Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

Don't even try to perform a backup from one host to another over IP if you haven't exchanged keys succesfully.
You have plenty of typos in your post, this is misleading because may lead others to think that you are mistyping things in your terminal.

Not "authorized_key" but [b]authorized_keys[/b]
Not "link-srv=1.2.3.4=22" but [b]--link-srv=1.2.3.4:22[/b]

The exchange key process is extremely simple and doesn't involve anything but two functional OpenSSH servers able to communicate. Once this is possible your public (c)XSIBackup RSA key will be added to the remote [b]authorized_keys[/b] file at the remote end, that's all from a conceptual point of view.

You are clearly being denied access to the remote system

Permission denied (publickey,password,keyboard-interactive)

Thus, any further attempt to perform a backup without previously fixing that issue will fail.
Forget about anything else and focus in running this command from 192.168.1.48.

./xsibackup --link-srv=192.168.1.70:22

Run it and paste whatever you get.

No worries, Merry Christmas!

A "Killed" is being printed to STDOUT. Seems like you have some other processes running that are killing current one.
Run this command:

ps -c | grep xsi

And check whether you have multiple XSIBackup processes running in the background, if so kill them all and make sure your cron is not overlapping jobs.

We don't know what might be the problem with your wget session, we have downloaded the package from a browser and also using wget.

[root@esxi1:/tmp] wget /?key=Xm2h1kpL63wIFf5ZXXXXXXXXXXXXXXXXXXXXXXXXXXX3219
Connecting to XXX.33hops.com (XXX.XXX.3.XXX:80)
?key=Xm2h1kpL63wIFf5 100% |*************************************************************************************************************************************************************|  1494k  0:00:00 ETA
[root@esxi1:/tmp]

Please download using your browser and upload the package via SCP or contact support so that we send you latest version. Some systems with multiple internet IPs might experience problemsdownloading.

We just released [b](c)XSIBackup-Pro 11.2.14[/b] which incorporates some improvements that will help you detect when DRS is moving your VMs around so that you can take action.

We will reinforce the code to detect whether there has been some previous error and cancel pre-deletion in these cases, as well as improving the error handling when the VM is not there any more. We'll have a new version ready in short.

Please, note this are measures to save some furniture once the house is on fire.

We detected an error in your job not having to do with this matter, the [b]--backupid[/b] argument must contain numeric strings in the range 000-999

We will of course test it and eventually fix any issue and or make any reasonable improvement, but please do notice that normal behavior would be to halt the backup job and notify the error, so the deletion of the previous VMs in the job is trivial as well as the backup of the subsequent VMs that is indeed performed, as the backup job is invalid in your context.

You can't consider anything happening around your backup job as something regular, as it's exceptional. The deletion of the first VMs backup folders as well as the backup of the subsequent ones is spurious.

We put our design efforts in trying to comunicate any error through the e-mail report, nevertheless there may be errors or exceptions that can't be reported by e-mail.

In your case you are suffering from an NFS protocol issue which is denoted by the message [b]Input/output error[/b]. [b](c)XSIBackup[/b] is somewhat NFS Async safe, as it "waits" until the block is available in the remote FS. In any case using Sync NFS won't hurt performance inside a LAN so you should always use Sync NFS, which is safer. Async should work seamlessly inside a LAN too though.

The sync=xxxxx options you comment aren't NFS options but seem to be volume sync options instead. Try to create a simple volume on a single disk and backup there, your NFS errors might be related to some layer underneath it which is not keeping up with NFS transfer rate.

Taking DRS into account in regards to backups is a must, not only using [b](c)XSIBackup[/b], but any other software working at host level, method which in turn has some advantages over doing it at [b]vCenter[/b] level and some drawbacks as having to deal with DRS should you happen to have it enabled.

We believe to have gotten you right at first. Nonetheless, what we are trying to explain is that the only line of code that deletes anything in your backup prog ([b]--backup-prog=Vmkfstools[/b]) is in preparation to backup a given VM at some [b]--backup-point, i.e.: /vmfs/volumes/backup/MY-VM01[/b], thus if you are getting some previous backup in the same job deleted, it can only be due to some previous VM in the row being under some other VM backup path.

Let's say you are to backup this VMs: [b]VM01, VM02, VM03, VM04, VM05[/b] at [b]/vmfs/volumes/backup/[/b]. First VM will be backed up at [b]/vmfs/volumes/backup/VM01[/b] VM02 at [b]/vmfs/volumes/backup/VM02[/b] and so on, and those dirs will be previously wiped to make sure you don't mix files.

That delete operation, the wipping of the the target folder, is the only one that is performed at the backup point root. Thusly if your backups at [b]/vmfs/volumes/backup/VM01[/b] and [b]/vmfs/volumes/backup/VM02[/b] are being wiped, that can only be due to some VM in the row after them being backep up to [b]/vmfs/volumes/backup[/b] so that the [b]backup[/b] dir is deleted to host some VM named "backup" which is sitting one dir below the others.

You can of course stretch this explanation to any directory depth, the matter is relative to the previous backup folders.

Of course, another way of deleting previous backups is if you backup VMs with the same name to the same backup point, but that needs no explanation. If you are backing up VMs hosted in a cluster, you should make sure that you keep names unique.

Apart from that we will of course revise any possibility that may occur during code execution to prevent any unwanted deletion, but (c)XSIBackup works under a general working principle which is to never stop even it it's receiving errors.

Look at it this way:

If when hitting an inexistent VM or some other issue, due to RDS or any other circumstance like a backup end target directory containing data [b](c)XSIBackup[/b] would just complain and stop execution, you wouldn't have any previous backup in the job deleted cause there would be nothing to delete and on top of that you would not have the remaining ones either.

[b](c)XSIBackup[/b] requests the ESXi system to take a snapshot on a given VM, but it doesn't take the snapshot itself. The messages you are posting aren't even produced by any [b](c)XSIBackup[/b] code.

Your system has become unstable and it fails to take a snapshot when requested to, that's where all your problems are coming from. We have plenty of experience with ESXi and we do know this might happen from time to time. First thing you should do is reboot the host whenever you have the chance to, this will most probably fix any issue.

If you continue to experience problems after a reboot, contact support, where we will be able to delve a bit more into your problem. In any case, as said, all that you seem to be suffering from is an unstable system, most probably due to memory corruption.

Have you checked that you have permissions on the xsibackup and the log files. You are running it out of the recommended installation path, thus you must make sure that everything has rights to read and write as required.

Well, the job is the very same, no matter if you launch it from the GUI or from the cron.
This seems to have to do with the time you launch the backup more than whether you launch it from the GUI or from the cron.
Try to use --backup-how=warm instead while you look for the root of the problem. A host reboot can also be a good idea in these cases.