I plan to backup some of my file systems to a remote server via zfs send. The pool to which I plan to send the backups to is exclusively set up for the backups of my main system. Do I need to have a mirror of drives at the remote location or is zfs clever enough to fix errors at the next call of zfs send?

To clarify: at home I have my main server in which I have two mirrored drives as a zfs pool. Now I want to send the not-replaceable data to an offsite server which also runs an OS with zfs.

The question is if I also need redundancy at the offsite location.

Just suppose zfs scrub finds an error at the offsite location. Would zfs send fix the error?


2 Answers 2


You don't need to have a mirror but doing it will improve reliability of the data stored on the pool.

ZFS won't fix errors if there is no redundancy for the affected data. The disk itself handles bad blocks by replacing them internally so in that sense, yes, sending again a pool will kind of "fix" the issue. I wouldn't bet too much on that and replace a disk having recurring errors though.

Note that the disk won't discover by itself bad sectors, you need to read them. The zpool scrub command is designed to scan a zfs pool for errors.


The Solaris ZFS Best practices document answers this question:

A pool that is not created with ZFS redundancy (RAIDZ or mirror) can only report data inconsistencies. It cannot repair data inconsistencies. A pool created without ZFS redundancy is harder to manage because you cannot replace or detach disks in a non-redundant ZFS configuration.

As zfs send/recv overwrites data (if the correct flags are used), it depends on your situation if this is a concern. For example, if you transfer new blocks every 5 minutes and your main pool dies 2 minutes afterwards, the possibility for corruption is much lower than when the backup pool is only updated once a week, month or even longer.

Hardware availability may also be important: what if your backup disk dies (no problem, you still have the main pool), but you cannot replace it for a day, so multiple planned backups will now fail? Redundancy also helps at the hardware level, not only for data integrity. Of course, this does not matter much if you have two other such machines set up which continue to work.

An alternative for special usecases (only one disk possible because of space or port constraints, pool size less than half of maximum disk size) could be to set copies=2 for the backup pool. This way, the data is internally duplicated in the backup pool (requiring 200% space) and it gives you data integrity, but a hardware fault will still destroy your backup pool. It may nevertheless be useful for long offsite backup storage where only single disks are possible, or for smaller systems. Note that it does not work for existing data, so a full backup afterwards is needed.

Also, a word of warning from the linked 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.

This means, unless you have good reasons not to, you should use send in combination with receive, because only active imported pools can be checked for corruption. If you just want to store the stream (for example, if one destination pool should hold multiple streams at the same time), it is suggested to use zstreamdump to verify integrity.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .