ZFS zfs receive: "cannot receive incremental stream: destination ... has been modified"

cracauer@

cracauer@

Developer
I have a backup disk with one ZFS pool and a number of filesystems that should receive incremental snapshots.

For some but not all filesystems it refuses with "cannot receive incremental stream: destination ... has been modified". I am sure that I did no such modification, this is purely a backup disk that has never been used to do any work on it. Did this happen to anybody else? What's behind this? Please tell me it is not something silly such as atime having been changed by a find(1) job?

Anyway, assuming this can't be fixed, my only alternative is to send a non-incremental snapshot, which requires to remove the entire target subsystem. Apart from being slow this also has the disadvantage of losing all previously existing snapshots in the backup disk.

Any ideas what the best way to deal with this is?
 
For backup (generated by zfs recv; updated via zfs recv) ZFS filesystems/volumes, I always set the zfs readonly property to on to avoid anything accidentally modifying (including metadata like atime) the filesystem. Additionally, if you don't need the backup mounted, you can just leave it unmounted for another layer of prevention. (Recv with -u, and additionally change the canmount property on the backup filesystems to noauto.)

You can do this because zfs readonly property only prevents changes via the posix layer (i.e. via directories and files), but not updating the filesystem via a subsequent zfs recv. With this set, I've never run into "destination modified" issues. (Which I previously had experienced on filesystems that were mounted and accitentally received meta-data updates.)

That said, you can use zfs-diff(8) to verify what it thinks has changed, and if it is truly a backup filesystem with no changes you wish to keep, use zfs-rollback(8) to return to the latest sent snapshot — the updating incremental send's starting snapshot. When I've run into this issue with accidental updates to a filesystem, this has successfully gotten the system back to a state where it is ready to receive the incremental updates.

N.B.: While there is a flag (-F) to use with zfs-recv(8) that will automatically do this rollback (to be able to perform the incremental receive), it has additional side effects, so I never recommend it. Far better to manually rollback the impacted systems this time, and adjust (readonly=on) properties to prevent the issue, than to bring out the -F hammer.
 
Thank you, Eric. That all makes sense. I wonder why I didn't come across this problem with other arrays, maybe I had atime off.
 
Eric A. Borisch said:
I always set the zfs readonly property to on
Click to expand...
+1
...and canmount="noauto" and *definitely* no imported mountpoints (i.e. they are inherited from the pool/path).
I usually set readonly and canmount at the root dataset that holds backups and the user (usually 'backup') that runs the zfs send|recv backup scripts can't import/change those (most) zfs properties.

(learned some of this the hard way...)
 
You must log in or register to reply here.
Back
Top