Love snapper/btrfs. It has saved me on numerous occasions. However, despite reading up on it I seem to have some basic confusion.
Here’s my current snapshots
$ sudo snapper list
[sudo] password for root:
Type | # | Pre # | Date | User | Cleanup | Description | Userdata
-------+------+-------+-------------------------------+------+---------+-----------------------+--------------
single | 0 | | | root | | current |
single | 1 | | Sun 15 May 2016 07:47:50 AEST | root | | first root filesystem |
single | 2032 | | Wed 04 Apr 2018 22:14:04 AEST | root | | |
pre | 2050 | | Mon 09 Apr 2018 12:11:04 AEST | root | number | zypp(packagekitd) | important=yes
post | 2051 | 2050 | Mon 09 Apr 2018 12:18:25 AEST | root | number | | important=yes
$ sudo btrfs subvolume get-default /
ID 2543 gen 1723908 top level 258 path @/.snapshots/2032/snapshot
$ sudo snapper status 1..2032 | wc -l
387527
$ sudo snapper status 2032..2050 | wc -l
71475
$ sudo snapper status 2050..2051 | wc -l
40356
My main confusion is that I would expect 0 to point to the latest snapshot 2051 (perhaps after reboot?), thus allowing me to delete 2032. Why is 0 pointing to an “earlier snapshot”?
Also, why can I not delete 1? Essentially resetting the “base” to the current snapshot?
‘0’ points to the snapshot you are booting from. The snapshots following ‘2032’ contain the differences based on that snapshot. I believe but stand to be corrected that 2032’ is based on ‘1”.
The key to understanding things is that snapshots do not contain a complete picture, only a set of differences.
First of all, a snapshot is, as the name suggests, a “photograph” of the filesystem at some point in time. It is not a set of differences, and does not need another snapshot to exist, it stands on its own. If you look into /.snapshot/1/snapshot you will see what your root filesystem looked like after installation, 2 years ago.
I believe that you CAN delete 1, just do
snapper delete 1
and it should go.
Snapshot 0 is not really stored in /.snapshot because it represents the current situation. It allows you to compare any snapshot with the current situation, to see what changed since the snapshot. For instance, with
snapper status 1..0
you can see all the files that are different between when you installed and now.
The snapshot subcommand creates a snapshot of the given subvolume (the /mnt/1 root volume in this case), placing that snapshot under the requested name (/mnt/1/snapshot) in that subvolume. As a result, we now have a new subvolume called snapshot which appears to contain a full copy of everything that was in the filesystem previously. But, of course, Btrfs is a copy-on-write filesystem, so there is no need to actually copy all of that data; the snapshot simply has a reference to the current root of the filesystem. If anything is changed — in either the main volume or the snapshot — a copy of the relevant data will be made, so the other copy will remain unchanged.
I tried once and you can’t. A lot of searching has not turned up much info, but it looks to me like snapshot 1 is the ‘mother’ of everything that follows.
This is saying that when you take a snapshot you make a full copy of the filesystem. However, since btrfs is copy-on-write it actually creates something that I believe we can think of as a hard-link to the file, instead of making an actual copy. If at any point in time the linked file is modified then the copy is actually made.This is different, though, from differential backups, where only the files that have changed since the previous backup are stored. The snapshot is always a full copy (but it’s lightweight, because of the CoW mechanism).
Also, the same guide you quote reads:
A snapshot in Btrfs is a special type of subvolume — one which contains a copy of the current state of some other subvolume
it doesn’t say anything about the copy being differential…
I tried once and you can’t.
This I can’t explain… where you root?
For instance I don’t have any “mother” snapshot, I have the current situation:
Type | # | Pre # | Date | User | Cleanup | Description | Userdata
-------+----+-------+------------------------------+------+---------+-----------------------+--------------
single | 0 | | | root | | current |
single | 2 | | Mon 09 Apr 2018 12:52:13 BST | root | number | after installation | important=yes
pre | 20 | | Mon 09 Apr 2018 19:14:45 BST | root | number | zypp(ruby.ruby2.5) | important=yes
post | 21 | 20 | Mon 09 Apr 2018 19:19:46 BST | root | number | | important=yes
single | 25 | | Mon 09 Apr 2018 19:42:59 BST | root | number | rollback backup of #1 | important=yes
single | 26 | | Mon 09 Apr 2018 19:43:00 BST | root | | |
pre | 37 | | Tue 10 Apr 2018 11:39:20 BST | root | number | yast sw_single |
pre | 38 | | Tue 10 Apr 2018 11:39:54 BST | root | number | zypp(ruby.ruby2.5) | important=no
post | 39 | 38 | Tue 10 Apr 2018 11:39:59 BST | root | number | | important=no
post | 40 | 37 | Tue 10 Apr 2018 11:40:02 BST | root | number | |
pre | 41 | | Tue 10 Apr 2018 11:40:19 BST | root | number | yast sw_single |
pre | 42 | | Tue 10 Apr 2018 11:40:43 BST | root | number | zypp(ruby.ruby2.5) | important=no
post | 43 | 42 | Tue 10 Apr 2018 11:41:37 BST | root | number | | important=no
post | 44 | 41 | Tue 10 Apr 2018 11:44:28 BST | root | number | |
pre | 45 | | Tue 10 Apr 2018 14:00:21 BST | root | number | zypp(packagekitd) | important=yes
post | 46 | 45 | Tue 10 Apr 2018 14:02:13 BST | root | number | | important=yes
where even snapshot 2 will be deleted by the “number” algorithm when its time comes (it keeps 10 “important” ones and right now I only have 6). Also, as you can see #1 is gone.
I think we are arguing over semantics. A “full” copy is either “full” or not, but I don’t thing it can be “full” and “lightweight”.
As far as deleting 1, yes I was root and I couldn’t delete it. And just to prove it, I tried again, and guess what? It got deleted! :sarcastic: Live and learn.
I have an older installation with docker installed, and whenever I did a rollback the docker images got messed up and took a lot of manual editing to get working again. Recently I created a new partition /var/lib/docker, formatted it ext4 and mounted it and reinstalled docker. I manually removed all the btrfs docker snapshots I could find. Now it works like a charm, and appears to let me delete snapshot 1.
This is what I mean: a differential backup, with respect to a previous backup, only copies the files that have changed since the previous backup. A full backup copies every file regardless of any previous backup. Snapshots are full backups. They don’t depend on any previous snapshot, and you can delete any snapshot you want, you’ll still be able to use the ones that are left. In a differential backup you need the whole sequence of backups to reconstruct the filesystems, while with snapshots you only need one.
Now for the lightweight part. This is entirely depending on Copy-on-Write. If the filesystem wasn’t CoW each snapshot would duplicate each file. With CoW, however, the file is actually copied only when necessary, that is when the original file is modified. In practice, therefore, the snapshots only hold the files that have changed since that snapshot was taken and something analogous to links to the files that didn’t change.
Yup. Me too! I recovered quite a bit of disk space.
Type | # | Pre # | Date | User | Cleanup | Description | Userdata
-------+------+-------+-------------------------------+------+---------+-------------------+--------------
single | 0 | | | root | | current |
single | 2032 | | Wed 04 Apr 2018 22:14:04 AEST | root | | |
pre | 2050 | | Mon 09 Apr 2018 12:11:04 AEST | root | number | zypp(packagekitd) | important=yes
post | 2051 | 2050 | Mon 09 Apr 2018 12:18:25 AEST | root | number | | important=yes
pre | 2052 | | Wed 11 Apr 2018 21:05:20 AEST | root | number | zypp(packagekitd) | important=yes
post | 2053 | 2052 | Wed 11 Apr 2018 21:21:35 AEST | root | number | | important=yes
Thanks for the discussion. It clarified things.
Looking into the above. The snapshots with higher numbers are later than earlier ones. Once exception the current “snapshot” 2032 which represents the current system state. Hence some of my confusion. So there are minimal differences between the snapshot 2053 and the current bootable system represented by 2032.
So all system changes now and forever are applied to 2032. Except if I do a rollback to a higher number number snapshot, in which case the number of the default current snapshot will increase to that new number. I was wondering how the current snapshot number increased - my other confusion.
