Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

That doesn't make much sense, XSIBackup can use any datastore as it's backup target.
You must have some previous error. It looks like the XSITools repository hasn't been correctly initialized and the [b].xsitools[/b] file is missing.

We need more info. Are you backing up over a WAN?, if so, what's your available bandwidth?
Most important: what is your remote's ESXi version?, have you detected any errors in the output?, can you provide it?

I'm afraid that Rsync is not a very practical way to move 500 gb. over IP, especially since it can't deal with zeros and copies them as data. Even though it can compress them, still is not the best way to do it. In any case it should work, no matter how long it takes, so please send us some more details.

Thank you for your feedback.

From XSIBackup 9.1.9 and up, the program will detect versions on both sides of the peer and choose an adequate Key Exchange Protocol (A.K.A. K.E.X.). Nevertheless, if you connect from an ESXi 6.5.0 box to a lower version one, the remote party will only offer KEX methods that the OpenSSH version present in ESXi 6.5.0 does not support any more, resulting in the message above. As a result, you can only perform IP data transfers from a lower version to a higher one or between same version, but not from ESXi 6.5.0 to a lower version of ESXi.

In any case backing up from a given version to a lower one is not very common, nor very recommendable, as you may be copying VMs which cannot be used in a lower ESXi version. The word "may" is there on purpose, as it really depends on the VM hardware version, and not on the ESXi version itself. If you don't fully understand what is exposed in this post, I suggest that you start here: [url]https://pubs.vmware.com/vsphere-51/index.jsp?topic=%2Fcom.vmware.vsphere.vm_admin.doc%2FGUID-68E5EDAE-66DE-43F8-9420-F424AFEADB1D.html[/url]

Just disable compression in your /etc/ssh/ssh_config file to find out if this is the cause of your slow down.
Add the line to the SSH client config file.

Compression no

Yes, most of the overhead in Rsync transfers is caused by the SSH encryption and/or compression. What kind of server/CPU are you using?

XSIBackup has its own built-in cron system, which is the recommended scheduling method. Of course, you are free to experiment and launch XSIBackup from other outer schedulers like cron or Windows Task Manager.

Almost every SSH client has an argument or switch to redirect output of command run in remote systems, in some cases this is the default behaviour, in some others you need to explicitly state that this redirection should take place. Nevertheless this is something that has to do with your chosen SSH client and not with XSIBackup itself, which simply prints its output to [b]stdout[/b] and knows/cares nothing about what happens with that output, whether it is redirected or not, or where it is indeed effectively redirected.

You should read this post [b][https://33hops.com/xsibackup-remote-execution.html]Executing XSIBackup Remotely[/url][/b], it should help you clarify how to execute remote commands from other Linux systems.

There are other posts in the Internet that treat this subject, this is a selection:

[url]https://unix.stackexchange.com/questions/1630/redirect-stdout-over-ssh[/url]
[url]https://unix.stackexchange.com/questions/151316/how-to-send-a-output-of-unix-command-from-one-server-to-another-server[/url]
[url]https://askubuntu.com/questions/917200/how-to-redirect-command-output-from-remote-machine-to-local-file-via-ssh[/url]

By now XSITools works only to local storage, but you can just attach your Ubuntu box as an NFS datastore, it's very easy. You can just follow this guide: [url]https://nfs.sourceforge.net/nfs-howto/ar01s03.html[/url]

You are pasting something that does not make sense ([b]esxi-host#[/b]).

1 - CD to your installation dir and run the program from that folder

cd /vmfs/volumes/datastore1/xsi-dir
./xsibackup

2 - Or invoke execution through an absolute path to the program

/vmfs/volumes/datastore1/xsi-dir/xsibackup

Those are the two main ways to execute something in a *NIX environment.

ESXi duplicates snapshot files when performing a quiesced backup on GPT Windows guests, this causes the [b]OneDiff[/b] algorithm to fail. We are working on a solution.

We want to clarify that [b]OneDiff[/b] algorithm works perfectly well on all other GPT OSs which support quiescing. It is only Windows that fails, or..., just follows a totally different behaviour than the rest of OSs. This error is very similar to this previous one affecting MBR Windows Systems: [url]https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2006849[/url]

It looks like Windows developers are not able to make their VSS behave as consistently as LVM in Linux. In fact, I would say that in regards to VMWare: 1/ They aren't able to make Windows work consistently on VMWare, 2/ They don't want to make Windows behave consistently in VMWare

As said, we will release a fix in short. By now, if you want to perform a quiesced backup on a Windows GPT or MBR server, you will need to asume a short down time (usually less than a minute) and use the [b][https://33hops.com/xsibackup-help-man-page.html#backuphow]--backup-prog=warm[/url][/b] switch, which will turn the server off, take a snapshot and then switch the OS back again, before making the hot backup.

[quote=ulfthomas][quote=admin][quote=sistemi]

I'm interested at the link, can you provide it?[/quote]

You have a link to a free tool in our Most Common Issues page here: [url=https://33hops.com/xsibackup-most-common-issues.html]https://33hops.com/xsibackup-most-common-issues.html[/url][/quote]

That is indeed the link I was using (I'm sorry but I forgot). There is a couple of typos in that article:

gptgen.exe -w [b]\.physicaldrive0[/b]
bcdboot [b]c:windows[/b] /s s: /f UEFI

Needs to be changed to:

gptgen.exe -w [b]\\.\\physicaldrive0[/b]
bcdboot [b]c:\windows[/b] /s s: /f UEFI

Else it will fail.[/quote]

Thank you for the info, but you should communicate that to the software authors at: [url]https://sabrnet.wzk.cz/2015/03/convert-windows-system-mbr-disk-to-gpt-with-efi-without-data-loss/[/url]
There is a textbox where you can leave some comments.

[quote=ulfthomas]A couple of more tests:

[quote]
- Cleaned out all the snaphosts and folders
- Initiated the first Onediff backup with additional switch --backup-how=warm: Backup successful
- Initiated the second Onediff backup with the same switch: Backup successful
- Initiated the third Onediff backup removing warm switch but adding --snapshot=dontquiesce: Backup successful
- [b]Initiated the forth Onediff backup removing both warm and snapshot switch: [u]failed[/u][/b]

[/quote]

Wouldn't this indicate that it could be related to the quiescing of the VM?[/quote]

Yes, it could be related to the VMWare issue that you pointed out. Remove the 500M check with the options flag [b]--options=no-500M-check[/b] and see if this helps the problem. Nevertheless, the fact that the resulting VM is not an exact copy of the original one when quiescing, is something to be concerned about. I guess VMWare should solve this issue.

We are working on this issue. We will offer a solution or workaround in short.