1 |
On Thu, Jan 21, 2016 at 5:00 PM, lee <lee@××××××××.de> wrote: |
2 |
> Hm, I must be misunderstanding snapshots entirely. |
3 |
> |
4 |
|
5 |
Well, in the case of zfs/btrfs you are. Different implementations |
6 |
have different snapshotting features. |
7 |
|
8 |
> What happens when you remove a snapshot after you modified the |
9 |
> "original" /and/ the snapshot? You destroy at least one of them, so you |
10 |
> can never get rid of the snapshot in a non-destructive way? |
11 |
|
12 |
If you remove a snapshot it goes away. If you remove the original it |
13 |
goes away. There isn't anything strange going on. |
14 |
|
15 |
With btrfs I can do this: |
16 |
|
17 |
btrfs su create a |
18 |
touch a/file |
19 |
btrfs su snap a b |
20 |
touch b/file2 |
21 |
echo "hello" >> a/file |
22 |
|
23 |
a now contains file with the text hello in it. b now contains file |
24 |
which is empty and file2 which is empty. |
25 |
|
26 |
If I delete a then it disappears. If I delete b then it disappears. |
27 |
They exist completely independently of each other. |
28 |
|
29 |
In btrfs the command "btrufs su snap a b" is somewhat equivalent to |
30 |
"cp -a a b" unless you look at what is going on closely. The main |
31 |
difference is that the first command takes almost zero time to |
32 |
execute, and consumes little additional space. This is true even if a |
33 |
is a directory containing a million text files or 10TB of video. |
34 |
|
35 |
Snapshots in btrfs just look like directories. They're subvolumes, |
36 |
and only subvolumes can be snapshotted. I imagine that zfs is |
37 |
slightly different, but with the same overall concept. |
38 |
|
39 |
> My understanding is that when you make a snapshot, you get a copy that |
40 |
> doesn't change which you can somehow use to make backups. |
41 |
|
42 |
You can certainly use snapshots to make backups. The snapshot is |
43 |
already a backup, though stored on the same media. |
44 |
|
45 |
> When the |
46 |
> backup is finished, you can remove the snapshot, and the changes that |
47 |
> were made in the meantime are not lost --- unless you decide to throw |
48 |
> them away when removing the snapshot, in which case you get a rollback. |
49 |
|
50 |
With btrfs at least there is no way to rollback a snapshot. You can |
51 |
of course just "mv a a.old ; mv b a ; btrfs su del a.old" and now your |
52 |
snapshot has replaced the original copy (aside from any files which |
53 |
happen to be open). |
54 |
|
55 |
> |
56 |
> To make things more complicated, I've seen zfs refusing to remove a |
57 |
> snapshot and saying that something is recursive (IIRC), and it didn't |
58 |
> make any sense anymore. So I left everything as it was because I didn't |
59 |
> want to loose data, and a while later, I removed this very same snapshot |
60 |
> without getting issues as before. Weird behaviour makes snapshots |
61 |
> rather scary, so I avoid them now. |
62 |
|
63 |
I couldn't tell you what that means. Perhaps you discovered a bug. |
64 |
|
65 |
Btrfs should always allow you to remove a subvolume (including one |
66 |
created as a snapshot). I believe they can be removed if they're in |
67 |
use, and the effect is similar to removing a file that is in use. |
68 |
|
69 |
> There seems to be some sort of relationship between a snapshot and the |
70 |
> "original" which limits what you can do with a snapshot, like the |
71 |
> snapshot is somehow attached to the "original". At least that makes |
72 |
> some sense to me because no real copy is created when you make a |
73 |
> snapshot. But how do you detach a snapshot from the "original" so that |
74 |
> you could savely modify both? |
75 |
> |
76 |
|
77 |
In btrfs there is no relationship between a snapshot and the original |
78 |
subvolume, other than them happening to share the same tree nodes |
79 |
initially. It isn't unlike what happens in git when you create a new |
80 |
branch. You end up with a new reference pointing to the same commit |
81 |
and everything below that is shared between the two branches |
82 |
initially. If you touch one file then most of trees/blobs between the |
83 |
branches are still shared, but the modified blob and all of its parent |
84 |
trees are now separated. |
85 |
|
86 |
Btrfs does mark snapshots as snapshots for some reason, but other than |
87 |
a yes/no flag snapshots are the same as any subvolume. They're not |
88 |
linked in any way to the original and there is no straightforward way |
89 |
to tell where a snapshot came from (well, other than either comparing |
90 |
it against all the other subvolumes, ideally looking for shared tree |
91 |
nodes). |
92 |
|
93 |
-- |
94 |
Rich |