Add --autoCreation to znapzendzetup

[devopstales]

Hello,

Please add --autoCreation option for znapzendzetup to solve frequent vm creation problem with backup.

[ccremer]

Would also love this one @oetiker With dynamically created datasets this would block backups, unless they are created manually on the receiver side:

bash-5.0# znapzend --runonce tank/services/kubernetes --recursive
[2020-05-01 17:54:46.26672] [777] [info] znapzend (PID=777) starting up ...
[2020-05-01 17:54:46.26681] [777] [info] refreshing backup plans for dataset "tank/services/kubernetes" ...
[2020-05-01 17:54:46.69472] [777] [info] running pre-send-command for pve-2.intern:tank/backup/pve-1/services/kubernetes
[2020-05-01 17:54:46.69843] [777] [info] found a valid backup plan for tank/services/kubernetes...
[2020-05-01 17:54:46.69854] [777] [info] running post-send-command for pve-2.intern:tank/backup/pve-1/services/kubernetes
[2020-05-01 17:54:46.70263] [777] [info] znapzend (PID=777) initialized -- resuming normal operations.
[2020-05-01 17:54:46.70327] [777] [debug] snapshot worker for tank/services/kubernetes spawned (787)
[2020-05-01 17:54:46.70434] [787] [info] running pre snapshot command on tank/services/kubernetes
[2020-05-01 17:54:46.70783] [787] [info] creating recursive snapshot on tank/services/kubernetes
[2020-05-01 17:54:46.89611] [787] [info] running post snapshot command on tank/services/kubernetes
[2020-05-01 17:54:46.89964] [787] [info] checking for explicitly excluded ZFS dependent datasets under 'tank/services/kubernetes'
[2020-05-01 17:54:46.93048] [777] [debug] snapshot worker for tank/services/kubernetes done (787)
[2020-05-01 17:54:46.93133] [777] [debug] send/receive worker for tank/services/kubernetes spawned (797)
[2020-05-01 17:54:46.93215] [797] [info] starting work on backupSet tank/services/kubernetes
[2020-05-01 17:54:46.93969] [797] [info] running pre-send-command for pve-2.intern:tank/backup/pve-1/services/kubernetes
[2020-05-01 17:54:46.94353] [797] [debug] sending snapshots from tank/services/kubernetes to pve-2.intern:tank/backup/pve-1/services/kubernetes
cannot receive new filesystem stream: zfs receive -F cannot be used to destroy an encrypted filesystem or overwrite an unencrypted one with an encrypted one
[2020-05-01 17:54:47.54216] [797] [warn] ERROR: cannot send snapshots to tank/backup/pve-1/services/kubernetes on pve-2.intern
[2020-05-01 17:54:47.54228] [797] [debug] sending snapshots from tank/services/kubernetes/pvc-07312430-e79c-443f-b5dd-2e2a5e9fa5a4 to pve-2.intern:tank/backup/pve-1/services/kubernetes/pvc-07312430-e79c-443f-b5dd-2e2a5e9fa5a4
cannot open 'tank/backup/pve-1/services/kubernetes/pvc-07312430-e79c-443f-b5dd-2e2a5e9fa5a4': dataset does not exist
[2020-05-01 17:56:08.35333] [797] [debug] sending snapshots from tank/services/kubernetes/pvc-24312448-0683-4a63-a45a-4d90643feac7 to pve-2.intern:tank/backup/pve-1/services/kubernetes/pvc-24312448-0683-4a63-a45a-4d90643feac7
cannot open 'tank/backup/pve-1/services/kubernetes/pvc-24312448-0683-4a63-a45a-4d90643feac7': dataset does not exist

[ccremer]

My bad, haven't realized it's in 0.20 release. However, it doesn't really work with encrypted datasets. For now, I'll do the very first send/receive manually, after that znapzend can deal with encrypted datasets. cannot receive new filesystem stream: zfs receive -F cannot be used to destroy an encrypted filesystem or overwrite an unencrypted one with an encrypted one

[jimklimov]

Note (at least for users of older releases) that the option can also be set for the daemon/service you can run to snapshot and replicate automatically regularly.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.