On 2016-03-23 13:41, Vytautas D wrote:
I can think of few ways to revert changes with btrfs, but I wonder
what are the trade-offs between each method and perhaps there is
already research done on this?
ways to restore a snapshot ( post kernel 3.* ):
a) via set-default
1. btrfs subvolume set-default / $id
2. reboot
b) always mount into snapshot
1. mount -o suvol=/.current $disk # at initrd
2. btrfs subvol del /.current
3. btrfs subvol snapshot /.snapshotA /.current
4. reboot
c) rsync
1. rsync $options /.snapshotA /.current
2. reboot
I can't give much advice on these except to say that the last one listed
is horribly inefficient and may break things (and use large amounts of
space).
That said, I can share what I use on my systems to do this. On all of
my systems, I intentionally do not use the default subvolume feature,
and always specify what subvolume to mount. This allows me to take
snapshots of the system prior to upgrades (or in other cases where I
need a snapshot), and then roll back by doing the following:
1. mount LABEL=root /mnt/tmp
2. mv /mnt/tmp/root /mnt/tmp/old-root
3. mv /mnt/tmp/snap1 /mnt/tmp/root
4. touch /mnt/tmp/root/.rollback
3. reboot
6. An custom init script sees the file /.rollback, and then copies over
any nested subvolumes from the old-root subvolume, renames old-root to
old-$(date +%FT%T), and deletes /.rollback
This works because mounting with the 'subvol=' mount option only pays
attention to the path, not the subvolume id or inode.
This can be done on a live system which is actively using the subvolume
without disrupting normal operation, provided the subvolume itself is
mounted as part of the FS hierarchy and not implicitly used via nesting.
All writes to the mounted subvolume still get sent to the old
subvolume until the reboot happens (which is usually a good thing).
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
