On Thu, Jan 21, 2016 at 5:00 PM, lee <l...@yagibdah.de> wrote: > Hm, I must be misunderstanding snapshots entirely. >
Well, in the case of zfs/btrfs you are. Different implementations have different snapshotting features. > What happens when you remove a snapshot after you modified the > "original" /and/ the snapshot? You destroy at least one of them, so you > can never get rid of the snapshot in a non-destructive way? If you remove a snapshot it goes away. If you remove the original it goes away. There isn't anything strange going on. With btrfs I can do this: btrfs su create a touch a/file btrfs su snap a b touch b/file2 echo "hello" >> a/file a now contains file with the text hello in it. b now contains file which is empty and file2 which is empty. If I delete a then it disappears. If I delete b then it disappears. They exist completely independently of each other. In btrfs the command "btrufs su snap a b" is somewhat equivalent to "cp -a a b" unless you look at what is going on closely. The main difference is that the first command takes almost zero time to execute, and consumes little additional space. This is true even if a is a directory containing a million text files or 10TB of video. Snapshots in btrfs just look like directories. They're subvolumes, and only subvolumes can be snapshotted. I imagine that zfs is slightly different, but with the same overall concept. > My understanding is that when you make a snapshot, you get a copy that > doesn't change which you can somehow use to make backups. You can certainly use snapshots to make backups. The snapshot is already a backup, though stored on the same media. > When the > backup is finished, you can remove the snapshot, and the changes that > were made in the meantime are not lost --- unless you decide to throw > them away when removing the snapshot, in which case you get a rollback. With btrfs at least there is no way to rollback a snapshot. You can of course just "mv a a.old ; mv b a ; btrfs su del a.old" and now your snapshot has replaced the original copy (aside from any files which happen to be open). > > To make things more complicated, I've seen zfs refusing to remove a > snapshot and saying that something is recursive (IIRC), and it didn't > make any sense anymore. So I left everything as it was because I didn't > want to loose data, and a while later, I removed this very same snapshot > without getting issues as before. Weird behaviour makes snapshots > rather scary, so I avoid them now. I couldn't tell you what that means. Perhaps you discovered a bug. Btrfs should always allow you to remove a subvolume (including one created as a snapshot). I believe they can be removed if they're in use, and the effect is similar to removing a file that is in use. > There seems to be some sort of relationship between a snapshot and the > "original" which limits what you can do with a snapshot, like the > snapshot is somehow attached to the "original". At least that makes > some sense to me because no real copy is created when you make a > snapshot. But how do you detach a snapshot from the "original" so that > you could savely modify both? > In btrfs there is no relationship between a snapshot and the original subvolume, other than them happening to share the same tree nodes initially. It isn't unlike what happens in git when you create a new branch. You end up with a new reference pointing to the same commit and everything below that is shared between the two branches initially. If you touch one file then most of trees/blobs between the branches are still shared, but the modified blob and all of its parent trees are now separated. Btrfs does mark snapshots as snapshots for some reason, but other than a yes/no flag snapshots are the same as any subvolume. They're not linked in any way to the original and there is no straightforward way to tell where a snapshot came from (well, other than either comparing it against all the other subvolumes, ideally looking for shared tree nodes). -- Rich
