Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
(Apologies for top posting - working off a different laptop as I broke mine this morning, and outlook is a pain) Jake/Maurits/Digimer, Thanks for the replies. Jake/Digimer: > What it sounds like you need is LVM's snapshotting capability. DRBD is designed to be a block-level replication tool, not a backup tool per-se. We need to back up individual folders, some of which are 80+ GB. I don't think a snapshot allows me to do this? Digimer: > As a secondary aside; Why use cp instead of rsync? Data on the primary server is on a SAN, with about 8 million files, most tiny. The backup dumps this to fast local disks (there is other things on the SAN also, and all our VMs etc get backed up nightly, meaning sometimes disk IO access can be slowed), this is then compressed locally, before being booted off to local storage on the second server. The department in charge of the data, and the backup process are not that well versed in this, and when I suggested rsync and the delta capabilities, they assumed it is going to take longer to check, and never tested it fully. Preferably, I would like them to rsync to the second machine, and then do the tar/gz there. But with managers involved, ive been told to look for another solution, as they "don't have the time to spend days looking at something that is potentially slower" > (inducing a split-brain condition, which is generally something you want to avoid The second machine does nothing except store a copy of this data (why they need 2 6core procs & 128GB memory baffles me tbh!). It actually stores two copies, one which is a "site sync" in the software, and the other being the tar/gz copy. It is source code, so they are quite finicky about the data. I will download the DRBD manual, and have a good read through. As I said im a novice with it. I also haven't used LVM snapshotting much, so will investigate that also. Once again, thanks for the replies. B -----Original Message----- From: Digimer [mailto:linux at alteeve.com] Sent: 17 February 2012 15:20 To: Brian O Mahony Cc: drbd-user at lists.linbit.com Subject: Re: [DRBD-user] Documentation download & another DRBD question On 02/17/2012 08:19 AM, Brian O Mahony wrote: > Hey folks > > I have a server with about 500GB of data on its own filesystem. > Currently, nightly, we lock this data, use tar to copy it it another > volume, unlock it, then use gzip on the copy to compress, and then > copy this to a second server for backup. The reason for the multi-step > process, is we want to keep data lock time a minimum. > > What I was thinking of doing is using DRBD to mirror this volume to > the second server. At backup time, on the second system, we stop the > process, or stop the packet shipping or likewise, so there will be no > updates, lock the data, run tar/gz, unlock, and restart the synchronization. > > Is this possible. IE can DRBD deal with a system being unavailable for > a few hours, store changes (or do checksums etc) and then replay those > changes when the second system comes back online? What it sounds like you need is LVM's snapshotting capability. DRBD is designed to be a block-level replication tool, not a backup tool per-se. For example, DRBD would be perfect playing the role of protecting your data from a sudden catastrophic failure on the server. There would be no data loss at all and within moments, the system could be back online with the help of a clustering layer like pacemaker or rhcs. Though you could technically break the secondary/backup node off, force it to be primary (inducing a split-brain condition, which is generally something you want to avoid), copying the data and then invalidating the node again, it would be a very unwise way of using DRBD. Whereas LVM's snapshot partitions are designed to do exactly what you want. It "freezes" the data at a point in time, allowing the partition to stay in use while you back up that snapshot partition. As a secondary aside; Why use cp instead of rsync? -- Digimer E-Mail: digimer at alteeve.com Papers and Projects: https://alteeve.com The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. If you are not the intended addressee please contact the sender and dispose of this e-mail. Thank you.