@oetiker Maybe it's connected with fact that I've excluded some child dataset. Hmm, znapzend should be able to handle this situation, I guess.
@Dacesilian can you try this patch:
diff --git a/lib/ZnapZend/Config.pm b/lib/ZnapZend/Config.pm
index 6bc4249..c616729 100644
--- a/lib/ZnapZend/Config.pm
+++ b/lib/ZnapZend/Config.pm
@@ -33,7 +33,8 @@ has zfs => sub {
rootExec => $self->rootExec,
debug => $self->debug,
lowmemRecurse => $self->lowmemRecurse,
- zfsGetType => $self->zfsGetType
+ zfsGetType => $self->zfsGetType,
+ zLog => $self->zLog
);
};
has time => sub { ZnapZend::Time->new(timeWarp=>shift->timeWarp); };
Needed to pass a trivial new Mojo::Log object so these tools spam formatted logs to stderr
Thank you, I've compiled current master branch and it is working fine!
rm -r znapzend/
git clone https://github.com/oetiker/znapzend.git znapzend && cd znapzend/
apt-get install perl unzip autoconf carton
./bootstrap.sh
./configure --prefix=/opt/znapzend-master
make
make install
rm /usr/local/bin/znapzend*
for x in /opt/znapzend-master/bin/*; do ln -s $x /usr/local/bin; done
Note: I'm just updating the README in https://github.com/oetiker/znapzend/pull/512/ so thanks for the updated apt-get bit ;)
As for the symlinks, a
ln -f takes care of removing older ones if present, and a GNU ln -r can make relative symlinks that are more meaningful when you juggle many alternate roots and do not want to reference the current OS you are running (most linux systems/scripts do not know the difference... solaris had that for decades, e.g. a file server hosting roots for diskless NFS workstations, so it is sort of a built-in habit)
unfortunately a non-GNU
ln such as in Solaris does not have the -r so explicit ../ have to be prepended
@oetiker : is there something remaining to be resolved urgently in https://github.com/oetiker/znapzend/pull/497/ or can you merge it? :)
Sounds good :)
Got a strange zfs lockup on the laptop: my OI with the pool being backed up is one VM, the USB disk for backups is attached to another, a Linux VM with iSCSI target. That VM eventually claimed some device connection errors and froze, pool over iSCSI timed out but curiously: the pool and its one vdev are both ONLINE but "all operations to the pool are suspended". Zpool clear does not help (nothing to clear, all online), replug of disk and reboot of target and restart of initiator also did not, attempts to reimport the pool and a zpool export -f froze last time I saw... will see it again in the evening. Any ideas insofar? :)
You can probably loop calling it with the --runonce mode, assuming you don't want to change the perl code. I don't think there's much otherwise out of the box - all schedule handlers strive to snapshot their datasets ASAP at the timed trigger, and proceed to replicate and clean up independently of each other.
Three independent setups should be processed by daemonized mode in parallel and I don't think there are now any toggles about that.
They may be processed sequentially or not in --runonce mode however
Certainly would be for
znapzend --runonce=pool/data/set only requesting one data set with a schedule
So in worst case you can certainly shellscript a loop over backup schedules (found by
znapzend list -r pool | grep 'key chars from heading' | awk '{print $4}' iirc) run once one by one.
(also, znapzendzetup confuses my brain a lot XD)
I just want to backup my laptop to my NAS but I couldn't get it to work if the source is encrypted
Hi folks. I'm trying to set up backups from "sosiego" to "thirtythree" using znapzend, where sosiego has its own SSH user on thirtythree. I'm using
--autoCreation, but znapzend doesn't seem to be handling the case where the filesystem can't be mounted after creation cleanly: I get […]
cannot open 'thirtythree/backups/sosiego/mail': dataset does not exist
filesystem successfully created, but it may only be mounted by root
cannot open 'thirtythree/backups/sosiego/mail': dataset does not exist
ERROR: cannot create dataSet thirtythree/backups/sosiego/mail
ah, it seems the filesystems are created as expected and just trying over and over again, gradually all of them are created and everything starts working. Still not optimal ^^