On 10/30/2011 05:17 PM, Bear Giles wrote: > LVM lets you create a snapshot where the mounted filesystem looks normal > but under the cover it's using a journal and the original logical volume, > e.g., /dev/mapper/vg0/home, is untouched. You can then perform your backup > and when you release the snapshot the journal is written to the original > volume.
Actually, the snapshot keeps copies of any blocks that have been modified in either the original or the snapshot volume, and when you delete the snapshot, they are all discarded. More recent versions of LVM now allow you to merge ( with lvconvert ) the snapshot into the original volume the next time it is remounted, effectively allowing you to revert the original volume to the snapshot state. > Obviously this requires a backup app that runs against the raw device > instead of the mounted filesystem. 'dump' does that, 'tar' does not. It does not require that since you can just mount the snapshot, then use tar, but in my experience, dump is much faster than tar. I've looked at trying to implement a system restore based on LVM for the last year or so and have concluded that it just isn't practical. There are a number of problems that make it so: 1) You must reserve space for the snapshot up front, and if that space runs out, the snapshot is lost. 2) Because it operates on a block level, it is rather inefficient. Specifically, you can write a new file to disk, and then delete it, but the blocks it was written to remain in the snapshot exception store, and may be somewhat larger than the actual file size, as the snapshot block size defaults to 64k iirc. These no longer used blocks also then have to be copied back to the original location during a merge, whether or not they actually contained any data in the snapshot. 3) Having a snapshot active has an appreciable write performance penalty on the original volume. This penalty grows linearly worse as you add more snapshots because each new write to the original volume results in data being copied out to each of the active snapshots first. It appears that btrfs is the way to go for system snapshots, and the apt-btrfs-snapshot package appears to be a good first step in this direction. It currently causes apt to make a btrfs snapshot before each upgrade/install and provides a command line interface to list, delete, and rollback to snapshots. It is written in python and I have been thinking of adding a little gtk gui to it. I spent this weekend patching dpkg to support a --force-no-syncs option so that apt can instruct it to avoid all of the syncs dpkg normally does as they are rendered completely pointless when you can just rollback to the snapshot if things go wrong, and have a large performance penalty, especially on btrfs. I've also been thinking of adding some support to grub to allow you to choose to roll back to a snapshot right from there, in case you can't even boot the system to ask apt-btrfs-snapshot to do it for you. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
