snapper undochange is not undoing changes

Hi,

Let me start of with a little bit of a back story on this:
Yesterday I added a new storage disk to a Tumbleweed server running the latest snapshot. The purpose of this disk is to store data for containerized applications, and for more important containers the data is bind mounted from the given subvolume in the container. I need to snapshot these subvolumes daily with snapper in case anything goes wrong - wrong build, wrong post etc - I can rapidly revert the change. The snapshot mechanism is double hating as a back solution as well (btrfs send | btrfs receive).
I currently have a main subvolume - DATA - and additional subvolumes as needed. That leaves me currently with 4 subvolumes making the strucuture the following:


ID 256 gen 763 top level 5 path DATA                                                                                                                                                  
ID 257 gen 766 top level 256 path portal_data                                                                                                                                         
ID 258 gen 767 top level 256 path portal_db                                                                                                                                           
ID 259 gen 764 top level 256 path docs_data                                                                                                                                           
ID 260 gen 765 top level 256 path docs_db                                                                                                                                             

Mounted from fstab:

UUID=478e3fe9-8a03-4f61-816a-85cc25a3ed21  /data btrfs compress=zstd:1,noatime,relatime,subvol=DATA 0 0

I enabled snapshoting with

snapper -c portal_data create-config /data/portal_data 

and so on for the other subvolumes the same way just changing the names and paths. I took the first snapshots myself with

snapper -c portal_data create 

and sure enough I had a snapshot done. Later followed by other timeline snapshots hourly.

The problem I ran into on this server is that really quickly the portal_data subvolume needed a rollback. I issued the # sudo snapper -c portal_data undochange 9…10 command, but to my surprise nothing happened. It listed what will be modified, created and deleted, but nothing happened within the folder it supposed to happen. I had to copy data from the snapshot manually.

Conducted a little test - before which I deleted a few snapshots to keep it clean - where I created a file called “justatest” under the /data/portal_data/_data/ (portal_data is the subvol) and issued the following commands:



portal-test:/data # snapper -c portal_data create -t single --description "test2"
portal-test:/data # snapper -c portal_data list
  # | Type   | Pre # | Date                     | User | Cleanup  | Description | Userdata
----+--------+-------+--------------------------+------+----------+-------------+---------
 0  | single |       |                          | root |          | current     |         
 7  | single |       | Wed Oct  6 15:00:25 2021 | root | timeline | timeline    |         
 8  | single |       | Wed Oct  6 16:00:27 2021 | root | timeline | timeline    |         
10  | single |       | Wed Oct  6 17:00:26 2021 | root | timeline | timeline    |         
11  | single |       | Wed Oct  6 17:32:38 2021 | root |          |             |         
12  | single |       | Wed Oct  6 17:46:34 2021 | root |          | test        |         
13  | single |       | Wed Oct  6 17:48:59 2021 | root |          | test2       |         
portal-test:/data # snapper -c portal_data status 12..13
+..... /data/portal_data/_data/justatest
portal-test:/data # snapper -c portal_data diff 12..13
--- /data/portal_data/.snapshots/12/snapshot/_data/justatest    1970-01-01 00:00:00.000000000 +0000
+++ /data/portal_data/.snapshots/13/snapshot/_data/justatest    2021-10-06 17:48:37.709550268 +0000
@@ -0,0 +1 @@
+/dev/random
portal-test:/data # snapper -c portal_data undochange 12..13
create:0 modify:0 delete:1
portal-test:/data #

Nothing happened. The file should’ve been deleted, but it wasn’t. What am I doing wrong here?

Hi adathor,

I’m not sure what the “undo_changes” command should bring. Asking

man zypper

it says

**undochange [options] **number1**..**number2**[files]**
           Undo changes done between snapshot number1 and number2. 

           **-i, --input **file
               Read files for which to undo changes from file file.

But I assume you want to go back to the status of snapshot 12?
That would be

snapper rollback 12

Documented usage of rollback is for root subvolume only. Do you really know and tested that rollback is actually possible for non-root subvolumes? Your example command is certainly wrong in this case because it applies to root, not to data subvolume. And this thread is about data subvolumes.

Yea rollback will definitely not work unfortunately. Anyhow I start to think that this question should this be a bug report?

Works here:

tw:~ # snapper -c portal_data create-config /mnt
tw:~ # snapper -c portal_data create
tw:~ # touch /mnt/foo
tw:~ # mkdir /mnt/bar
tw:~ # snapper -c portal_data create -t single --description test1
tw:~ # rm /mnt/foo
tw:~ # rmdir /mnt/bar
tw:~ # touch /mnt/foo1
tw:~ # mkdir /mnt/bar1
tw:~ # snapper -c portal_data create -t single --description test2
tw:~ # snapper -c portal_data list
 # | Type   | Pre # | Date                     | User | Cleanup | Description | Userdata
---+--------+-------+--------------------------+------+---------+-------------+---------
0  | single |       |                          | root |         | current     |         
1  | single |       | Sat Oct  9 10:40:04 2021 | root |         |             |         
2  | single |       | Sat Oct  9 10:40:58 2021 | root |         | test1       |         
3  | single |       | Sat Oct  9 10:41:21 2021 | root |         | test2       |         
tw:~ # snapper -c portal_data status 2..3
-..... /mnt/bar
+..... /mnt/bar1
-..... /mnt/foo
+..... /mnt/foo1
tw:~ # snapper --verbose -c portal_data undochange 2..3
create:2 modify:0 delete:2
deleting /mnt/foo1
deleting /mnt/bar1
creating /mnt/bar
creating /mnt/foo
tw:~ # ll /mnt
total 0
drwxr-x--- 1 root root  6 Oct  9 10:41 .snapshots
drwxr-xr-x 1 root root  0 Oct  9 10:43 bar
-rw-r--r-- 1 root root  0 Oct  9 10:43 foo
drwxr-xr-x 1 root root 18 Sep  1 20:28 rcv
drwxr-xr-x 1 root root 18 Sep  1 20:30 rcv2
drwxr-xr-x 1 root root  0 Sep  1 20:28 src
drwxr-xr-x 1 root root  0 Sep  1 20:28 src-snap1
drwxr-xr-x 1 root root  0 Sep  1 20:28 src-snap1-clone
drwxr-xr-x 1 root root  0 Sep  1 20:28 src-snap1-clone1
tw:~ # snapper --verbose -c portal_data undochange 1..2
create:0 modify:0 delete:2
deleting /mnt/foo
deleting /mnt/bar
tw:~ # ll /mnt
total 0
drwxr-x--- 1 root root  6 Oct  9 10:41 .snapshots
drwxr-xr-x 1 root root 18 Sep  1 20:28 rcv
drwxr-xr-x 1 root root 18 Sep  1 20:30 rcv2
drwxr-xr-x 1 root root  0 Sep  1 20:28 src
drwxr-xr-x 1 root root  0 Sep  1 20:28 src-snap1
drwxr-xr-x 1 root root  0 Sep  1 20:28 src-snap1-clone
drwxr-xr-x 1 root root  0 Sep  1 20:28 src-snap1-clone1
tw:~ # snapper --verbose -c portal_data undochange 3..1
create:2 modify:0 delete:0
creating /mnt/bar1
creating /mnt/foo1
tw:~ # ll /mnt
total 0
drwxr-x--- 1 root root  6 Oct  9 10:41 .snapshots
drwxr-xr-x 1 root root  0 Oct  9 10:51 bar1
-rw-r--r-- 1 root root  0 Oct  9 10:51 foo1
drwxr-xr-x 1 root root 18 Sep  1 20:28 rcv
drwxr-xr-x 1 root root 18 Sep  1 20:30 rcv2
drwxr-xr-x 1 root root  0 Sep  1 20:28 src
drwxr-xr-x 1 root root  0 Sep  1 20:28 src-snap1
drwxr-xr-x 1 root root  0 Sep  1 20:28 src-snap1-clone
drwxr-xr-x 1 root root  0 Sep  1 20:28 src-snap1-clone1
tw:~ # 

Show full protocol of what you did from the very beginning.

Argh, OK, nope. Missed that. Sorry! :embarrassed: