backing up LVM volumes
in [Debian]
|
From: Boyd Stephen Smith Jr. on 27 Apr 2010 15:50 On Tuesday 27 April 2010 14:07:07 Chris Davies wrote: > Johannes Wiedersich <johannes(a)physik.blm.tu-muenchen.de> wrote: > > rsync -a /mounted/partition /directory/on/mounted/backup > > backs up all I need. Read man rsync for its options. > > > > Why not just copy the data off the mounted partition. Even more simple > > and faster. > > That's great for you. It might not be so useful for the OP, because > their filesystem is fast-changing and/or contains large files (or > groups of files) that are updated but need to maintain their internal > integrity. Consider MySQL database files as one simple example of such. For "normal" file operations, taking an LVM snapshot of the mounted filesystem and then making your backup from that should be sufficient. This should even work for postgreSQL database files (though, it is not optimal). MySQL has a history of being more flaky, but it might work there as well. If you snapshot a mounted file system, the snapshot will be approximately equivalent to the original file system, uncleanly unmounted at that exact moment (think: power failure). It's possible to then take backups of an active system with no downtime (although I/O load will certainly go up during the backup). If you mount the snapshot as part of the backup procedure, a journaled file system will want to replay the journal then. Otherwise, a journal replay will be required at restore time. PostgreSQL (etc.) will also end up doing a journal replay / recovery at restore time. If you cleanly unmount a file system, take a snapshot of it, remount it, then make your backup from the snapshot, you should be in a much better position. You will have a little bit of downtime, but the snapshot will be of a cleanly unmounted file system that will be totally quiesced during the backup process. Again, I/O load will likely be high during the backup, but that's not easily avoided. Since the file system was cleanly unmounted, no journal replay / recovery will need to occur at any level at either backup or restore time. (Honoring "Reply-To" header by including the author in the CC.) -- Boyd Stephen Smith Jr. ,= ,-_-. =. bss(a)iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
From: Celejar on 27 Apr 2010 17:10 On Tue, 27 Apr 2010 14:51:57 -0500 "Boyd Stephen Smith Jr." <bss(a)iguanasuicide.net> wrote: .... > For "normal" file operations, taking an LVM snapshot of the mounted filesystem > and then making your backup from that should be sufficient. This should even > work for postgreSQL database files (though, it is not optimal). MySQL has a > history of being more flaky, but it might work there as well. > > If you snapshot a mounted file system, the snapshot will be approximately > equivalent to the original file system, uncleanly unmounted at that exact > moment (think: power failure). It's possible to then take backups of an > active system with no downtime (although I/O load will certainly go up during > the backup). If you mount the snapshot as part of the backup procedure, a > journaled file system will want to replay the journal then. Otherwise, a > journal replay will be required at restore time. PostgreSQL (etc.) will also > end up doing a journal replay / recovery at restore time. > > If you cleanly unmount a file system, take a snapshot of it, remount it, then > make your backup from the snapshot, you should be in a much better position. > You will have a little bit of downtime, but the snapshot will be of a cleanly > unmounted file system that will be totally quiesced during the backup process. > Again, I/O load will likely be high during the backup, but that's not easily > avoided. Since the file system was cleanly unmounted, no journal replay / > recovery will need to occur at any level at either backup or restore time. Thanks for this explanation. Your explanation of the difference between snapshotting a mounted vs. unmounted filesystem might explain some of the trouble that I've been having with my snapshot based backup procedure, but I've still had to give up lvm snapshots totally as broken, primarily because of this (see my messages in the thread): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549691 I've also been hit by this, although it *may* be harmless (or not - this stuff could really use decent documentation): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503268 Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/20100427170355.b422e4a4.celejar(a)gmail.com
From: Celejar on 27 Apr 2010 17:20 On Tue, 27 Apr 2010 13:44:27 +0100 Chris Davies <chris-usenet(a)roaima.co.uk> wrote: .... > LVM provides a snapshot mode for this kind of requirement. It's not > stunning but it's usually sufficient. Perhaps usually, but in my use-case (and that of others) it's badly broken (I've mentioned this elsewhere in the thread, but I really need to vent about this badly documented, frustrating mess: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549691 Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/20100427171023.540fe533.celejar(a)gmail.com
From: Boyd Stephen Smith Jr. on 27 Apr 2010 17:40 On Tuesday 27 April 2010 16:03:55 Celejar wrote: > I've had to give up lvm snapshots totally as > broken, primarily because of this (see my messages in the thread): > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549691 That is troublesome, probably to the point of actually being broken. It's likely that something "behind-the-scenes" in LVM is actually messing with the snapshot device even when it is not mounted and preventing the removal. I'm fairly sure the snapshot device has to be updated whenever a write is done to a new LE in the original device, and it's possible *that* is causing the problem. I hope this issue gets some attention; I doubt it is a Debian-ism. > I've also been hit by this, although it *may* be harmless (or not - > this stuff could really use decent documentation): > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503268 My guess on this one is one of two things: 1) Udev is taking a little while to unlink "secondary" names for the LVs that are being removed, and when lvm does its device scan it's hitting "missing" devices. 2) LVM is using device names from its cache for devices that are no longer present for its device scan and, again, hitting "missing" devices. In either case I think the error messages are annoying, but not indicative of a real problem. -- Boyd Stephen Smith Jr. ,= ,-_-. =. bss(a)iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
From: Celejar on 27 Apr 2010 18:00 On Tue, 27 Apr 2010 16:40:37 -0500 "Boyd Stephen Smith Jr." <bss(a)iguanasuicide.net> wrote: > On Tuesday 27 April 2010 16:03:55 Celejar wrote: > > I've had to give up lvm snapshots totally as > > broken, primarily because of this (see my messages in the thread): > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549691 > > That is troublesome, probably to the point of actually being broken. It's > likely that something "behind-the-scenes" in LVM is actually messing with the > snapshot device even when it is not mounted and preventing the removal. Makes sense to me, although I'm no expert. > I'm fairly sure the snapshot device has to be updated whenever a write is done > to a new LE in the original device, and it's possible *that* is causing the > problem. I hope this issue gets some attention; I doubt it is a Debian-ism. The mechanism is somewhat documented in the source tree at Documentation/device-mapper/snapshot.txt, although I'd have to read it more carefully. > > I've also been hit by this, although it *may* be harmless (or not - > > this stuff could really use decent documentation): > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503268 > > My guess on this one is one of two things: > 1) Udev is taking a little while to unlink "secondary" names for the LVs that > are being removed, and when lvm does its device scan it's hitting "missing" > devices. > 2) LVM is using device names from its cache for devices that are no longer > present for its device scan and, again, hitting "missing" devices. > > In either case I think the error messages are annoying, but not indicative of > a real problem. Makes sense. I don't think that I've ever experienced an actual problem obviously related to this, although it may, of course, be symptomatic of something actually wrong with my setup. Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/20100427175829.e1e7f763.celejar(a)gmail.com
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 Prev: [UNICOLOMBIA] Matriculas abiertas Next: tool tips remaining after window switching |