Updated Common snapshots and holds (markdown)

DatuX
2022-04-28 17:54:33 +02:00
parent e705a50fbb
commit c98c16feac

@ -14,7 +14,7 @@ There are a few rules for ZFS however:
* There cant be any newer snapshots on the target. (Normally should not happen, otherwise use --destroy-incompatible)
* Encryption has to be compatible (See [[Encryption]])
If there is no snapshot in common, the only way to continue is to destroy all the whole dataset (and all its snapshots) on the target and start from a full backup.
**If there is no snapshot in common, the only way to continue is to destroy all the whole dataset (and all its snapshots) on the target and start from a full backup.**
## Holds to the rescue
@ -28,9 +28,15 @@ If you know what you're doing you can use --no-holds.
Normally when you split up the snapshotting part and backupping part you would do it like this: [[https://github.com/psy0rz/zfs_autobackup/wiki#splitting-up-snapshot-and-backup-job]]
The snapshotter will still connect to the target server and figure out the common snapshot so that it wont be deleted. It can also cleanup old snapshot from the source if it determines the target doesnt need them (anymore)
The snapshotter will still connect to the target server and figure out the common snapshot so that they wont be destroyed. It can also cleanup old snapshots from the source if it sees that target doesn't need them (anymore)
However, if you have an offline backup (e.g. a USB disk that you sometimes connect), you are force to use the snapshot-only tool. You would just run zfs-autobackup without specifying a target dataset or ssh-target.
In this case the holds are more important: Now the tool looks at the holds to see which snapshots are common. Otherwise it might accidentally destroy them if you have a tight --keep-source schedule.
However, if you use the snapshot-only mode, the snapshot tool cant "see" the target machine.