ZFS ZFS snapshots (parent/child relationship - dependencies)

[mokfarg]

I am curious about what happens if a snapshot become corrupted for some reason or another (solar flare who knows!). Does that mean every following snapshot would be unusable? What is the parent/child relationship? What is the safeguards in place to help prevent this? If this is the case would the recommendation be not to keep a long period of snapshots to reduce the chance all changes are lost for long time periods, rather keep shorter time periods?

I know we are to have backups, in which I do however I wish not to be in a situation where i have been taking snapshots for a year and one becomes corrupted near the beginning of that time period in which I have to do a big restore or worse someone does not have those backups any longer.

I don't completely understand how durable/resilant snapshots are or the relationships between them.

 

[skeletor]

First of all, snapshot contains only diff blocks, not whole files. So, if we imagine, that some blocks will be corrupted, so, only part of file which contains this block will be corrupted. But, this file also will not be accessible for you, because of ZFS.

If you want to prevent such situation, you should use a periodical (for example, add job to cron ) scrub of your ZFS pool. Or you can increase number of files copy on ZFS, by setting properties "copies" to copy count

For ZFS it doesn't matter how is big your snapshot. It's towards to corrupted only.
But from other side, less count of big snapshots will use less capacity rather then more count of small snapshots. Also, huge numbers of snapshots will impact to your performance, will decrease it. Summary, you should use less numbers of snapshots.

 

[ralphbsz]

Disclaimer: I have not read or studied the ZFS implementation.

Your question is sort of silly. You ask "... if a snapshot became corrupted ...", and in and of itself that question doesn't make terribly much sense. The way a file system works is roughly as follows. Data is written (typically at the time of file creation), and goes to disk. The file system them creates what's called metadata, which is information about the data. In the simplest example, the metadata might be "/home/mokfarg/foo.bar points at an object with inode number 9876, it is a file, it is 23456 bytes long, it was created last Tuesday, and it is stored on disk /dev/ada12 starting at block 456". Obviously, the real metadata is much more complex. When a file is deleted, the metadata is updated, and it might say "disk /dev/ada12 block 456 is now free, and the directory /home/mokfarg now has one fewer directory entries.

Now, what are snapshots? Really nothing but an interesting game (using smoke and mirrors) with the metadata. For example, if you take a snapshot in the above situation, initially nothing happens. A day later, you modify the file in place (not with an editor, but using a write() system call in the middle). At that point, the metadata might store "In the snapshot, inode 9876 is stored consecutively starting at block 456; in the current version, it contains blocks 456-457, then block 5555, and the rest of the file is on block 459, where it ends". To continue that example, a while later you delete the snapshot, and the metadata might get updated to show that block 458 is now free (since it is no longer used by any file in any snapshot).

So, how can a snapshot become corrupted? Only if the metadata is corrupted. In a file system, that's sort of the largest possible accident. Since the metadata for snapshots has to be integrated with the metadata for the current version, it's hard to imagine a scenario where a snapshot is damaged, and the rest of the system is not. And if the metadata is seriously damaged, repairs are hard.

Skeletor's suggestion of "zpool scrub" is a good one: In order to scrub all disk blocks that hold data and metadata, ZFS has to do a complete walk of all metadata; if there is a skeleton in the closet, it is likely to be found.