Before major system changes, I do snapshot of @ to bak_@
but…
To do this I need to boot into live environment, mount drive with btrfs file system and then do the snapshot.
Similar way with snapshot recovery
I don’t believe that there is no better way (for this case I don’t want to use tools like timeshift)
I think that sometime ago I tried to do this under running system (restore snapshot) but something went wrong and I had to repair everything my way.
If I have @ subvolume
Can I do its snapshot backup in current running system?
Can I restore this backup during the same session ?
I have encrypted drive. After restoring, something went wronk and I couldn’t boot the system. I had to chroot into installation and install bootloader (systemd boot)
I thought that timeshift do this. Isn’t it? It recover snapshots after reboot?
I never restored a system backup with Timeshift, but i think it would have the same impact than updating. Meaning, you’d need to reboot afterwards in order to use the restored system.
I do snaps and rollbacks in live system.
To do a snap, mount the root file system and then make the snap. Like:
sudo mount -t btrfs /dev/sda1 /mnt
sudo btrfs sub snap /mnt/@ /mnt/@-210902-preUpdate
sudo umount /mnt
Do what you need.
You can undo with:
sudo mount -t btrfs /dev/sda1 /mnt
sudo mv /mnt/@ /mnt/@-failed
sudo mv /mnt/@-210902-preUpdate /mnt/@
sudo umount /mnt
and when you reboot you are in the previous state. The reboot it’s a must.
May be you can work with different snaps in “live mode” using firejail --chroot. I’ll try someday.
You should delete the failed snap eventually, to free disk space.
As you probably know:
sudo mount -t btrfs /dev/sda1 /mnt
sudo btrfs sub del /mnt/@-failed
sudo umount /mnt
It’s important to do the two “mv’s”.
I believe that I tried sometime ago, something like:
mounting
creating snapshots
and to rollback:
btrfs subvolume delete @ which was my root subvolume
btrfs subvolume snapshot @bak @
Don’t remember but this destroyed my system I believe
So with subvolumes @ and @bak I should do
mv @ @trash
mv @bak @
My directory tree lokks like this:
nvme0n1 259:0 0 931,5G 0 disk
├─nvme0n1p1 259:1 0 500M 0 part /boot
├─nvme0n1p2 259:2 0 431G 0 part /Windows
└─nvme0n1p3 259:3 0 500G 0 part
└─cryptroot 254:0 0 500G 0 crypt /var/cache
/home
/
My subvolumes are on nvme on nvme0n1p3, and this partition is encrypted so I should mount /dev/mapper/cryptroot it directly in /mnt
And when I ls mnt I’ll see @, @bak subvolumes
Right?
There are some limits in moving snapshots. You can’t move a ro-snapshot, but only rw-snapshots. So you can’t move @backup when it is readonly (what a backup should be). But you may make a rw-snapshot of the backup to @
Using snapshots, understand that you have to explicitly mount your root filesystem (subvolid=5).
Whether you do your snapshots manually (that is what i do) or in an app, it has to be done.
All my snapshot are in /.snapshots folder (folder created manually) and i have added this in fstab :
In that case, you can list your snapshots in command line, add or delete them, no need to boot into a live cd. You see them all in the /.snapshots folder too.
When i want to add a snapshot of @, i do :
sudo btrfs subvolume snapshot / /.snapshots/<name of your snapshot>
Then i advice you to install grub-btrfs, so that your snapshots are available in grub menu. So each time you add a snapshot there is a new entry in grub. I do not use Timeshift either.
So, i manually add snapshots in a running system and when i want to restore the previous snapshot (or an older one), i reboot and i choose it in grub menu.
I would like to bump my previous question and ask one more
If I have @ subvolume
And I do a snapshot of it @snap
In fstab should I mount @ or @snap?
Can I use both snapshots (change fstab entry when I want) or just use @ and if something goes wrong delete @ and use @snap?
If you create a second subvolume (rw) this will be a separate subvolume with inital the same files. But when using it it will beginn to differ from ist anchestor. Also if you use the anchestor again (rw) this subvolume will also beginn to differ from its first state. While this is possible, you may get confused, where your newest files may be