Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Thu, Feb 03, 2011 at 02:16:08PM -0600, J wrote: > On 2/3/2011 1:09 PM, Digimer wrote: > >On 02/03/2011 01:50 PM, J wrote: > > > > If you use clustered LVM, snapshotting is not an option. > > > > How you snapshot depends, to an extent, on where LVM is in relation to > >your DRBD resource. That is, if it's raw partition -> DRBD -> LVM, raw > >partition -> LVM -> DRBD or stacked raw -> LVM -> DRBD -> LVM. > > > > If you've got LVM below DRBD, then snapshotting it would, I suspect, > >take a point-in-time snapshot of one side of the resource. So long as > >the DRBD itself is UpToDate, this should provide you with a "drive > >image" capable of restoring your DRBD resource. Alternatively, if you > >use LVM on DRBD, then you can snapshot individual LVM LVs as you > >normally would. > > > > In either case, you should not impact or effect your DRBD resource, > >beyond allocating enough space for the snapshot partition (be it > >node-side or space in the DRBD resource). > > > > So, I believe the answer is no: I will not be able to mount that > locally and easily. Suppose remounting the file system read only for > a fast rsync is a viable fall back. Don't give up so quickly because of information overload ;-) Your question was: if I take a snapshot of the logical volume used by drbd, will I be able to mount that locally (and easily?) Though J's answer is correct, it does not clearly say it: The answer is: Yes. It's that simple. Bonus: you can even do it on the Secondary, so the additional rsync load will less affect the primary too much. Caveat 1: (nothing to do with DRBD) of course, if there are files currently in use (like database stuff etc.) you should first tell your application to "quiescen" (equivalent of "flush tables with lock" or whatever the incantation was). Caveat 2: (has to do with additional layer between lv and fs) If a file system lives directly on an LV, "lvcreate -s" will do an implicit "freeze" of the file system, and then "thaw" it again once the snapshot is taken. This is not strictly necessary, but reduces potentially large journal replays necessary when mounting the snapshot, in case the snapshot is taken during a particularly busy period. If there is an additional layer between LV and file system, in this case DRBD, this implicit freeze/thaw is no longer done. If you really want it, you'd have to do it explicitly. To do that, you could use xfs_freeze -f, xfs_freeze -u, even against a non-xfs file system. It it much more useful to "quiesce" the application(s) running on top of that filesystem than the filesystem itself: if you don't do the former, the latter won't help much, if you do the former, the latter does not have much to do, anyways. So if you did not know about that file system freezing, you can probably safely forget about it again. The additional information about all the various stacking possibilities with DRBD and LVM are still correct. -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. __ please don't Cc me, but send to list -- I'm subscribed