How can I validate a ZFS snapshot image residing on a backup system?

More modern versions of ZFS provide a command named zstreamdump which can provide human-readable information from a stream (or image) created using zfs send.

This is an example using the commandline:

host # zstreamdump < foo.zfs 
BEGIN record
    ...
    toname = zpool/data/foo@04hoursago
    END checksum = 123123123123123123/123123123123123123/asdasdasdasdasd/zxczxczxczxczxc
    ...
    Total write size = 54784 (0xd600)

And an example from FTP:

ftp> get /backups/foo.zfs "| zstreamdump"
BEGIN record
 hdrtype = 1
 ...
 toname = zpool/data/foo@04hoursago
 END checksum = 123123123123123123/123123123123123123/asdasdasdasdasd/zxczxczxczxczxc
 ...

This provides me with the name of the actual snapshot, and a checksum of that snapshot. It will not provide me with a list of files within the snapshot of course, because that information exists at a different layer.

I have not actually tried this on an incremental snapshot created using zfs send -i, but this may be what I want.

I think the problem with your -nv approach was that intermediate filesystems are not created when receiving with -n, and therefore it will fail every time, while it works without the no-op flag (but expanding the complete filesystems may take a long time). Unfortunately, most documentation/blogs online do not use this flag, therefore they never experience this error like you (and I) did.

Also a word of warning from the Solaris Internals ZFS Best Practices Guide:

If you store ZFS send stream on a file or on tape, and that file becomes corrupted, then it will not be possible to receive it, and none of the data will be recoverable. However, Nevada, build 125 adds the zstreamdump(1m) command to verify a ZFS snapshot send stream. See also, RFE 6736794.

Especially with large datasets this means three things:

• If your stream is on storage you don't trust regarding bit safety, you would need to check almost all the time and still live with the risk that a single bit error wipes your whole backup.
• If your stream is on storage you trust (for example on a ZFS volume exported as NFS), you are relatively save, but you miss out on zfs list -r and zfs diff.
• If you have access to native storage (for example, ZFS volume accessed over SSH), you can expand the received filesystems and use the mentioned tools. Also in this case the -v switch works as expected and can be parsed easily.