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