Support for snapper snapshot structure

[Dalmat]

The destination snapshot comparison does not work on my setup. Actually exists_at_dst returns 1 when the snapshot already exists remotely On the other side, "function_call && exit" only exit if the function_call return code is 0, i.e fine

[nachoparker]

We should see why it fails, and fix it inside the function.

What is the output of btrfs subvolume show "$src" in your setup?

Thanks

[Dalmat]

Hello,

Indeed, sorry I misread and inverted the expected return code of exists_at_dst returns. My problem is that DST_UUID is always empty, because my snapshots are created by snapper and have the following hierarchy

# btrfs subvolume list /home 
ID 257 gen 4159 top level 5 path @home
ID 260 gen 4131 top level 257 path .snapshots
ID 261 gen 3554 top level 260 path .snapshots/1/snapshot

I don't have a directory containing all snapshots

The listing of snapshots done by DSTS=( $( ls -d "$DST"/* 2>/dev/null ) ) looks for snapshots as direct subdirectories from the target path. Consequently get_dst_snapshots() does not find any remote snapshot

What I need in this case is a way to specify that the snapshots are 1 level deeper from the main backup directory

[nachoparker]

That's an interesting hierarchy... btrfs-sync expects a folder full of snapshots, and you have a .snapshots folder with... subfolders that have snapshots...

Where would the other snapshots go? .snapshots/2/snapshot? it would be interesting to support snapper, but we have to see how would that go with their snapsthot structure.

[Leicas]

I just faced the same issue. I have was able to cheat for the first snapshot using /.snapshot/* as source, but then the other I get : ERROR: cannot find parent subvolume And in the destination folder I only get the content of the folder.

[Dalmat]

Hello,

I'm back to this topic. The snapper hierarchy is indeed as described previously

# btrfs subvolume list /home 
ID 257 gen 5473 top level 5 path @home
ID 265 gen 5450 top level 257 path .snapshots
ID 266 gen 5321 top level 265 path .snapshots/1/snapshot
ID 267 gen 5323 top level 265 path .snapshots/2/snapshot
ID 268 gen 5328 top level 265 path .snapshots/3/snapshot
ID 269 gen 5352 top level 265 path .snapshots/4/snapshot
ID 270 gen 5355 top level 265 path .snapshots/5/snapshot
ID 271 gen 5358 top level 265 path .snapshots/6/snapshot
ID 272 gen 5361 top level 265 path .snapshots/7/snapshot
ID 273 gen 5363 top level 265 path .snapshots/8/snapshot
ID 274 gen 5364 top level 265 path .snapshots/9/snapshot
ID 275 gen 5448 top level 265 path .snapshots/10/snapshot
ID 276 gen 5449 top level 265 path .snapshots/11/snapshot

I doubt snapper will change this folder structure as it would be backward incompatible on an existing setup. I guess this setup was introduced because snapper generates a report file which cannot be in the snapshot, and is thus placed in the numbered folder.

If you are open to introduce support to snapper and this folder hierarchy, I can contribute/validate the change.

[nachoparker]

If you are open to introduce support to snapper and this folder hierarchy, I can contribute/validate the change.

Certainly, it would be great to support snapper but I don't use it myself so I would need someone else that uses it to contribute this change.

It is important only that the changes don't break current behavior

[Tigger2014]

@Dalmat Any progress on the changes needed for this, I would also benefit highly from it but not to sure how to go about writing the changes?