oetiker / znapzend

zfs backup with remote capabilities and mbuffer integration.
www.znapzend.org
GNU General Public License v3.0
609 stars 137 forks source link

# at begin of line brakes znapzend config #529

Closed moetiker closed 3 years ago

moetiker commented 3 years ago

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

 #dst_c_plan = 1months=>1days,6months=>1weeks,1years=>1months,5years=>6months
       dst_a = slow/backup/plon/vm-128
  dst_a_plan = 1month=>1day,6months=>1week,1year=>1month,10years=>6months
       dst_b = root@hard:slow/backup/plon/vm-128
  dst_b_plan = 1month=>1day,6months=>1week,1year=>1month,10years=>6months
     enabled = on
     mbuffer = /opt/ooce/bin/mbuffer
mbuffer_size = 1337M

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

jimklimov commented 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).

stale[bot] commented 3 years ago

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.