Ubuntu System Restore

[Phillip Susi]

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.