Hi all.
I'm trying to use duplicity to back up LVM snapshots (which are Xen domU disks).
I've seen scripts that take a snapshot, mount the snapshot, and then back up the files inside it. But my preference is to just back up the LVM logical volume directly. I feel more comfortable knowing I have an exact, filesystem-level snapshot.
However, this doesn't appear to work: if I specify a volume such as /dev/dm-10, this isn't backed up. So at the moment I am using dd to copy the volume data to a temporary file, and then using Duplicity on this. However, this causes a lot of seemingly unnecessary disk thrashing.
So, a couple of questions:
1. Should Duplicity be able to back up the LVM partition directly? If so, how? (If not, why?).
2. Am I misguided? Is it a much better idea just to mount the snapshot and back up the files? If so, why?
A block-level backup is not inherently a bad idea - obviously it has different tradeoffs to a filesystem level backup, such as wasting time and space backing up unallocated blocks, and possibly being harder to pull out individual files or to restore on a different OS. I would say generally it's better to have a filesystem level backup, but it's often worth having more than one backup strategy, and perhaps this is worth doing too.
There's no in-principle reason why duplicity couldn't back up the contents of block devices rather than the node, but it doesn't do that today and it would require some code changes.
What I would probably do in your situation is skip duplicity and go right to rdiff, the compression layer underneath it, since you don't need and can't use the duplicity features to do with selecting files, storing file metadata, etc.
Something like (pseudocode)
dd if=/dev/whatever | rdiff delta devfoo.sig | gzip -9 > /backup/devfoo-`date -I`.rdiff