Btrfs: Subvolumes and snapshots

Posted Feb 6, 2015 6:41 UTC (Fri) by dlang (guest, #313)
In reply to: Btrfs: Subvolumes and snapshots by JimAvera
Parent article: Btrfs: Subvolumes and snapshots

I think you are slightly misunderstanding the way snapshots work.

When you do a snapshot, you aren't copying all the data into the snapshot. What you are doing is copying a current set of metadata and flagging all the disk blocks as Copy on Write, so that as you continue to use the filesystem, the blocks that make up the snapshot never get changed. If the OS wants to write to that file the filesystem allocates a new block, copies the existing data over to it and then does the modification that the OS asked for.

So if you have a filesystem in a RAID0 stripe set of drives, when you make a snapshot, the snapshot will continue to require both drives.

You would then have to make a complete copy of the files on the filesystem to have it all reside on one drive.

to post comments

Btrfs: Subvolumes and snapshots

Posted Feb 6, 2015 9:40 UTC (Fri) by JimAvera (guest, #100933) [Link] (1 responses)

Well, yes. Creating a snapshot doesn't replicate file data, but that's besides the point. When blocks are striped across all drives, then failure of a single drive causes a total loss.

The idea is to somehow convert selected "backup" snapshots to no longer store anything on a particular drive. It would be like removing one disk from a RAID-0 set, but only for a single specified subvolume. The difference is that blocks on the "removed" drive would be replicated, so other snapshots referencing the same data would still point to the original copy, achieving the desired replication effect.
-----
But such a scheme would only be interesting with two drives; eventually it would create as many copies as drives, which for more than two is excessive.

Btrfs: Subvolumes and snapshots

Posted Feb 6, 2015 9:47 UTC (Fri) by dlang (guest, #313) [Link]

actually, since the blocks include references to other blocks, you would end up with three (or more) copies of the blocks

1. the original set that's split across the two drives

2. the set that has all pointers changed to live on drive1

3. the set that has all pointers changed to live on drive2

and since the pointer changes need to take place each time the data is copied from one drive to another (since the existing blocks will already be in use), each single-drive snapshot would be a full copy of everything.

Also, while snapshots are pretty reliable (since what they do is stop making changes to the blocks currently in use), this code would be doing some major re-writing of blocks it would also be far more fragile.

you would be better of just using a conventional backup program to do a backup of the snapshot, far less risk involved.