Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
Repo info
James Crocker
Hello - am enjoying znapzend! I've encrypted datasets and was messing with the code base to support sending raw streams only to do a fresh pull and see the sendRaw feature - yeah! So, while I don't have to continue pursing enabling that feature myself - I'm still looking at how best to manage the ZFS pools for send/recv. Specifically, I really like that the 'config' is stored in the zfs properties - keeping everything nicely self-contained. However, 'features' are not stored along with the other org.znapzend ZFS properties. Currently then, to enable the sendRaw feature it must be passed to the $ZNAPZENDOPTIONS for the znapzend.service unit's ExecStart (and/or configured in an EnvironmentFile). Consequently if I want one particular pool to sendRaw, while another doesn't, it would require creating multiple service unit files with or without the --featrues options sent to znapzend. I'd like take on the task of embedding the features as org.znapzend property and reference it when znapzend is called - perhaps allowing the cli --features to override any ZFS org.znapzend:features property. But, I thought before I invest any goodly time and effort to do so - Were there any reasons that the cli --features option is not already stored as an ZFS org.znapzend:features property for the datasets? Thanks!
Tobias Oetiker
yes having features per-destination would be great we just have no found a good sustainable way to have that yet. but maybe adding a per dest feature property with key value pairs might be a nice way of doing it ...
another much more radical aproach we thought about was to have the config as json, base64 encode it and store it in a buch of properties (no sure how much data a single property can take)
note that some features will be per source, some per dest
a pr for that would be great
James Crocker

Haven't found anything specific from ZoL; but if it follows Oracle ZFS ...

User property names must conform to the following conventions:
-They must contain a colon (':') character to distinguish them from native properties.
-They must contain lowercase letters, numbers, or the following punctuation characters: ':', '+','.', '_'.
-The maximum length of a user property name is 256 characters.

The values of user properties must conform to the following conventions:
-They must consist of arbitrary strings that are always inherited and are never validated.
-The maximum length of the user property value is 1024 characters.

So, a json config may bump up to the max length sooner than later.

And regardless, imho, it's nice to be able to review/see the zfs property values in human readable form - without having to jump through hoops to decode a base64 string. And, even if json stored plain-text, it would be challenging to quickly parse visually.

For what it's worth - is this sort of the thought on a json config?

{ "source": { "enabled": true, "dataset": "rpool/ROOT/ubuntu", "snapshot": { "set_property": "property1=value1,property2=value2", "tsformat": "%Y-%m-%dT%H:%M:%SZ", "plan": "1hours=>15minutes,1days=>1hours,1weeks=>1days,1months=>1weeks,1years=>1months", "recursive": true }, "send": { "raw": true, "compressed": true, "mbuffer": { "path": "/usr/bin/mbuffer", "size": "1G" }, "znap_cmd": { "pre": "echo hello", "post": "echo goodbye" } } }, "destinations": [{ "dataset": "backup_pool/ROOT/ubuntu", "snapshot": { "plan": "1weeks=>1days,1months=>1weeks,1years=>1months", "receive": { "force": true, "unmounted": true, "set_property": "property1=value1,property2=value2" } } }, { "datasets": "root@bserv:backup_pool/ROOT/ubuntu", "snapshot": { "plan": "1months=>1weeks,1years=>1months", "receive": { "force": true, "unmounted": true, "set_property": "property1=value1,property2=value2" } } }, { "datasets": "root@bserv2:backup_pool/ROOT/ubuntu", "snapshot": { "plan": "1years=>1months", "receive": { "force": true, "unmounted": true, "set_property": "property1=value1,property2=value2" } } }, { "datasets": "root@bserv3:backup_pool/ROOT/ubuntu", "snapshot": { "plan": "1hours=>15minutes,1days=>1hours", "receive": { "force": true, "unmounted": true, "set_property": "property1=value1,property2=value2" } } } ] }

Tobias Oetiker
yes something along these lines ... but the points you listed are somethinf which prevented us from takeing that route
James Crocker
And just FYI I did put that json into a zfs property to see what it'd look like... The wc -c character count on that json is 1193 - So, ZoL property values can apparently exceed 1024 char. But, as discussed challenging to read on a zfs get all - and throws off the output a bit too. The ZoL zfs property name is constrained to 256 chars.
James Crocker

So, the 256 char allowed for zfs property name is quite expansive. What if - a pseudo like json zfs property? Something like

org.znapzend:source:send:znap_cmd:pre='echo hello'
org.znapzend:source:send:znap_cmd:post='echo goodbye'

Still reasonably readable and still objecty like in organization.

Tobias Oetiker
and then the values 256 should make for quite some depth
yes, that looks better.... the options are really all destination related though (you might want to send raw to one destination and not another) so the send options could be specified for each destination

so what about:

the current org.znapzend:dst_<name> could be read as org.znapzend:dst:<name> for backwards compatibility

(and org.znapzend:dst_<name>_plan -> org.znapzend:dst:<name>:plan too)
Tobias Oetiker
yes going all : makes sense
When running znapzend in debug mode, there is some output that reads [debug] cleaning up snapshots on poolname/dataset. Which datasets are being deleted and how are they being selected by znapzend?
Tobias Oetiker
according to your retention rules for the source
I'm sorry to possibly hijack the chat with a technical question, but is there a way to have znapzend initiate the replication portion of the festivities from the remote server? Similar to what you can do with zrep? I think I'd like to help with some documentation and use cases if this is possible.
My use case is that I'd like my backup vault to have privileges to pull but not have any other server with write access to push in.
Tobias Oetiker
if you can describe your scenario in more technical terms, I might be able to suggest ...
ahhhh :)
I have all my zvols encrypted, and would be doing snapshots / backups raw, such that the backup machine could pull without ever having the keys
Tobias Oetiker
at the moment znapzend can not be reversed ... the idea is that the live copy is the most valuable and may thus not be accessed from the outside ... there has been talk about possibilities to reverse the logic, but no one with coding abilities and design abilities has kept at it ...
gotcha. yeah, i just found the open request on github
Tobias Oetiker
znapzend master has support for backup of encrypted volumes
(so that they stay encrypted at the remote end)
I saw that - the raw flag is exactly what I needed
the code is mostly python, right? the last scripting stuff I did was perl waaaay back in the day
Tobias Oetiker
the code is all perl
What would budget be to contribute to the project and help implement this?
I just don't have the time right now, but I'm in a place in my life where I'm no longer surviving on ramen...
Tobias Oetiker
the first step would be to open an issue (or maybe there is already one) and propose a design on how this would work on a logical and configuration level
yes the time issue ... that seems to be everybodies problem these days ... mine too
Alright, let me check out the code and see if I can conceptualize how this would work.
for reference this is how zrep does it, but the backend architecture is different I'm sure
Hi :)
I have a question I can't figure out the answer to, I've setup znapzend, and it works. I am wondering though, how do I configure the features? like --features=skipIntermediates,compressed ?
Jonathan Duggan
Hey guys - is there any literature anywhere on integrating or somehow monitoring a znapzend environment ? i have an environment of around 30 sans currently using homebrew scripts & sending info to a central api for a webfrontend to quickly overlook. its turned into a huge chore so keen to move to something like zsnapzend but wondering if such a thing exists already for the monitoring side ?
Tobias Oetiker
there is no such document, but basically you can parse syslog output
Hi I get this error when I try to modify and list : zLog must be specified at creation time
Having the same. Is this because it can't connect to syslogd?
Carsten Härle

What does the znapzend 20.0 error message mean?

cannot send 'xxxxxx': I/O error
ERROR: cannot send snapshots to xxxxx on yyyy
send/receive for data1 failed: Can't call method "message" without a package or object reference at /usr/lib/x86_64-linux-gnu/ZnapZend.<

Hi, in lib/ZnapZend.pm $refreshBackupPlans is called during init. That sub creates (to be replicated) zfs datasets at the destination if they don't exist. However the pre-send-command and post-send-command's (if set and not off) are also executed. I find this a bit misleading because the documentation describes a valid example (bringing a zpool online) but other use cases come to mind, like running some job against the transferred snapshot. But that like the parameter name implies, run that job only before and after zfs send do not run it after "refresh" Yes the environment variable WORKER is appended with "-refresh" to distiguish both cases but that's nowhere documented.
Please let me know whether you want the documentation updated or split the pre/post-send-command in the "refresh" and send versions. Which is a bit cleaner than checking some environment variable for a string.
Tobias Oetiker
if you have an idea on how to make this cleaner without breaking existing implementations ...
otherwise improvements for PR the documentation will be fine
Now a design question. Why does the pre/post-snap-cmd includes the snapshot name in an environment variable for the scripts and the pre/post-send-cmd doesn't?
Now the script doesn't know which snapshot was send. I can think of various (edge) cases where something might have changed between the actual send and executing the script. I've hacked this variable in the various sub's to get it from $createSnapshot via the workers to $sendRecvCleanup. If interested I could create a pull request.
I need post processing of the send snapshot, not a snapshot. Another snapshot might have been created, this one might have been deleted. So just processing the last snapshot won't do it. Processing get's done in [dataset]/.zfs/snapshot/[snapshot name]
@oetiker , unfortunately I don't. But I was hoping that you might see a solution.