About this Adrien,
# mkdir /live-root # mount -o subvolid=0 /dev/sda4 /live-root # rsync -aHA --exclude="/live-root" / /live-root
-- Indeed this is much better than my original idea I would also add -X to preserve all extended attributes.
If you had install your Funtoo box inside a subvolume....
For exemple :
Subvolid=0 ----> @root id=255 or any number
--- Please don't use @ in front of snapshots names, this is an horrible bad practice to ban. A VFS structure should remain transparent at anytime (this is the reason of why subvolumes are threaten like directories without fancy names by the kernel). What is true on a machine can be false on another, good luck for applications compatibility especially with complex structures implying nested directories/subvolumes.
You would be able to use this instead :
# mkdir /live-root # mount -o subvolid=0 /dev/sda4 /live-root # cd /live-root # btrfs subvolume snapshot @root @live-root
I think that you should add something about installing a Funtoo inside a subvolume instead of installing it directly inside the subvolid=0
--- Why not but I don't see clearly what would a major differences of installing a distribution in another subvolume rather than 0 would be.... I should dig to measure the consequences :-)
--- Installing a distribution in a subvolume give a great advantage. First, Now on my system, each time I emerge something, update something or depclean, I get automatics snapshot of them so I can do a very fast recovery after reboot (Or I can boot any prior version of my funtoo very easily. Also, The way I use subvolume give me the ability to copy/rsync everything *without* the mounted stuff if the from of my copy is the subvolume, "/var/disksetup/@root" on my system instead of /
The other advantage is that all my subvolumes and snapshots are outside of my normal Funtoo VFS so safe from any human error because not mounted by default. I use the @ in the front of my subvolume (and not my mounting point pointing to them) to simply identify them as subvolume.. No incompatibility involved, the only tool who deal with them is the btrfs module and the btrfs-progs tools and the subvolume containing them is not mounted by default.
In case if I break totaly my /, it's a lot faster to delete the @root subvolume and make a snapshot of the latest good snapshot as @root than... copying the whole snapshot to / so I get, instant recovery.
Also, you can even use a @home as a subvolume and with that, you can have 2 separate strategy to backup your stuff.
Snapshot your @home every hour and @root every 12 hours.
There's a lot avantanges with subvolume.
My / (@root) is snapshoted at system modification with emerge and my /home (@home) is snapshoted at shutdown. This is a lot less hassle to manage for my automated recovery scripts... But maybe an hourly home backup is possible with some improvements.
Again: using fancy names is not a good pratice in the general case. See my arguments before, you can scan a BTRFS volume to see what subvolumes are in it..... I can have subvolumes at several place in the VFS and some other others machines may not follow the same layout or not use subviolumes at all. Fancy names = pratice to *ban*.