Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

Well, first of all XSIBackup does not announce any sort of compatibility with [b]AWS S3 buckets[/b]. It nevertheless supports open standards like NFS, so just as long as you are able to [b]properly[/b] mount your NFS share in ESXi, everything should work.

Do not forget to [b]always use NFS 3[/b], as we state in every NFS related post; NFS 4.1 is useless in case of backups and, on the other side, does not even work from the ESXi shell.

You must note that NFS is a complex protocol in which a number of different ports are used in an intrincate and complex relationship between the NFS client and host, NFS was never designed to work accross the Internet, thus mounting NFS over a WAN is normally performed tunneled to avoid having to deal with that complex scheme and having to port it to any firewalls in between.

Beeing able to mount the NFS share, does not mean that the NFS protocol is properly set up. By what you are describing, it looks like NFS is not working fine and you are loosing some fundamental information.

[url]https://serverfault.com/questions/588623/is-nfs-good-to-share-disk-images-over-the-internet[/url]

No worries

Before anything else, upgrade to the latest version, there has been some bug fixes. Use the script online, it will keep your configuration files and jobs. Copy those folders out of the server, if you will, to have a backup, just in case.

You have different problems here:

1 - You have XSIBackup installed to more than one point and this is confusing the program. Remove any leftover and keep one single installation dir. You should be tidy: per instance, keep a uniform path accross all servers, the default one if possible ([b]/vmfs/volumes/datastore1/xsi-dir[/b]). If you can't keep the default paths, you must be aware of the fact that you should change the [b]xsidefaultpath[/b] as stated in the warning message below.

2018-10-25T22:41:39|  Found more than one remote (c) XSIBackup installation dir at [10.240.100.41]
2018-10-25T22:41:39|  Using hardcoded var at conf/xsiopts [xsidefaultpath] as remote path.
2018-10-25T22:41:39|  Remote xsi path set to: /vmfs/volumes/datastore1/xsi-dir

Taking on account that you are running a remote job via the [b][https://33hops.com/xsibackup-help-man-page.html#manhost]--host[/url][/b] argument, you can just wipe every remote [b]xsi-dir[/b] folder and let XSIBackup create it for you, again according to the [b]xsidefaultpath[/b] variable in the [b]conf/xsiopts[/b] file. Note that you can also parse this variable in your backup job.

2 - You have not understood how the program works in regards to remote execution of jobs. You are parsing this in your job:

--host=10.240.100.41:22 --backup-point=10.240.100.41:22:/vmfs/volumes/Archive

Which literally means that you are going to run the job at server [b]10.240.100.41[/b] which has SSH service running on port [b]22[/b] and then, the job running there, will send the backup to the [b]10.240.100.41:22:/vmfs/volumes/Archive[/b] datastore in the same IP and port.

The above does not make much sense, as you are running the job in [b]10.240.100.41[/b], the [b]/vmfs/volumes/Archive[/b] datastore is local to it, so the --backup-point should be just [b]--backup-point=/vmfs/volumes/Archive[/b]

There was an issue affecting gmail.com domains.
It has already been solved, sorry about the inconvenience.

Thank you for the feedback, we'll increase that length, there will always be something longer though.

Use a different e-mail address on a different domain.

We have never come accross such problem, and we have many thousand users
I removed the --certify-backup option from the example I posted before, as it's not an option available in the free version.
I also changed everything to lower case and removed all unnecessary options, as in the test script.

"/vmfs/volumes/RAIDx/xsi-dir/xsibackup" \
--backup-prog=vmkfstools \
--backup-point="/vmfs/volumes/RAID-lenovo" \
--backup-type=running \
--use-smtp=1 \
--mail-to=myemail@mydomain.com \
--backup-id=001 \
--description="Backup Enterprise VMs" \
--exec=yes >> "/vmfs/volumes/RAIDx/xsi-dir/var/logs/xsibackup.log"

Try it again and let us know.
This is very weird, I think you have just pasted some out of page code characters.

Where?
How?
Through what?

1.2 Tb. is a lot of data. If you try to push it through a dial up modem connection, then using tb/age is a reasonable unit of measure. If you are doing it through a 10 mbps WAN, then ages is still a good unit of measure. If on the contrary you are copying over a LAN, then taking ages might not be a reasonable speed.

Please, use terms that anybody reading your posts can understand, like mb/s. If you expect to receive a concrete answer, then provide some, at least, approximate information on the subject.

Are you sure there's at least one VM running?
Try to use the combination of --backup-type=custom --backup-vms=your,list,of,comma,delimited,VMs

You might be picking up a job that already has that VM added in the remote host. We don't have enough information to offer a precise answer.

Best advice: delete everything in th /tmp dir and start from scratch.

You can backup over IP via SSH by just setting the backup point to a remote computer, where you have three values separated by colons, which represent [b]IP:Port:Remote path[/b], i.e.:

--backup-point=10.0.0.3:22:/your/backup/destination

All [b][https://33hops.com/xsibackup-using-backup-programs.html]backup programs[/url][/b] support SSH over IP backups except [b]Vmkfstools[/b], we are ultimating [b][https://33hops.com/xsitools-vmfs-deduplication.html](c)XSITools[/url][/b] compatibility with SSH backups at the time of writing this.