You are not logged in.
My excuses, we already included that option. It's listed in the Man Page:
[url]https://33hops.com/xsibackup-help-man-page.html#shutdown-wait[/url]
TO EXTEND THIS POST's EFFECTIVITY:
It's a general misconception to believe that when you run a remote job by means of the --host argument, the execution control is returned to the master server. We don't state that, we never fed that belief, and we try to fight it as fiercely as we can, but still many people just want to believe it works like that.
When you run a remote job by means of the --host argument, execution control is passed on over to the remote host. So, when the remote job ends, should it have an --on-success and/or --on-error event handlers, the remote XSIBackup installation, and not the one it came from, will look in the remote server's xsibackup-cron file, whether a backup job with the referenced Id exists to be chained.
If after reading this, yo still think you have an issue with the event handlers, please, open a ticket, as these matters are a bit difficult to track with just some comments and very little details.
Thank you for your feedback.
You can easily tweak that in the script, but we will take this as a feature request for next main release.
If it was not turned off, it would not be a test, but just printing some texts on your screen.
The provided information is confusing and is not enough to track the eventual problem down, so please, open a ticket with the support department and provide detailed information.
You should not run an interactive job while a scheduled job is running. XSIBackup is not designed to cope with that situation and the behaviour you describe is normal. Each job creates a unique .ERR file.
You are getting some nasty gross errors from your server. This uncontrolled errors are affecting XSIBackup execution. If you think everything is OK with your ESXi host, then we have nothing else to say.
You are considering a derived error as the most significant one, when it's right the opposite.
Your datastores are disconnected from the host, and you are getting this errors:
ls: /vmfs/volumes/406984e4-03e13517-bd9f-97387cb15ab7: Input/output error
ls: /vmfs/volumes/5acf14db-5a4338e1-ca54-509a4c7ebfdb: Input/output error
ls: /vmfs/volumes/db650dec-b44f9b39-938a-58ef2d0a6d43: Input/output error
The arithmetic syntax error is just a consequence of your devices being offline, check your switch and cables.
If you use --host combined with --on-error, --on-success, you will need to escape the GT symbol. But subsequent job will not be sought in the host where the --host job is being launched from, but in the host where the --host argument points to.
We're sorry but we are not getting you.
How come a job that wasn't launched delete a file?
Yes, please, read this post: [url]https://33hops.com/persistent-esxi-crontab-xsibackup-extended-cron.html[/url]
Service has been re-stablished.
Thank you for your understanding.
It's a bug in our website, we are working on it now. If you need the package urgently write to support.
Sorry about the inconvenience.
That's probably due to using different IPs to reach the Internet for HTTP and ESXi host.
It's not a big deal, the easiest way to workaround is to just download the package and install manually.
It's a trivial operation, just uncompress and assign permissions. Yo have detailed instructions on the steps and commands to use in the README.txt file.
As per our preeliminary tests and user feedback, it seems last XSIBACKUP-PRO version is compatible. So, we will be launching an officially enabled version in short. In the meanwhile, you can enable ESXi 6.7 on your own by editing the main xsibackup file as explained above.
We have been testing the crontab for years, you can fall into different issues, which are generally easy to fix.
Read this: [url]https://33hops.com/xsibackup-cron-how-to.html[/url]
You can verify that the crontab is working by adding something like
echo "Hello World!" At the top of your xsibackup-cron file. You can then use a tail -f
tail -f /vmfs/volumes/datastore1/xsi-dir/xsibackup-cron.logAnd you will se a "Hello World!" printed out in screen every minute.
If that should not happen, then restart your cron service or reboot the host if nothing else works.
#Stop crond service
/bin/kill -9 $(cat /var/run/crond.pid)
#Start crond service
/usr/lib/vmware/busybox/bin/busybox crondUPDATE: run that very same backup but launching it from the other side instead of launching from master and then making it write back to master. Just for testing purposes.
1 - Yes, that backup topology is perfectly doable. Your logs show the signs of a clogged environment. You will need to determine why Rsync just hangs. To be more precise, I never saw Rsync hanging, but it behaves like that when it runs out of resources. XSIBackup launches Rsync and coordinates different binaries, but the cause of an Rsync TCP transfer freezing has to do with what's going on at the TCP and OS level. Clogged switch or NICs? ESXi server running out of memory or CPU?
In any case, before trying to set up some complex backup topology, I would just try some simpler ones, to at least have an overview of how your hardware is behaving under a simpler scenario.
2 - Just as long as you stick to compatible hardware versions, no problem.
3 - XSIBackup tries to determine what's the remote installation point. If it doesn't find one, or if it finds more than one, it then tries to use the value parsed in --remote-xsipath; if this last value is not parsed, then it tries the value hardcoded at conf/xsiopts (/vmfs/volumes/datastore1/xsi-dir), and if after all this it can't find a plece where to copy the files, it does at the root, which BTW is not persistent. So,... check that you have a datastore1, and if you don't, look for an alternative place in your system that is persistent accross reboots. Once you know where to place files, use that path, i.e.: /vmfs/volumes/my_persistent_ds/xsi-dir
4 - Now we know you are over a WAN, we can add it as the most suspicious cause of the problem. We usually run backups and move VMs over FO without much problems, although effective transfer speeds fall down to real available bandwidth between two given points. Try to use a network monitoring tool to check your WAN stability and also try to find out if your ISP might be reducing your available bandwiths under some conditions.
Just run your backup under a reliable LAN and then again through your WAN to compare, I don't think it's your backup job that stalls, but your WAN.
Off course it can be done with REGEX. You just need to create your matching expression.
Learning Regular Expressions is easy, but as everything it takes some time and a learning curve.
You can start here: [url=https://regexone.com/]Regexp tutorial[/url]
You can select VM by means of a Regular Expression as described in the product's man page: [url=https://33hops.com/xsibackup-help-man-page.html#backupvmsregexp](c)XSIBackup-Classic Man Page[/url]
Oops, fixed!
Yes, it will fallback to Rsync.
Use OneDiff, although it will not offer you checksum check upon backup completion, which is highly recommendable.
Or just backup the whole VM each time.
XSIBackup-Free is a great tool for home use and learning, but if you have a 1tb. .vmdk file and you want enterprise level cinfidence in your data, I would just by Pro version. It's a perpetual license and you will still have upgrades during one year.
[url]https://33hops.com/xsibackup-pro-vmware-esxi-backup.html[/url]
Yes, it's just a escaping issue, as the parenthesis are parsed over an SSH tunnel. We will improve support to make escaping as avoidable as possible in future release.
You can buy it in the product page: [url]https://33hops.com/xsibackup-pro-vmware-esxi-backup.html[/url]
Upgrading is fairly easy, just keep your RSA keys and /conf files. You have a detailed procedure in the README.txt file of the Pro version, it's a 1 min. operation.
Will be solved in next version 10.3.4, there's an easy fix in the meanwhile: [url]https://33hops.com/forum/viewtopic.php?id=212[/url]
It's a false positive related to the host's config backup, which was removed from the free version in v. 10.3.0
We will fix this issue in next release.