You are not logged in.
We really don't know what's the point in your argument.
So, you always used backup software that sent notifications when it was not working?.
Your issue is most probably related to your cron service, so we find it a bit difficult that any e-mails could be sent.
By the way, the crond service is ESxi's cron, but there isn't any reason why it shouldn't work, unless something wen't wrong in the reboot.
Inspect the [b]/etc/rc.local.d/local.sh[/b] file, it should look like this.
If it does not, maybe it's due to the crontab having been edited manually and your changes having been lost in the reboot.
#!/bin/sh
# local configuration options
# Note: modify at your own risk! If you do/use anything in this
# script that is not part of a stable API (relying on files to be in
# specific places, specific tools, specific output, etc) there is a
# possibility you will end up with a broken system after patching or
# upgrading. Changes are not supported unless under direction of
# VMware support.
# Note: This script will not be run when UEFI secure boot is enabled.
"/vmfs/volumes/datastore1/xsibackup-dir/src/cron-init" root
exit 0You need to manually re-add the independent disk to the .vmx file. Our software prepares the VM to be switched on, it cannot asume it will find a disk it could not backup.
You said:
[b]"On Saturday, we had a power outage midway through one of the backups"[/b]
And then
[b]"It's been up 3 days now, and the nightly backups have not resumed. That is a very bad sign for a backup solution"[/b]
Haven't you thought of the possibility that the outage caused some additional trouble that you need to fix?, that is not a trivial incident for a server.
- Make sure that your cron service is running and is loaded just once.
- Check that the ESXi crontab is O.K.
[url=https://33hops.com/xsibackup-cron-troubleshooting.html](c)XSIBackup Classic: troubleshooting the (c)ESXi cron[/url]
It's a lot easier than that, use [b]--backup-type=running[/b] or [b]--backup-type=all[/b]
Please, read the Man Page before asking for help.
[url=https://33hops.com/xsibackup-help-man-page.html](c)XSIBackup Classic Man Page[/url]
Independent disks cannot be backed up, as they are not affected by snapshots. That applies to other software too:
[url=https://www.veritas.com/support/en_US/article.100024362]Backup of independent disks[/url]
You must backup that content from within the guest OS.
[b]Random Thoughts[/b] kindly pointed you to that document up in this thread.
A Google search by "xsibackup 11 crontab" returns the same URL
If you use the application interactively, the output is sent to the screen. That is the very same information that will be logged when you use it from a crontab.
Isn't that exactly what's explained here?: [url=https://33hops.com/xsibackup-free-11-things-that-have-changed.html](c)XSIBackup Classic: changes in version 11.0.0[/url]
Add your SMTP servers in the [b]conf/smtpsrvs[/b] file and test them with this command:
./xsibackup --check-smtp=some@email.com --use-smtp=NWhere [b]N[/b] is the sequence number in the first field of the [b]conf/smtpsrvs[/b] file.
Then use it in your backup job by invoking the SMTP server this way
... --mail-to=some@email.com --use-smtp=NThank you for the feedback, you have that information in the first page of the manual:
[url]https://33hops.com/xsibackup-pro-gui-manual.html#1[/url]
[url]https://33hops.com/user-login.html[/url]
Don't worry much, only the wisest entangle in apparently stupid problems. This doesn't explain why your rules were not being added, it doesn't matter what port the remote server uses, the rule must be added to the ESXi firewall.
Please, note that you have left this in in your rule:
<port>587</port>XSIBackup actually uses nc to probe the SMTP servers. Supposing that you are testing the server with nc from the same ESXi shell, try to tweak the timeouts at the header of the src/sendmail module.
XSIBackup never supported SSL, just TLS, so yes, that is an issue, SSL is insecure and has been deprecated by most ISPs. Use some other server.
To get out of that prompt, which is the bash continuation, type [b]Ctrl+d[/b]
You are pasting some unknown character, type the command manually to make sure that you are entering the right characters.
You must first add the rule
<service id='9999'>
<id>SMTPout-587</id>
<rule id='0000'>
<direction>outbound</direction>
<protocol>tcp</protocol>
<porttype>dst</porttype>
<port>587</port>
</rule>
<enabled>true</enabled>
<required>false</required>
</service>To the rules file at [b]/etc/vmware/firewall/service.xml[/b]
Once you have done so
esxcli network firewall ruleset set --ruleset-id="SMTPout-587”--enabled=true"Connection closed by remote host" and/ or "Broken pipe" message and copy errors might be returned by SSH on the remote server. This does not happen on the reference Linux distros: RHEL, Fedora, CentOS and is caused by some particularities in the behaviour of the SSH daemon shipped with ESXi. We are working on it and will release a fix with version 11.2.3.
Your cron is working, your job files are being called by the cron. You are just one step away. You are missing something, but we can't find it for you.
How come this be?: 2019-01-31T02:00:01Z
That is a time in the future, you are supposed to be in the US east coast.
This is a problem restricted to sending e-mails, so let’s concentrate in this issue and leave everything else apart.
Issue this command:
./xsibackup --check-smtp=some@email.com --use-smtp=2
And let us know if you get the same result, I bet you will.
This looks like an ESXi bug in some build when calling Firewall operations from the command line or a broken firewall more than an XSIBackup issue.
Try adding the firewall command manually at the end of the /etc/vmware/firewall/service.xml file…
<service id='9999'>
<id>SMTPout-587</id>
<rule id='0000'>
<direction>outbound</direction>
<protocol>tcp</protocol>
<porttype>dst</porttype>
<port>587</port>
</rule>
<enabled>true</enabled>
<required>false</required>
</service>
And see what is ESXi’s response when issuing this command
esxcli network firewall ruleset set --ruleset-id="SMTPout-587”--enabled=true
Contact support to find out what your problem is. You are offering very little detail for us to be able to offer some guidance.
Please, keep in mind that the root crontab permission set is 0600. You need to change it to be able to edit the file with vi.
Depending on the crond implementation, and that can change from one ESXi version to the next, the cron daemon might not execute your crontab if permissions are not 0600.
As you previously had to change them to edit the file, we are asuming you are setting them back to 0600
[b][url=https://33hops.com/xsibackup-pro-vmware-esxi-backup.html]XSIBackup-Pro[/url][/b] is licensed per crontab. You can install to one ESXi server and backup up to 20 servers from that server's crontab, but if you want to perform a different installation to a new server and run backup jobs from its local crontab, then you need an additional license.
That is a widely open question with no precise answer.
Mounting your Synology NAS as NFS3 or iSCSI is a trivial task, once you do it your volume will be available as a datastore and you'll be able to backup your VMs there via any of the XSIBackup [b]--backup-prog[/b] programs, except those which are exclusively to be used over IP (Rsync).
Nevertheless, what you stated is "I tested XSITools over IP" which means that you directly tried to backup to your Synology NAS by connecting over IP to the SSH port, which as previously stated is not supported. XSIBackup may be used to backup over IP to other ESXi boxes (version and HW compatible) or to Linux servers, being our distro family of choice RHEL, Fedora, CentOS that is where we certify Linux features.
That is really weird. We use different ESXi versions and builds every day and never saw this.
Please, let us know the details of your environment, there could be some bug in your vi binary.
We don't state that XSITools will work on a Synology OS.
We are walking on thin ice here. To properly discuss this matter, we would need to delve into it by reading the appropiate protocol definitions of some extensions as secure renegotiation. What we can tell you from our own experience is that there are many GMail servers and that not all of them behave the same and they also evolve over time. They do in regards to basic usage, but not all of them will be able to handle a secure connection on port 587.
AFAWK to connect over TLS to gmail.com you will need to use port 465, if you try to connect on port 587, at least at the time to develop that part, the SMTP conversation was being handled over to a TLS context. We cannot guarantee that this will work all the time in all servers, we can't even guarantee that it still does in any server. We in fact just make use of GMail and other providers.