I gotta switch to dayjob at some point :-)
thank you
and since the late 90's, never had a chance to say directly: Thank you for the goodnesses of RRD(tool) and MRTG! (by the way)
Would you visit FOSDEM sometime so I can repeat that in person (assuming I'm approved this year too)?
then if not visiting, be sure to have a good family time then :)
@oetiker : I posted some ideas about recursive send into oetiker/znapzend#438 - does that seem reasonable or did I miss something glaring? :-)
also seems oetiker/znapzend#437 can be closed
Hi - just installed znapsend on Arch Linux (installed with ZFS on Root), backing up to FreeNAS. Just a few questions since I'm a little confused about things. I believe I made my first backup correctly, however is there a way to verify? Where is configuration file stored? Web page states in the zfs file structure itself -- so how to read? Although I have the systemd znapzend service started and enabled -- what program is involved with the scheduling? I ran the first task with a runonce command - how to make this run automatically?
settings are stored in zfs properties
Looks like excluded snapshots are being deleted (after https://github.com/oetiker/znapzend/pull/379/files/8e65186d9b8a98502f192c615055d8c35aebf460 ), but we still send them. This causes ERRORs on later runs, since common snapshots are missing). Are we missing some logic?:
--- ZnapZend.pm.dist 2019-11-28 17:07:17.927267363 +0100
+++ ZnapZend.pm 2019-11-28 17:44:33.203399136 +0100
@@ -336,6 +336,22 @@
#from being snapshot/sent by setting property "org.znapzend:enabled"
#to "off" on them
for my $srcDataSet (@$srcSubDataSets){
+
+ # get the value for org.znapzend property
+ my @cmd = (@{$self->zZfs->priv}, qw(zfs get -H -o value org.znapzend:enabled), $srcDataSet);
+ print STDERR '# ' . join(' ', @cmd) . "\n" if $self->debug;
+ open my $prop, '-|', @cmd;
+
+ # if the property does not exist, the command will just return. In this case,
+ # the value is implicit "on"
+ $prop = <$prop> || "on";
+ chomp($prop);
+ if ( $prop eq 'off' ) {
+ $self->zLog->debug('Skipping ' . $srcDataSet . ' due to it being explicitly disabled.');
+ next;
+ }
+
+
my $dstDataSet = $srcDataSet;
$dstDataSet =~ s/^\Q$backupSet->{src}\E/$backupSet->{$dst}/;
Please note the missing "-s local", so it also works on inherited properties in the recursive dataset.
--- lib/ZnapZend.pm.dist 2019-11-29 00:29:36.980904411 +0100
+++ lib/ZnapZend.pm 2019-11-29 00:21:08.546796322 +0100
@@ -615,7 +615,13 @@
# removal here is non-recursive to allow for fine-grained control
if ( @dataSetsExplicitelyDisabled ){
$self->zLog->info("Requesting removal of marked datasets: ". join( ", ", @dataSetsExplicitelyDisabled));
- $self->zZfs->destroySnapshots(@dataSetsExplicitelyDisabled, 0);
+
+ # We need to explicitly call destroySnapshots for each dataSet we found
+ # because it is only designed to destroy sets of snapshots _for the same filesystem_.
+ # Since we are/have a top-level recursive snapshot, recurse here too.
+ for my $dataSetToDestroy (@dataSetsExplicitelyDisabled){
+ $self->zZfs->destroySnapshots($dataSetToDestroy, 1);
+ }
}
}
}As a side note, it think
$self->zZfs->destroySnapshots(@dataSetsExplicitelyDisabled, 0);should have been:
$self->zZfs->destroySnapshots(\@dataSetsExplicitelyDisabled, 0);but my "Perl"-ish is rusty :)
I have Linux hosts that are constantly falling out of sync. I am not sure if the issue is with the send side or remote side, but this is the third time this has happened on a dataset larger than 30TB. It seems like this product is not really production-ready for Linux, at least. Is anyone else having this issue. I feel like my hands are tied and I am going to have to move over to SANOID.
zfs hold [-r] tag snapshot...
Hi this is not directly related to znapzend; but maybe someone have some experience. When I create and clone a snapshot on a windows server, not all files are there - also tried to snapshot and clone while windows server is turned off, so data to "local" disk should have been flushed
[Thu Jan 2 00:01:49 2020] [warn] ERROR: suspending cleanup source dataset because 1 send task(s) failed:
[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
[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
but snapshot seems to be sent :
I am looking for a method to prevent local and remote datasets from falling out of sync due to accidental snapshot deletions by znapzend. I have not had a chance to test this in a lab environment but I intend to. My thinking is that if I place a hold on one or more common starter (full) snapshots created using the "runonce" parameter, that should me to rollback to the starter baseline snapshot should one or more of the subsequent, and more recent, snapshots get mistakenly deleted. While the remote copy would technically fall out of sync, the ability to resync would not be lost. Is this an accurate and true assumption? If not, it would be nice to add this logic to znapzend.
is hold not a solaris only extension ?
Hi..... I want to replicate my encrypted snapshots to a remote pool and have them stored encrypted without the key. I think that just adding -w to the zfs send options is all that's required but znapzend can't set that. Would you be interested in a PR to do that and is there anything to watch out for? Would you think it best just to support -w or have a config setting to set arbitrary extra flags? :)
to keep consistent, an explicit option might be best .. wondering though if the option could be set automatically
but that is probably counter intuitive
Also.... belated thanks for RRDtool, I used that lots in a previous job, very useful! :)