1 |
lee <lee@××××××××.de> wrote: |
2 |
|
3 |
> Rich Freeman <rich0@g.o> writes: |
4 |
> |
5 |
> > On Tue, Jan 19, 2016 at 5:22 PM, lee <lee@××××××××.de> wrote: |
6 |
> >> "J. Roeleveld" <joost@××××××××.org> writes: |
7 |
> >> |
8 |
> >> How does that work? IIUC, when you created a snapshot, any changes you |
9 |
> >> make to the snapshotted (or how that is called) file system are being |
10 |
> >> referenced by the snapshot which you can either destroy or abandon. |
11 |
> >> When you destroy it, the changes you made are being applied to the |
12 |
> >> file system you snapshotted (because someone decided to use a very |
13 |
> >> misleading terminology), and when you abandon it, the changes are thrown |
14 |
> >> away and you end up with the file system as it was before the snapshot |
15 |
> >> was created. |
16 |
> >> |
17 |
> >> In any case, you do not get multiple versions (which only reference the |
18 |
> >> changes made) of the file system you snapshotted but only one current |
19 |
> >> version. |
20 |
> >> |
21 |
> >> Do you need to use a special file system or something which provides |
22 |
> >> this kind of multiple copies when you make snapshots? |
23 |
> >> |
24 |
> > |
25 |
> > And that is exactly what zfs and btrfs provide. Snapshots are full |
26 |
> > citizens. If I create a snapshot of a directory in btrfs it is |
27 |
> > essentially indistinguishable from running cp -a on the directory, |
28 |
> > except the snapshot takes only seconds to create almost entirely |
29 |
> > regardless of size, and takes almost no space until changes are made. |
30 |
> > Later I can delete the snapshot, or delete the original, or keep both |
31 |
> > indefinitely making changes to either. |
32 |
> |
33 |
> Hm, I must be misunderstanding snapshots entirely. |
34 |
> |
35 |
> What happens when you remove a snapshot after you modified the |
36 |
> "original" /and/ the snapshot? You destroy at least one of them, so you |
37 |
> can never get rid of the snapshot in a non-destructive way? |
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. When the |
41 |
> backup is finished, you can remove the snapshot, and the changes that |
42 |
> were made in the meantime are not lost --- unless you decide to throw |
43 |
> them away when removing the snapshot, in which case you get a rollback. |
44 |
> |
45 |
> To make things more complicated, I've seen zfs refusing to remove a |
46 |
> snapshot and saying that something is recursive (IIRC), and it didn't |
47 |
> make any sense anymore. So I left everything as it was because I didn't |
48 |
> want to loose data, and a while later, I removed this very same snapshot |
49 |
> without getting issues as before. Weird behaviour makes snapshots |
50 |
> rather scary, so I avoid them now. |
51 |
> |
52 |
> There seems to be some sort of relationship between a snapshot and the |
53 |
> "original" which limits what you can do with a snapshot, like the |
54 |
> snapshot is somehow attached to the "original". At least that makes |
55 |
> some sense to me because no real copy is created when you make a |
56 |
> snapshot. But how do you detach a snapshot from the "original" so that |
57 |
> you could savely modify both? |
58 |
|
59 |
In zfs you can clone the snapshot and it will be independent, but I am |
60 |
new at zfs, so check it out. |
61 |
|
62 |
-- |
63 |
Your life is like a penny. You're going to lose it. The question is: |
64 |
How do |
65 |
you spend it? |
66 |
|
67 |
John Covici |
68 |
covici@××××××××××.com |