Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

In regards to your 1st question, what do you mean by "but nothing is even shown on the smtp server"?. If you don't detect a connection to your SMTP server, then you are not even reaching it, so you should check your firewall/s: ESXi and anything else in between. XSIBackup opens required port automatically in ESXi, so you should check everything else. Unless you wanted to say something different, you have a connectivity issue, not related to XSIBackup.

Have you installed the cron?.
If you did but still don't get it to run, read this post: [url]https://33hops.com/xsibackup-cron-how-to.html[/url]

[b][url=https://33hops.com/xsibackup-help-man-page.html#deldirs]--del-dirs[/url][/b] is an option exclusive to XSIBACKUP-PRO, as stated in the Man Page, so it will just show a notice in XSIBACKUP-FREE. In any case, even if you had the Pro version, this argument (--del-dirs=-d5time) would never work, as it does not follow the syntax explained in the manual.

[b]create snapshot xsibackupdiff (11) failed[/b]

You can't backup a VM if you can't take a snapshot.
Fix the VM and then try to back it up. Check that VMWare Tools are installed and running, consolidate the VM, check that you have enough space in the datastore and also in the virtual disk. Namely, fix whatever is wrong and try again.

That error has nothing to do with XSIBackup, it's a generic VM error.

Well, you can easily check that XSIBackup declares content-type (at the SMTP protocol level) and document type (at the application level) correctly. In fact if you relay directly from XSIBackup to any mail server, your e-mail will be properly interpreted. Some e-mail clients like GMail will remove the table borders and padding, ignoring CSS, but that's something totally out of our control.

You are probably loosing the [b]Content-type: text/html[/b] declaration somewhere in your relay chain. Check that your postfix is respecting it and parsing it to 365.

I guess some other changes Postfix could be making on the fly to some header could be the cause.

On the other side Microsoft is well known for going "their own way".

You can use one cron, whatever is more suitable for you. If you use a Linux cron, you don't need to use the --host option, just create the jobs, store them in one local bash script file at the ESXi server and launch that file from the outer cron. You can also run the command directly, but this has the disadvantage of having to escape the command properly. No rocket science anyway.

[url]https://33hops.com/xsibackup-remote-execution.html[/url]

Whatever accesibility problems you may encounter is part of a different story. You might find yourself in a situation in which you need two different crons running on each server, but you can always open a port in the firewall.

I'm seeing your key in the server.
Maybe you have a cache issue, empty browser cache and reload the page.
But please, don't post this personal issues in the forum, it won't help anybody, you have the support department to assist you.

The key to your problem is on some other errors in your log:

packet_write_wait: Connection to 192.168.100.16 port 22: Broken pipe

This is self explanatory. The reason why it's always the same VMs that fail could be in some timely issue.
Split your backups into two and treat those two VMs in a different backup job. Try to back them up manually and see if you still get those errors. Try to find out if there is some automated job that brings the backup link down at the communications layer.

To make this change permanent you should remove that sed from this file:

/etc/rc.local.d/local.sh

Otherwise it will reappear on [b]/var/spool/cron/crontabs/root[/b] after reboot.

As already stated, this type of error [b]Failed to clone disk: Input/output error[/b] has to do with some uncontrolled condition at the hardware or transport layer: full disk, bad cable, bad disk, broken driver, etc...

Just make sure that things are where they have to be.
This posts may be of help to you:

[url]https://33hops.com/xsibackup-cron-how-to.html[/url]
[url]https://33hops.com/xsibackup-advanced-cron-alternatives-to-xsibackup-cron.html[/url]

From the README.txt file:

Update:

	You can try to just overwrite the existing files, but you must be 
	aware of the fact that memory corruption may appear. Should this 
	happen (you will notice it because some weird syntax and runtime 
	errors will be thrown), please reboot your server. This is due to 
	how bash scripts are cached in memory. One good way to ensure you 
	work this issues around is to copy the new version to a different 
	folder and then delete the old and rename the new to xsi-dir. This 
	changes every program's file inode and prevents mem caching.

	If you run a mission critical environment and you have a working 
	XSIBackup installation, you'll have to ponder whether to upgrade 
	or continue using the existing version.

I'm sorry DaveK, but I'm not quite getting you.
You mean you didn't accept the license agreement?; you have to, for the software to work.
Apart from that, you do need to test your backup jobs before placing them in the xsibackup-cron file. Once you know they are correctly formatted and working, enable them in the crontab.
You still haven't told us what ESXi version you are using.

I think you should not get obsessed with this feature too much. If we have not added it so far is for a number of reasons:

1 - Purging orphaned blocks would be time consuming
2 - Deleting the wrong ones would be desastrous
3 - The space you are going to save by purging a well populated repo is insignificant, as most blocks will be shared

So, in the end, the consumed CPU and the expected results in return, makes its cost effectiveness, as a feature, be very poor.

We know what that bug is, we first addressed it in a way that might not work for everyone of you. We'll send you now a newer version that will be published in short and should give remedy to this issue in every case.