The dangerous "side effect" of zfs recv -F

[frenziedengi]

I am trying to understand zfs send and zfs recv options.

When reading the documentation for sending incremental zfs replication streams (e.g. zfs -RI @fooey1 blah@fooey2) I noticed that the document says there is a special interpretation to the "-F" switch on the receive side:

"If receiving an incremental replication stream (for example, one generated by zfs send -R -[iI]), destroy snapshots and file systems that do not exist on the sending side."

I am trying to understand... What is the logic behind this? Why is it specific to this particular use case? Why have this feature at all? If you are trying to send only the differences between snapA and snapB, and you happened to delete a filesystem, why would this go and delete the filesystem on the target? You will lose all your history/snapshots... all of your data in that filesystem. It seems like there should be a separate switch for this. One to rollback the receiving target to the common snapshot, and another to allow destruction of file systems on the receiving side.

Am I making sense?

Obviously, the way around this behavior would be to not use "-F" option, perform a manual rollback on the target (if necessary) to the latest common snapshot, and then send the incremental replication stream...

Or, the other take away might be: Be really careful when you decide it is time to destroy a zfs data set / filesystem, because there might not be any going back (depending on how you replicate to remote systems).

 

[cyberjock]

I'm gonna comment partly because nobody else has.

The ZFS code is the same code that is part of FreeBSD. Like it or hate it, its the same version FreeBSD 8.3 has. It's generally a waste of time to try to change things that you don't like about the FreeBSD source. There can be unintended consequences for trying to hackjob and remove stuff that you think is stupid/useless.

Second, I'm betting there is a very good use-case for the -F parameter, although I'm not sure when that would be. Although I'm very curious as to who has a good handle on the answer and will provide it...

 

[frenziedengi]

I'm gonna comment partly because nobody else has.

The ZFS code is the same code that is part of FreeBSD. Like it or hate it, its the same version FreeBSD 8.3 has. It's generally a waste of time to try to change things that you don't like about the FreeBSD source. There can be unintended consequences for trying to hackjob and remove stuff that you think is stupid/useless.

Second, I'm betting there is a very good use-case for the -F parameter, although I'm not sure when that would be. Although I'm very curious as to who has a good handle on the answer and will provide it...

To clarify, I am not at all inferring that I think FreeNAS is wrong... I am more trying to understand the use case and the "best practices". Very often I see people using the "-F" option on the receive side, mostly for the convenience of the automatic rollback, but I wonder if they realize that it can nuke their data history if they are not careful...

 

[studentism]

I wonder if they realize that it can nuke their data history if they are not careful...

I feel really, really awful zombie-ing a thread, but seeing as how I arrived here from a Google search, I feel like having an actual answer here is worthwhile for posterity's sake.

"zfs send" exists to replicate pools, which is particularly handy for backup purposes. if one intentionally deletes a pool or snapshot, that deletion should be reflected on the replicated data set--right? That's exactly what this does.

OTOH, if one inadvertently deletes a pool or snapshot, why would one replicate that error to the backup server(s)? Restore from the good data set (i.e., swap the zfs send/zfs recv targets). Replicating the bad data set literally overwrites your "good" copy of the data.

If pools are being deleted inadvertently without your knowledge, you've got some more serious problems to deal with.