Closed moetiker closed 3 years ago
Practical suggestion: My exploits in this area were IIRC to rename the value into a pattern that znapzend does not pick up, like disabled_dst_a
and disabled_dst_a_plan
for a destination that I know won't be accessible for a while. When that dest comes back, I can rename the attributes back to bring them to life.
Otherwise, yes seems like a bug (at least, destroying the config with no way to restore its previous status... probably new attr values should be written, removed attrs removed afterwards, but even that is far from atomic).
I am not sure however whether znapzend
should parse the strings and make assumptions about what values (bytes, lengths, etc.) are "valid" for the current ZFS version on the host, it is for the OS to decide really. It might warn about "fishy" inputs though, and re-ask for confirmation.
Notably, #
is a separator for bookmarks in ZFS versions that have them (#514).
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.
I thought I could add # on a not used entry with znapzendzetup edit
The config can be saved but it removes all entries and can not changed with znapzendzetup any more...
plon:~# znapzendzetup edit fast/vm backup plan: fast/vm
dst_c = root@naire:tank-a/backup/plon/vm-128
post_znap_cmd = off pre_znap_cmd = off recursive = on src = fast/vm src_plan = 3weeks=>1day,3months=>1week tsformat = %Y-%m-%d-%H%M%S
Do you want to save this backup set [y/N]? y cannot set property for 'fast/vm': invalid property 'org.znapzend:#dst_c' ERROR: could not set property #dst_c on fast/vm plon:~# znapzendzetup edit fast/vm zLog must be specified at creation time!
only the two zfs properties are left.
fast/vm org.znapzend:dst_b root@hard:slow/backup/plon/vm-128 local fast/vm org.znapzend:post_znap_cmd off local