devurandom
commented
5 years ago In my own, crude snapshoting script I was using @ plus the config name (e.g. home) plus the UTC timestamp (e.g. 2019-05-11T00:37:00Z) as the snapshot name (-> @home-2019-05-11T00:37:00Z).
This is somewhat similar to what the btrfs devs recommend: https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Managing_Snapshots
Currently snapper recycles the snapshot directory name e.g. /xyz/.snapshots/1..n/snapshot and this can be a problematic for some applications like for example SAMBA. E.g. consider the following example where some snapshot directories exposed as shares by SAMBA are deleted and then recreated outside of SAMBA
the following snapshots;
/xyz/.snapshots/1/snapshot /xyz/.snapshots/2/snapshot /xyz/.snapshots/3/snapshot
are exposed as SAMBA shares named respectively 'shadowable@{0a0df48e-35d1-48df-8c03-0ba52767be34}', 'shadowable@{0ad619ff-a8f2-4789-823b-f9a70be7bb08}' & 'shadowable@{9893c614-a98e-495f-8040-6eea8af1ac61}'
say an administrator deletes /xyz/.snapshots/3/snapshot via 'snapper delete 3' and creates a new snapshot via 'snapper create' now samba thinks the samba share named 'shadowable@{9893c614-a98e-495f-8040-6eea8af1ac61}' still exists (as the associated /xyz/.snapshots/3/snapshot directory exists but isn't actually the same snapshot)
Possible solutions: a) A new api that allows a uuid to be retrieved for a particular snapshot. (such a uuid could be obtained from the underlying filesystem if it already provides such and/or snapper could generate it's own) b) snapper could implement a different naming scheme that doesn't resuse the id and provides a unique name instead.