Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Adding linux-ha to cc list. The discussion is about using the drbd secondary as a source for nightly backups. On Wed, Apr 8, 2009 at 2:19 PM, Lars Ellenberg <lars.ellenberg at linbit.com> wrote: > On Wed, Apr 08, 2009 at 01:34:43PM -0400, Greg Freemyer wrote: >> On Wed, Apr 8, 2009 at 1:13 PM, Peter Sabaini <peter at sabaini.at> wrote: > >> >> >> Anyhow, provided the bandwidth is sufficient, I prefer the DRBD >> >> option. However, will the backups be successful, if the backup drive >> >> is attached to the secondary? Most of what I've read suggests that >> >> you shouldn't even mount the secondary in read-only mode (although >> >> maybe an LVM snapshot can be mounted for taking a backup). >> > >> > DRBD won't allow you to mount a secondary. This means you either have to use a >> > Dual Primary setup (requiring a cluster filesystem) or make a block-level >> > backup (don't know if thats adivsable). Maybe you can temporarily disconnect >> > DRBD for the backup, promote the secondary, mount + backup, demote again, and >> > reconnect -- Im not really sure if this would work though, you'd have to try. >> > >> > peter. >> >> I also don't think a snapshot will work either. The first step in >> creating a snapshot is to quiesce every thing, then create the >> snapshot. Since the quiesce would have to happen on the primary, I >> don't think you could properly coordinate a snapshot being created on >> the secondary. >> >> If tape is critical to your situation, you may need to stick to rsync. >> >> FYI: I think this should be added to the drdb wishlist. I think some >> commercial SAN devices that replicate have to ability to mount the >> remote copy by using snapshot technology on the remote. >> >> And I know some support what Peter describes which is effectively: >> >> quiesce primary > > xfs_freeze -f # or pick your favorite equivalent > > but, you have to be aware that "quiesce filesystem" (which is what a > local lvm snapshot would implicitly try to do for you on recent Linux > OS), is _not_ the same as "quiesce primary". > you need to actually "quiesce" all applications as well... > > [*] but see below. > >> stop block transmissions from primary to secondary > > drbdadm disconnect > >> mount secondary in read-only form >> perform backup >> unmount secondary >> release drdb to continue updates > > even mount -o ro _does_ rw access to the device in general (update > superblock, replay journal...). and drbd does not and will not support > to mount a device in secondary role. At a minimum XFS has a specific mount option for true readonly devices. The option was put in specifically to support truly readonly snapshots. I don't know if any of the other common linux fs'es have that feature. > still, you can introduce an arbitrary "split brain" here, > make it primary, and mount -o ro that one, > then later connect --discard-my-data, to revert potential (minimal) > local changes and apply changes done on the remote "real/production" > primary since the disconnect. > >> If drdb doesn't support that, I'd also like it to go on the wishlist. > > [*] much easier, and already suggested: > just do an lvm snapshot below the drbd on secondary, > and mount that one readonly. > > ignore the "quiesce" point, or replace it with a simple "sync;". > if your file system and applications are able to recover from > a crash, they are able to recover from a snapshot while taken > even when not "quiesce"d. > if they are not able to recover: don't use them. > > of course, for any applications supporting "checkpoints", > it would shorten the necessary recovery time if you > set a checkpoint on the active node just before > you take the snapshot on the secondary. Lars, I see your feedback above, but you are showing doing some stuff on the primary, then some stuff on the secondary. Maybe the drbd admin gui tool could leverage pacemaker / heartbeat to support this. If one wants to automate a nightly backup as an example, for most scenarios it would be: quiesce primary (yes, quiesce apps, quiesce fs, quiesce drdb secondary) quiesce drdb secondary ( drbdadm disconnect or possibly something less drastic) lvm snapshot secondary at direction of primary (via pacemaker / heartbeat) have secondary mount snapshot (via pacemaker) start backup (via pacemaker) Seems like a great feature to add to the drdb admin gui. Greg -- Greg Freemyer Head of EDD Tape Extraction and Processing team Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com