Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

The SMTP module first scans the server to check that it is indeed listening on the specified port. If you get that message, then the SMTP client was not able to reach the SMTP server. Check your network, network firewalls, SMTP server firewall, etc...

Well, XSIBackup is not just a script calling command line tools, it features propietary low level binaries to transfer and manipulate data too. It would simply not work as it does without low level programming. We have kept the frame as a bash script for some reasons:

1 - It allows users to tweak it to their needs.
2 - Makes it easy to debug any eventual issues.
3 - Compiled binaries would not make it faster, there were compiled code is required, that's what we use.

In regards to the [b]--smart-info[/b] argument, you are absolutely right, it's just a report of what the esxcli tool offers, so any information you are getting out of it will depend on what the built in SMART report tool can offer. This is a value added argument, we might improve it in the future, but backup and replication is our main worry and action field.

Free version does not have any GUI

We'll launch XSIBACKUP-FREE 11.0.1 today

No, it's not.
Next version of Free product will be.

Thank you for your detailed feedback, we do appreciate it.
We already removed that redundant "d".
You are right in regards to that button, we'll add something that is more self explanatory.
That other suggestion about allowing the job to be killed will be added to the feature request list.

For the GUI we have used [b]dialog[/b] library, that works on top of ncurses. Unfortunately it is not able to display \r characters, so it breaks percentage progress. Running jobs through the GUI is a convenient but somehow dirty way of running [b]--run-backup=XXX[/b] argument. You should do that from the command line if you want full detailed, scrollabe output on screen.

We'll take that list being wiped as a bug and will make the GUI preserve remote VMs when you edit remote jobs.

I noticed we are talking about remote jobs all the time, so when you say "I'm unable to get backups to work with version 11.0.0", I guess you mean "I'm unable to get [b]remote[/b] backups to work with version 11.0.0".

If you just converted some older backup jobs into job files at the xsi-dir/jobs directory, there might be something which needs to be tweaked. Contact support with the full backup job to delve into your issue.

Version 11.0.0 offers a GUI with which you can manage all main XSIBackup arguments, as new minor versions are launched, we will add some new functionality to the GUI, like disk exclusion management, which will be added on version 11.0.1.

We have not removed anything all functionality is still there. The only thing is that you might need to edit the job file manually to do some things by now, such as excluding disks. Some other tasks, like using bash code snippets to generate backup paths dynamically, will always need to be done by editing the job files.

So, you keep everything you already had, you get some really interesting improvements, like using the ESXi cron directly, thus having full Linux crontab flexibility, or centralized backup chaining on top of the GUI. But you can still use XSIBackup by directly editing the job files or creating your own.

Attach your NAS to your ESXi server via NFS or iSCSI as a datastore and backup to a local path in that datastore, or backup over IP to a secondary ESXi server, that must be visible over IP, have its SSH service open and have been linked to the primary one by means of the [b][url=linksrv]--link-srv[/url][/b] command.

You can alternatively backup over IP to any Linux/Unix enabled device, but that will require a good understanding of how key authentication works between two OpenSSH systems in case XSIBackup cannot handle it automatically.

If you are getting a "Server does not exist" message, then you aren't even reaching it at the TCP/IP level.

Please, read the Man page: [url=https://33hops.com/xsibackup-help-man-page.html](c)XSIBackup Classic Man Page[/url]
And tutorials: [url]https://33hops.com/xsibackup-tutorial-1.html[/url]

Before using the software, especially if you are attempting to perform complex operations.

There is indeed one bug that has to be addressed in ESXi 6.7 and prevents any over IP backup from being fulfilled.
The OpenSSH binary now spits the absolutely unnecessary line: [b][url=https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/FIPS_Mode_-_an_explanation]FIPS[/url] mode initialized[/b]
If I was the programmer that decided to offer such redundantly unnecessary poetry, I would not comment in bars ;-), as many thousands of people are probably now thinking what would be a fair nemesys for such unwanted piece of information on STDOUT.

We are already working this verse around and an almost fully compatible version will be launched with [b]XSIBACKUP-PRO 11.0.0 RC3[/b], which will be distributed to Pro users tonight or tomorrow morning the latest.

UPDATE:

The problem was fixed in v 11.0.1

Please, contact support, there's not much we can tell you without seeing the backup log.

You should be able to answer yourself.
If you store to a folder called Monday, what will happen next Monday?, it's obvious.
Is it safe?, well that depends on your own requirements. If you overwrite Monday's backup next Monday: would it be safe for you to have Tuesday, Wednesday, Thursday, Friday, Saturday and Sunday backups?
Design you backup schedule following your own requirements.

That depends on the type of backup you want to restore:

- (c)OneDiff, Vmkfstools and Rsync generate full VMs that can be used directly from the backup location. If you want to use them some other datastore or server, just move the VM folder and re-register them at the desired server.

- (c)XSITools and Borg deduplicated backups need to be restored from their respective repositories, for wich you will need XSIBACKUP-PRO restore module. In case of Borg, you could restore the backups manually too: extract the backup file, rename it to .tar and untar it.