[Thu Jan 2 00:01:49 2020] [warn] +--> ERROR: cannot send snapshots to backup/mother/saspool/vms/vm-100-disk-1 on root@pdzfs
[Thu Jan 2 00:01:49 2020] [info] done with backupset saspool/vms in 107 seconds
Haven't found anything specific from ZoL; but if it follows Oracle ZFS ...
https://docs.oracle.com/cd/E19253-01/819-5461/gazss/index.html
...
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"
}
}
}
]
}
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:enabled=true
org.znapzend:source:snapshot:plan=1hours=>15minutes,1days=>1hours,1weeks=>1days,1months=>1weeks,1years=>1months
org.znapzend:source:snapshot:tsformat=%Y-%m-%dT%H:%M:%SZ
org.znapzend:source:snapshot:recursive=true
org.znapzend:source:send:raw=true
org.znapzend:source:send:compressed=true
org.znapzend:source:send:mbuffer:path=/usr/bin/buffer
org.znapzend:source:send:mbuffer:size=1G
org.znapzend:source:send:znap_cmd:pre='echo hello'
org.znapzend:source:send:znap_cmd:post='echo goodbye'
org.znapzend:destination:0:dataset=backup_pool/ROOT/ubuntu
org.znapzend:destination:0:snapshot:plan=1weeks=>1days,1months=>1weeks,1years=>1months
org.znapzend:destination:0:receive:force=true
org.znapzend:destination:0:receive:unmounted=true
org.znapzend:destination:1:dataset=root@bserv:backup_pool/ROOT/ubuntu
org.znapzend:destination:1:snapshot:plan=1months=>1weeks,1years=>1months
org.znapzend:destination:1:receive:force=true
org.znapzend:destination:1:receive:unmounted=true
Still reasonably readable and still objecty like in organization.
so what about:
org.znapzend:dst:<name>
org.znapzend:dst:<name>:sendRaw
org.znapzend:dst:<name>:plan
etc....
the current org.znapzend:dst_<name> could be read as org.znapzend:dst:<name> for backwards compatibility
