Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
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