I've been installing zetaback on my home network. In the process, I've come across several errors and omissions. The first is that make install' repeats the steps that have already been done bymake'. This is a problem if the commands are run by different users. This is caused by missing dependancies in the Makefile. My patch Makefile.in.diff corrects this problem.

Another problem I encountered with the zetaback server is that locking failed with no message. My patch zetaback.in.diff corrects this problem and several others. Zetaback now prints:

Cannot open: /dpool/unix/amd/.list

in this case. Another is that zetaback always prints:

Using custom ssh config file

even if it's not doing that. Finally, zetaback only reports the wait status of failed remote commands. My patch adds three separate `die' messages to indicate different reasons for the failure.

I discovered that I needed to escape slashes in zetaback_agent.conf patterns. This requirement should either be fixed or documented in the man page. I also discovered that there was no way to quote values in zetaback.conf . I needed this ability to enter commands that contained spaces. Again, this bug should either be fixed or documented in the man page.

Did I miss finding another document? We really need one to describe the setup required on the zetaback server and the agent hosts before using zetaback. The setup entails at least six steps, some of which may be new to backup administrators. We also need one to show how to put zetaback into production, and how to do restores when they are required.

Hi!
can anybody explain me how to execute issues with dataset backup?
it was some network outages with my backup server, so i have no backups for since 4 march.
I try to run zetaback backup manually, but i received the next error:

backup@backup-tst:~$ /opt/omni/zetaback/bin/zetaback -ff -b -d -h nfs1.prod.local
Planning 'nfs1.prod.local'
Acquiring lock for nfs1.prod.local:.list
 => Filesystems for nfs1.prod.local (zetaback_agent -l output)
    data/nfs/crm-site.int [__zb_full_1486615036,__zb_incr,__zb_dset_1490710525,__zb_dset_1490710576,__zb_dset_1490710685]
=> No/default class
 => Scanning '/data/nfs/crm-site.int' for old backups of 'data/nfs/crm-site.int'.
 => doing dataset backup
Acquiring lock for nfs1.prod.local:ZGF0YS9uZnMva2V5c3VydmV5LmNvbQ==
Releasing lock for nfs1.prod.local:.list
Using custom ssh config file: -F /opt/omni/zetaback/etc/ssh_config
Receiving to zfs filesystem data/nfs/crm-site.int/ZGF0YS9uZnMva2V5c3VydmV5LmNvbQ--@1490710755
   => ssh -F /opt/omni/zetaback/etc/ssh_config nfs1.prod.local sudo /opt/omni/zetaback/bin/zetaback_agent -z data/nfs/crm-site.int -i 1488603602 -s 1490710755
 => failure zfs_do_backup nfs1.prod.local:data/nfs/crm-site.int s: error: 256 at /opt/omni/zetaback/bin/zetaback line 808. at /opt/omni/zetaback/bin/zetaback line 843.
Releasing lock for nfs1.prod.local:ZGF0YS9uZnMva2V5c3VydmV5LmNvbQ==
Releasing lock for nfs1.prod.local:.list
Acquiring lock for nfs1.prod.local:.list
 => Filesystems for nfs1.prod.local (zetaback_agent -l output)
    data/nfs/crm-site.int [__zb_full_1486615036,__zb_incr,__zb_dset_1490710525,__zb_dset_1490710576,__zb_dset_1490710685,__zb_dset_1490710755]
Releasing lock for nfs1.prod.local:.list

Unless we are restoring a backup to the same host and name from which it originated, we should probably default to excluding the restored backup to avoid backing it up again under the new name.

I'm not sure whether this is really what we want, but in my experience, if I'm restoring under an alternate name, it's so that I can reference something from the backup, and I don't actually want the alternate copy backed up again. I think the fact that the hostname and/or dataset name differ from the original should be a reasonable indicator. In that case, the restore should set the exclude property on the restored dataset as a final step before completion.