Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

- ¿Have you previously linked both servers?. If the GUI is exiting, run this command in the command line:

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

Where 1.2.3.4 is the remote IP and 22 is the default SSH port.
- ¿What type of server are you backing up to?
- Is it ESXi, ¿what version of ESXi?

Well, I don't have the newer add ons to the SMTP spec now in mind, but, isn't that a feature on the server side upgrading non secure SMTP to a secured connection?

XSIBackup does indeed support TLS through OpenSSL if the server does.

Thank you!, If they find out they will move me to the commercial area ;-)
Just write to support with your tech request and we'll propose you the best fit

The [b]conf/smtpsrvs[/b] file might have gotten corrupted somehow. It's not a big deal, as it's easy to fix, but if you managed to unformat/ corrupt it through the GUI, it could be considered a bug. It's most probably due to some special character in the input, we filter them, but you migth have passed something we are not taking into account.

[b]Solution:[/b]
Just edit the [b]conf/smtpsrvs[/b] file manually. The format for each line is described in the head of the file, you can just delete all active lines and start from scratch or correct manually, should you find something that should not be there.

It will prune the [b][https://33hops.com/xsitools-vmfs-deduplication.html](c)XSITools[/url][/b] repository to make sure it stays within the 2Tb boundary. You don't have to take this literally to the Mb unit, as there are maneuver margins and the repo is pruned only when the new backup set has been fit into the repo, but you just have to tweak the [b][https://33hops.com/xsibackup-help-man-page.html#backuproom]--backup-room[/url][/b] a bit below your desired size to fit your available space.

Please, be aware that as [b][https://33hops.com/xsibackup-help-man-page.html#backuproom]--backup-room[/url][/b] not only affects the size of the (c)XSITools repo, but also the accumulated size of the folders with an XSITools mask, i.e.: 20190107102345, it may also prune other types of backups if the accumulated size of those thusly masked folders reach the configured value, so it's better to keep your XSITools repositories in a different root folder.

You may as well run out of space in your disk while the size of the repo is still below the limit, in that case you would get out of space errors from the file system. It's easy to prevent all of this situations by keeping backup contents well organized.

You are too limited.
Download latest version 11.2.2, which allows to prune (c)XSITools repositories by using the --backup-room argument. It allows to parse up to 2048 gb as the XSITools repo limit, next version clears that restriction.

In the local machine, as stated control is always returned to the master server.

Use backup chaining combined with the [b]--host[/b] argument. When you add [b]--host=1.2.3.4[/b] to a backup job, having previously linked to host [b]1.2.3.4[/b] by means of the [b]--link-srv[/b] option, you will make that job be executed in the [b]1.2.3.4[/b] host.

The log will be stored to the [b]var/logs/xsibackup-1.2.3.4.log[/b] file. When the remote job ends control will be returned to the master server and it will look for any eventual [b]--on-success[/b] and [b]--on-error[/b] arguments asigned to the job.

If the job id is found in the jobs folder, it will be triggered, if it contains a [b]--host=1.2.3.4[/b] the job will be executed to the remote host and so on.

That looks fine, once you reach the limit set in the [b]datedirmask[/b] variable, if the sum of all the folders matching the mask exceeds the value set in [b]--backup-room[/b] argument, the folders will start to be deleted starting by the eldest one. They will be removed until making enough room to fit the current backup.

You should also take a look at the [b][https://33hops.com/xsibackup-help-man-page.html#deldirs]--del-dirs[/url][/b] argument.

- .vmx file is renamed to .vmx.bak to reset the (c)OneDiff cycle automatically.
- As the .vmx file is not present, rename .vmx.bak back to .vmx (you already did).
- Error: error deleting all snapshots VM. This is just a generic error, you must follow the thread to know what's the root cause. Inspect your ESXi log files to delve into the issue.
- All needed files seem to be present: -000001.vmdk, -000001-delta.vmdk, .vmsn
- It could be that some process is holding some of the snapshot files. Use lsof command to find out:

lsof | grep "datastore_d2/VM_BACKUP/Ubuntu"

- Reboot the host if you have the chance, this does magic most of the times.

Thank you so much for your feedback, you are right. We will correct this and add the final command. It's a kind of obvious for more experienced  LVM users, as otherwise the added chunk remains as unused space, but less obvious for people just wanting to extend the XSINAS appliance size.

XSINAS is O.K., it's a useful appliance in SMEs scenarios, but some people which don't fully understand what block deduplication is, just take for granted that it will work as any other regular FS when it obviously doesn't. The FS will slow down as you add data to it.

We have been extremely conservative when configuring XSINAS, so that nobody inadvertedly "hurts himself" by not fully understanding the concept behind. If you want to take the appliance to its limits, you should consider switching to Tokio Cabinet and using fast PCI SSDs. It will multiply its possibilities. Nevertheless, take on account that Tokio Cabinet may loose data in extreme circumstances, like a power outage, while BerkeleyDB has been programmed to be more robust, but lacks Tokio Cabinet speed.