Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

You could do that, or even perform an Vmkfstools on a VM that is engaged in a OneDiff differential backup. The backup will be made from the OneDiff snapshot and the integrity of the OneDiff differential backup will be preserved.

Thus it's totally safe to backup the _XSIBAK VM or even the original VM.

Use [b]OneDiff[/b] as you backup program to achieve the differential backup every day and [b]Vmkfstools[/b] every three days, you don't need chaining.

You have a wizard in the GUI and a full manual detailing every step here: [url]https://33hops.com/xsibackup-pro-gui-manual.html#1[/url]

It's a matter of choosing programs, paths and VMs and clicking on "Next". You should previously add an SMTP server.
If you are new to Linux, you might need to learn how a crontab works, but that is general knowledge that you should acquire on your own.

*     *     *   *    *        command to be executed
-     -     -   -    -
|     |     |   |    |
|     |     |   |    +----- day of week (0 - 6) (Sunday=0)
|     |     |   +------- month (1 - 12)
|     |     +--------- day of        month (1 - 31)
|     +----------- hour (0 - 23)
+------------- min (0 - 59)

Yes, that is regular behaviour in Linux shells, when you exit processes are killed by SIGHUP:

[url]https://stackoverflow.com/questions/32780706/does-linux-kill-background-processes-if-we-close-the-terminal-from-which-it-has[/url]

If you run manually and want the job to finish, you should do one of these things:

1 - Leave the SSH connection open until the process finishes.
2 - Put the process in the background by adding a NOHUP command first and a & sign at the end of the command.
[url]https://askubuntu.com/questions/8653/how-to-keep-processes-running-after-ending-ssh-session[/url]

You might need to wrap your job in a file, in fact that's what XSIBackup does by placing the jobs in job files inside the [b]xsi-dir/jobs[/b] directory.

This approach might not work, due to XSIBackup creating many child subprocesses with complex relationships. So you will most probably be bound to just leave the SSH session open. We have not designed XSIBackup to be detached from a TTY.

In full Linux environments, there are tools which allow you to achieve the same goal, like [b]screen[/b].

This is very weird.
As you know, all there is to public key authentication is copying the public key to the remote [b]authorized_keys[/b] file. Just as long as it is there and the remote [b]authorized_keys[/b] file has the appropiate permissions [b]0600[/b], which BTW are reset on every reboot, public authentication will work.

Check that you have your XSIBackup RSA public key at the file [b]/etc/ssh/keys-root/authorized_keys[/b] in the remote host, you can just cat compare visually for the matter.

cat /etc/ssh/keys-root/authorized_keys

Take on account that if you try to backup from different ESXi versions, let's say ESXi 5.5 to ESXi 6.7, the OpenSSH versions will differ a lot. Due to some security problems, OpenSSH has removed some KEX protocols from newer versions and when mixing older versions like OpenSSH 5.6 with some newer ones, like 7.3, they just can't find a valid KEX protocol in common and drop key auth.

To verify this point just issue this command:

ssh -vv -4 -o PreferredAuthentications=publickey -o StrictHostKeyChecking=no \
-i /vmfs/volumes/backup/xsi-dir/xsibackup_id_rsa root@192.168.X.X

Accomodate paths and IPs to your own and see if you can connect to the other end passwordlessly.
In case you cant, inspect the verbose output and you will probably see that the reason is no agreement in KEX protocols available.

WORKAROUND:

You should use ESXi versions which are not too far away from each other in time. If you can't upgrade, you can still manually enable diffie-hellman KEX (per instance) in the [b]/etc/ssh/sshd_config[/b] of the server side.

Also, just check whether key authentication has been disabled on the same config file.

We are sorry sir, but aren't really understanding your problem.
We suspect that you have not linked servers prior to performing the backup. You cannot perform a backup without first allowing servers to communicate, hence the repeated password prompt.

You must link servers before even attempting to use XSIBackup over IP
[url]https://33hops.com/xsibackup-help-man-page.html#linksrv[/url]

Please, read the program documentation before posting to the forum, otherwise we won't be able to help you. You may start here:
[url]https://33hops.com/xsibackup-tutorial-1.html[/url]

You have most documents arranged by topic here:
[url]https://33hops.com/xsibackup-indexed-resources.html[/url]

Then, what is the problem?
Are you aware of what deduplication is and how it works?

In regards to the VMs being different, still compression plus some little help from deduplication could result in those figures.
Restore your VMs to make sure everything is O.K. if you will.

You aren't receiving errors, you are receiving messages which are pretty clear.
You don't need support, you need to read the program documentation before using it.

First of all, make sure that you can reach the server you want to copy VMs to. Not from Putty, but from server A.
Then use a [b]--backup-prog[/b] that you can use over IP (Rsync), default is [b]Vmkfstools[/b] which can be used locally only.

Thus:

./xsibackup --backup-prog=Rsync --backup-point=192.168.99.205:22:/vmfs/volumes/DATA \
--backup-type=custom --backup-how=cold --backup-vms="Mail01" --date-dir=yes

This is a message printed by the XSITools module, so things must be getting mixed somewhere somehow.

XSITools Error XSITCMP1

Read the details of how things work in version 11:
[url=https://33hops.com/xsibackup-free-11-things-that-have-changed.html](c)XSIBackup Classic: changes in version 11.0.0[/url]

Prepare your job and run it with the --run-backup=001 argument.
Make sure you kill any remain from previous attempts eventually loaded:
[url]https://33hops.com/xsibackup-most-common-issues.html[/url]

Please, note that since [b]v 11.0.0[/b] the way the cron works has changed. Changes are explained in detail here:

[url=https://33hops.com/xsibackup-free-11-things-that-have-changed.html](c)XSIBackup Classic: changes in version 11.0.0[/url]

If [b]--backupid=01[/b] is working, it's just because you are still keping the old cron redirection to [b]xsibackup-cron[/b] in the [b]/var/spool/cron/crontabs/[/b] file.

We really don't know what else to add. If you change something, do it all the way, if you miss something, things might not work.
XSIBackup already rotates logs, you have the [b]rotate_log_size[/b] general variable in the [b]conf/xsiopts[/b] file.

First of all, please, upgrade to version 11.0.3 if you have the chance. It's a lot more advanced and stable in regards to backup chaining. In fact, you cannot use [b]--del-dirs=+2d[/b] in older versions.

What you pose is correct, but: why do you split backup 01 and 02?, wouldn't it be easier to group VMs and write this instead:

/vmfs/volumes/datastore1/xsi-dir/xsibackup --backupid=01 --backup-prog=onediff \
--time="Mon 17:00|Tue 17:00|Wed 17:00|Thu 17:00|Fri 17:00|Sat 17:00|Sun  17:00" \
--backup-point="/vmfs/volumes/datastoreA" --backup-type=custom --backup-vms="vm_01,vm_02" \
--mail-from=xxx --mail-to=xxx --smtp-srv=192.168.xxx.xxx -- smtp-port=xxx --smtp-usr=xxx \
--smtp-pwd=xxx --smart-info=yes --on-success="backupid->02" --on-error="backupid->02"

We are sorry but we are not fully getting what you mean.

Jobs are stored in the xsi-dir/jobs folder.
If you want to overwrite some job, edit the job instead of creating a new one. In any case, if you assign the same BackupId to any job, it will overwrite the previous one with the same Id.

What do you mean by "XSIBackup cannot add a VM that is not present in the host", of course not. You should control vMotion to make sure your VMs are where you want them to be during the backup windows, otherwise how are you going to back them up?.

You are assuming XSIBackup has features we have never announced. XSIBackup does not integrate into a vCenter environment, it's a per host backup tool, which has its advantages on the other side. So take control of your cluster and arrange things so that you can backup your VMs from their current hosts, there are multiple ways to achieve what you want.

The most obvious way to handle the situation is to set policies in regards to vMotion, so that it does not move VMs around during the backup windows and use the [b]--backup-type=all|running[/b] argument along with [b]--disable-vmotion[/b] to backup all VMs at a given host during that backup period.