©XSIBackup-Free: Free Backup Software for ©VMWare ©ESXi

Forum ©XSIBackup: ©VMWare ©ESXi Backup Software


You are not logged in.

#1 Re: General matters » XSIBackup-DC 1.5.1.1: --options=R ignored when using --replica » 2021-10-05 11:16:31

What should I do in the meantime? I moved from XSIBackup Classic to XSIBackup-DC and try to reconstruct a similar setup where a registered replicated VM is backed up to a deduplicated repo. I have large independent disks that are not replicated, so I am not sure whether it is safe to turn on CTK also for these disks, although they are never replicated or otherwise incrementally backed up. (Their content is backed up via other means.)

Or will you add --options=R also for --replica within the next couple of weeks?

#2 General matters » XSIBackup-DC 1.5.1.1: --options=R ignored when using --replica » 2021-10-05 10:50:46

herrep
Replies: 3

Hi,

Originally, I started with a CBT-based replication of a VM that is properly registered as _XSIREP VM by using options --replica=cbt and --options=R.

However, for some VMs, I disabled CBT and changed the options to --replica and --options=R. I deleted the previously generated _XSIREP VM and cleaned up everything related to CBT. I still would like to get the replicated VM registered, but without CBT.

Unfortunately, --options=R does not show any effect, although the replication takes place on the same ESXi host. I can successfully replicate the VM, but the replicated VM is not registered. I neither find an output concerning a failed registration in the regular log file nor in the error log.

Is it planned behavior that --options=R only works in conjunction with --replica=cbt or is this a result of a strange setup on my side that requires further investigation?

Best regards,
Peter

#3 General matters » XSIBackup-DC 1.5.1.1 --replica=cbt with an excluded ctk-disabled disk » 2021-09-30 16:03:49

herrep
Replies: 1

Hi,

In my present replication setup, I use options --replica=cbt and --options=R to create a replicated VM that is registered again.

This works with some restrictions as long as all disks assigned to the VM are ctk-enabled. However, I also have VMs which include some independent disks which are even excluded from the replication. As they are excluded, there is no need to enable ctk for them as the respective ctk files would never be used. So I disabled ctk for these indendent disks and used option --exclude to ensure that the data of such disks does not need to be transferred.

As soon as I start replication, I receive the following error message:

2021-09-30T15:49:43 | Error code 149 at file esxi.c, line 149 | Error description: no matching CTK entry for disk: scsi0:1
-------------------------------------------------------------------------------------------------------------
/!\ There aren't any CTK files (-1), run --enable-cbt first, ignoring CBT flag
-------------------------------------------------------------------------------------------------------------

The above finding, i.e. scsi0:1 being not ctk enabled and therefore having no CTK files, is correct. But exactly this disk is excluded from backup. The other disk, scsi0:0 is ctk enabled and a CTK file is available. Unfortunately, --replica=cbt does not seem to support such a scenario where not all disks are ctk enabled although all disks to be transferred are ctk enabled.

Did I miss something or would it be necessary to consider these circumstances properly?

Best regards,
Peter

#4 Re: General matters » XSIBackup-DC 1.5.1.1: Which files to exclude from backup --replica=cbt » 2021-09-29 16:04:51

I would assume that it implies a risk in performing hot backups if the memory state is not saved. But probably I did not fully understand the way how the hot backup/replication is performed. Therefore, I would appreciate if you could shed some light onto hot backups in conjunction with not considering the memory state.

#6 Re: General matters » XSIBackup-DC 1.5.1.1: Which files to exclude from backup --replica=cbt » 2021-09-29 15:30:03

Good to know that non memory snapshots are taken by xsibackup. Am I right that --backup-how=hot is equivalent to restoring the disk state at the point of the backup/replica, but the memory state is lost, like when switching of the VM without shutdown? However, this should have no impact on cold and warm backups, as the VM is shut down, thereby having no memory state at all.

#7 Re: Feature requests & improvements » XSIBackup-DC 1.5.1.1: --enable-cbt without starting the VM afterwards » 2021-09-29 15:22:12

From your comments I understood that it is NOT a requirement to start the ctk enabled or ctk reset VM after a change of the ctk settings. If this understanding is correct, I would recommend to start a VM after ctk actions only if the VM state prior ctk actions was running. Otherwise the VM should remain in off state.

However, if there is a way to circumvent this behavior by running the appropriate ctk actions by myself, this is fine.

With regard to --enable-cbt, I understand that the only action performed by xsibackup are ctk enable actions applied to the respective VM which can clearly also be done independent from xsibackup.

What needs to be done for --reset-cbt? Would be the correct replacement handling to disable ctk and then enable ctk again, and, in addition, to delete the .xsi folder within the VM folder?

#8 Feature requests & improvements » XSIBackup-DC 1.5.1.1: --options=R independent from --replica=cbt » 2021-09-27 12:38:17

herrep
Replies: 1

Hi,

The xsibackup options --replica=cbt for replicating a VM and --options=R for registering the replicated VM can only be used if the VM is replicated to a destination path that is either mounted by the same ESXi host or, in case of using a remote path, when the destination system is also an ESXi host. This is quite clear, as registration of the replicated VM requires an ESXi host.

At present, it is already possible to register the replicated VM, even if it is stored on a remote system like a Synology NAS, as long as the disk at the remote system is mounted at the local ESXi host, for example by using NFS.

So it is possible to replicate and register the replicated VM on the same ESXi host, although the files are remote to the ESXi host.

I would like to improve performance by performing --replica=cbt by specifying the remote path and using xsibackup executed on the Synology NAS. However, once I specify the remote path, the remote xsibackup cannot register the replicated VM as the Synology NAS is not an ESXi host.

Therefore, I would like to process the --options=R in a separate step, after having performed the replication via remote path, were I specify the path to the replicated VM via the NFS drive of the Synology NAS mounted at the ESXi host.

Would this be feasible?

Best regards,
Peter

#9 Re: General matters » XSIBackup-DC --replica=cbt: --options=R appears to be without function » 2021-09-27 12:27:40

I believe that there is still some room for discussion with regard to --options=R (registration) in conjunction with a remote path. I will describe the situation in a new post so that we can close the thread here.

#10 Re: Feature requests & improvements » XSIBackup-DC 1.5.1.1: --enable-cbt without starting the VM afterwards » 2021-09-27 12:24:04

The same also applies to --reset-cbt were the VM is also started even if it was turned off before.

#11 Feature requests & improvements » XSIBackup-DC 1.5.1.1: --enable-cbt without starting the VM afterwards » 2021-09-27 10:16:23

herrep
Replies: 4

Hi,

when I use --enable-cbt on a running VM, the VM is stopped and afterwards started again. This is fine. However, if the VM is stopped (because of a previous shutdown, for example) prior to --enable-cbt, the VM will be started nevertheless.

Is it a requirement to start the VM for properly setting up CBT, or could this behavior optimzed so that only previously running VMs are started again after --enable-cbt?

Best regards,
Peter

#12 Re: General matters » XSIBackup-DC 1.5.1.1: Which files to exclude from backup --replica=cbt » 2021-09-27 09:58:41

Thanks for clarification. Just to make sure: When I run --replica as hot backup without shutting down the VM during replication, I assume that .vmsn contains the memory state of the machine. Therefore, the old .vmsn files are not of any use as I cannot revert the VM to a previous state, but the last .vmsn is essential if I want to continue right after the point of having performed the replication. Therefore, I can delete all "old" .vmsn files in the replicated VM directory, but should keep the last .vmsn file. Is this correct?

#13 Re: Feature requests & improvements » XSIBackup-DC 1.5.1.1: Further hints on --backup-cbt » 2021-09-27 09:54:07

Unfortunately, the above-posted backup job does not work.

Prior to --backup=cbt, I have executed --enable-cbt on each _XSIREP VM. The following problems occur, for which I created separate posts to discuss them individually:

a) "VMs(^_XSIREP$)" cannot detect any of my VMs ending with _XSIREP,
b) When I replace the above VMs regexp by a long list of VMs, xsibackup reports that --enable-cbt has to be executed first (although I have done this), and
c) When I use a remote path working correctly with --replica=cbt, under --back=cbt the missing repo directory could not be created.

So further guidance is needed as how to backup as suggested above.

#14 General matters » XSIBackup-DC 1.5.1.1 --backup=cbt no folder create with remote » 2021-09-26 21:49:20

herrep
Replies: 0

Hi,

When using --backup=cbt and specifying an NFS drive (mounted as datastore in ESXi) as backup destination, the repo directory is created.
In fact, the NFS drive is remote, and I can also specify a remote path, as xsibackup is availabkle on the NAS.

As long as I use --replica, the remote path works and missing directories are correctly created.
However, once I switch to --backup=cbt and specifying the same remote path that works with --replica, I receive the following error message:

Performing --backup action
-------------------------------------------------------------------------------------------------------------
ckup/repo-202109': Not a directory
-------------------------------------------------------------------------------------------------------------
2021-09-26T17:27:52 | Error code 3254 at file xsibackup.c, line 3254 | Error description: something went wrong creating the backup folder at: <nas>/backup/repo-202109
-------------------------------------------------------------------------------------------------------------
202109': Not a directory
-------------------------------------------------------------------------------------------------------------
2021-09-26T17:27:53 | Error code 4364 at file common.c, line 4364 | Error description: something went wrong creating the data folder at: <nas>/backup/repo-202109/data, error: Illegal seek
-------------------------------------------------------------------------------------------------------------
o-202109': Not a directory
-------------------------------------------------------------------------------------------------------------
2021-09-26T17:27:54 | Error code 4373 at file common.c, line 4373 | Error description: something went wrong creating the config backup folder at: <nas>/backup/repo-202109/cfgbak, error: Illegal seek
-------------------------------------------------------------------------------------------------------------

In my setup, the same backup drive can be accessed from the ESXi via NFS mount locally or via a remote path.

What I can see is that, when using --backup=cbt and remote path, a file "repo-202109" is created, but not a directory. As already mentioned, when using --replica, the creation of directories works fine, meaningless whether I use the remote path or the local NFS mounted drive as destination. With --backup=cbt, I can only use a local path, not the remote path.

Best regards,
Peter

#15 General matters » XSIBackup-DC 1.5.1.1 Backup CBT-enabled _XSIREP VMs » 2021-09-26 21:39:20

herrep
Replies: 0

Hi,

In my backup scenario, I start with replicating my original VM with --replica=cbt and --options=R to receive a registered _XSIREP VM. Then, I would like to --backup=cbt the registered _XSIREP VM. Therefore, I ran --enable-cbt first on the _XSIREP VM. This seem to work fine.

Nevertheless, when starting --backup=cbt onto the _XSIREP VM, I receive the following error message:

be enabled, run --enable-cbt="<vm>_XSIREP" first
2021-09-26T17:29:33 | Error code 216 at file signal.c, line 216 | Error description: raised SIGTERM (11) (2) in job, total errors: 11, check error.log

The error.log does not report anything beyond this.

What did I miss? --replica-cbt works fine after having performed --enable-cbt on the respective VM, but this procedure does not seem to work when using --backup=cbt.

Best regards,
Peter

#16 General matters » XSIBackup-DC 1.5.1.1 VMs not selectable via regexp with --backup=cbt » 2021-09-26 21:30:05

herrep
Replies: 0

Hi,

What I am doing wrong when I want to backup VMs based on a regexp in back mode --backup=cbt?

I entered:

"VMs(^.*_XSIREP$)"

to select all my CBT replicated and registered VMs which end with "_XSIREP". Nevertheless, I receive the following error message:

2021-09-26T17:22:31 | Error code 2882 at file xsibackup.c, line 2882 | Error description: could not find any VM in list: ^.*_XSIREP$, please check that the VM files exist

When I create a long list of all VMs separated by commas, I can backup them.

Best regards,
Peter

#17 Feature requests & improvements » XSIBackup-DC 1.5.1.1: Further hints on --backup-cbt » 2021-09-26 15:19:18

herrep
Replies: 5

Hi,

My way of backing up the VMs is to first create a replica of the VMs by using --replica=cbt and --options:R to receive replicated _XSIREP VMs that are registered at the ESXi host.

Now I want to continue and make a deduplicated backup from the replicated _XSIREP VMs. Up to now, I used the --backup functionality.

However, I noticed that starting with XSIBackup-DC 1.5.1.0 there is also CBT support for backup, i.e. --backup=cbt. I searched the manual to find some more background information and impact on particularly using --backup=cbt instead of --backup, but I could only find detailed information in conjunction with --replica=cbt.

I would like to clarify the prerequisites for moving from --backup to --backup=cbt:

Is it sufficient to --enable-cbt on the _XSIREP VMs and to start backup with a fresh repository when switching to --backup=cbt?

I would create a new repo each month, e.g. like this:

REPODATE=`date +%Y%m`
"<path>/XSIBackup-DC/xsibackup" \
--backup=cbt \
"VMs(^_XSIREP$)" \
"root@<nas>:22:<volume>/backup/repo-$REPODATE" \
--compression=yes \
--config-backup \
--backup-how=cold \
--remote-path="/usr/bin/xsibackup"

Is this setup recommendable? Particular drawbacks?

Best regards,
Peter

#18 Re: General matters » XSIBackup-DC 1.5.1.1: Which files to exclude from backup --replica=cbt » 2021-09-26 14:25:23

I run replica cbt with hot backup, so I assume it would be good to keep always the latest .vmsn file so that the replicated VM contains also the active state information. Is my understanding correct that in such a replicated VM only keeping the last .vmsn file makes sense? I wonder why all previous .vmsn files and all previous quiesce manifest .xml files are kept when there is already the next cbt cycle?

According to my understanding, the replicated VM does not allow to roll back to a previous CBT cycle. For this purpose, I would need to deduplicate backup the replicated VMs. Then I can access any CBT cycle. Is my understanding correct?

For the purpose of using the replicated (and registered) VM, I assume that none of quiesce manifest .xml file is necessary - they are only relevant for analysis. Is my understanding correct?

#19 Re: General matters » XSIBackup-DC --replica=cbt: --options=R appears to be without function » 2021-09-26 12:59:12

If I understood you correctly, you suggest to replicate the VM to the NAS by addressing the NAS destination by its NFS volume that is configured as datastore at the local ESXi host. This is exactly what I did.

However, my question was a kind of optimization: I understand that using xsibackup remotely on the NAS reduces load on the ESXi host so that a replication using the remote address of the NAS would increase performance.  Therefore, my question arose whether it would be possible to use the remote address for the copy part and as soon as --options=R will result in VM registration, a local path of the NFS volume is specified so that the remotely stored VM will nevertheless be registered at the local ESXi host.

#20 Re: General matters » XSIBackup-DC --replica=cbt: --options=R appears to be without function » 2021-09-25 20:43:33

I got the point that a backup destination specified on a remote host having no ESXi functionality cannot lead to a registration of a replicated VM. However, in my setup, the backup destination is also accessible as an NFS drive at the ESXi host.

Of course, I continued in the present case by replacing the remote destination by a local path which results in storing the replicated VM on the same location as previously, but with the ability of being registered afterwards. Now I wonder whether there is a way of optimizing this setup.

I would prefer transferring the VM data via the remote path with xsibackup remotely executed on the NAS. And then, once the data are over there, I would like to register the replicated VM, but of course over the local path. Would this be somehow possible, e.g. bei running --options=R separately or whatever?

Or would this be a new feature request resulting in an option to specify the local path?

#21 Feature requests & improvements » XSIBackup-DC 1.5.1.1: VM mismatch --replica=cbt / new backup location » 2021-09-25 20:38:20

herrep
Replies: 1

Hi,

After having enabled CBT for a VM and performed the first full replication, I realized that the backup location was wrong. Therefore, I manually unregistered and deleted the resulting _XSIREP VM and performed --reset-cbt followed by an --enable-cbt for this CBT to start over again at the new backup location. Furthermore, I already run the suggested commands to overcome registration issues:

/etc/init.d/hostd restart
/etc/init.d/vpxa restart

While the CBT replication seems to work fine for other VMs where I did not had this issue with a wrong backup location in the first place, VmWare still has stored some information concerning the ctk enabled disks so that the new set up replication with option --replication=cbt and --options=R failed. The error log shows:

2021-09-25T20:15:04 | Error code 1168 at file esxi.c, line 1168 | Error description: can't remove all snapshots for VM -1
2021-09-25T20:15:04 | Error code 3540 at file xsibackup.c, line 3540 | Error description: can't remove all snapshots for VM <myvm>
2021-09-25T20:15:05 | Error code 3574 at file xsibackup.c, line 3574 | Error description: could not unregister VM(101) <myvm>_XSIREP, error: 

However, I found out that --reset-cbt is not sufficient. It is required to manually disable CBT in the VM, i.e. ctkenable to false for both the general settings as well as for the respective disk. I did this with a powered off VM and without snapshots.  Then I could start over again without issues.

Would it be possible to integrate the disabling of ctk also into --reset-cbt?

Best regards,
Peter

#22 General matters » XSIBackup-DC 1.5.1.1: Which files to exclude from backup --replica=cbt » 2021-09-25 20:13:03

herrep
Replies: 9

Hi,

When replicating a VM using option --replica=cbt in a quiesced hot backup, I realize that each time a quiesce manifest .xml file is created and a snapshot .vmsn file. Besides the vmware-*.log files. So the files get more and more.

Is it fine to delete these files in regular intervals from the VM directory?
Is it fine to exclude these files from replication?

Best regards,
Peter

#23 General matters » XSIBackup-DC 1.5.1.1: CBT count increased by 4 each replication » 2021-09-25 20:02:33

herrep
Replies: 1

Hi,

When I created the first CBT based replication for a number of VMs, the log file showed CBT 1 for each of these VMs when executing the replication with option --replica=cbt.

On subsequent runs, I would expect that CBT is always incremented by 1 so that we have CBT 2, then CBT 3 and so on.

However, what I realized was that CBT was increased by 4 for each run, so the sequence was CBT 1, CBT 5, CBT 9, CBT 13.

Is there anythig I have to worry because of this?

I made a simple test where I just executed another replication run right after having finished the previous one. So I cannot image that another process was interfering in between that caused an extra increment.

Best regards,
Peter

#24 Feature requests & improvements » XSIBackup-DC 1.5.1.1: Warning message Not enough space to backup VM » 2021-09-25 17:40:11

herrep
Replies: 1

Hi,

When performing a cold backup of my virtual machines, XSIBackup-DC 1.5.1.1 performs a calculation of the required space to perform the backup. It appears that all files are taken into consideration that are located in the selected VM directories, even if particular files are excluded from backup through the use of an --exclude regexp pattern.

In my case, I see the following line in the log file:

/!\ Not enough space to backup <vm-name>: avail 9.71 TB | required 40.66 TB

As already mentioned, the backup is successfully performed in my case, as only an amount of data far less than the available space will indeed be backed up. Nevertheless, this warning message is not appropriate. Would it be possible to improve the calculation so that the exclusion pattern will be properly taken into account?

Best regards,
Peter

#25 Re: General matters » XSIBackup-DC --replica=cbt: --options=R appears to be without function » 2021-05-19 12:30:32

In the mean time, I simplified the backup command as follows:

"/vmfs/volumes/hdd/XSIBackup-DC/xsibackup" \
--replica=cbt \
"VMs(ups-vm)" \
"root@nas:22:/volume1/backup" \
--options=R

Prior to backup, I emptied the vm directory at the target. However, the result was unchanged. The backup as such was reported as successful, but when analyzing the replicated vmx-file, I noticed that it is still unchanged, i.e. no _XSIREP appended. There is also no registration on the ESXi host. Here is the xsibackup.log:

|---------------------------------------------------------------------------------|
||-------------------------------------------------------------------------------||
|||   (c)XSIBackup-DC 1.5.0.3: Backup & Replication Software                    |||
|||   (c)33HOPS, Sistemas de Informacion y Redes, S.L. | All Rights Reserved    |||
||-------------------------------------------------------------------------------||
|---------------------------------------------------------------------------------|
                   (c)Daniel J. Garcia Fidalgo | info@33hops.com
|---------------------------------------------------------------------------------|
System Information: ESXi, Kernel 6 Major 7 Minor 0 Patch 0
-------------------------------------------------------------------------------------------------------------
License: 000306E40000000000000000d89d67195a68 | (c)XSIBackup-DC
-------------------------------------------------------------------------------------------------------------
Remote system: Linux
-------------------------------------------------------------------------------------------------------------
PID: 34570689, Running job as: root
-------------------------------------------------------------------------------------------------------------
Remote xsibackup binary found at: /bin/xsibackup
-------------------------------------------------------------------------------------------------------------
(c)XSIBackup-DC replicating data to /volume1/backup
-------------------------------------------------------------------------------------------------------------
Performing --replica action
-------------------------------------------------------------------------------------------------------------
Item number 1 in this job
-------------------------------------------------------------------------------------------------------------
ups-vm Hardware Version is: 14
-------------------------------------------------------------------------------------------------------------
All snapshots were removed, as ups-vm is engaged in a CBT job
-------------------------------------------------------------------------------------------------------------
Virtual Machine Name: ups-vm
-------------------------------------------------------------------------------------------------------------
Creating snapshot VM : ups-vm (powered on)
-------------------------------------------------------------------------------------------------------------
*** Snapshot was successfully created ***
-------------------------------------------------------------------------------------------------------------
Virtual Machine: ups-vm
-------------------------------------------------------------------------------------------------------------
Backup start date: 2021-05-19T11:34:43
-------------------------------------------------------------------------------------------------------------
2021-05-19 11:34:43 | Backing up 26 files, total size is 11.20 GB
-------------------------------------------------------------------------------------------------------------
    NUMBER	                                                   FILE             SIZE          PROGRESS
-------------------------------------------------------------------------------------------------------------
    1/26                                               ups-vm.vmx          2.86 KB    | Done   0.00%
-------------------------------------------------------------------------------------------------------------
    2/26                                ups-vm-flat.vmdk (CBT 17)         10.00 GB    | Done   0.00%
-------------------------------------------------------------------------------------------------------------
::: detail ::: 100.00% done | block 10240 out of 10240                                      | Done  89.27%
-------------------------------------------------------------------------------------------------------------
    3/26                                              ups-vm.vmdk        596.00 B     | Done  89.27%
-------------------------------------------------------------------------------------------------------------
    4/26                                              ups-vm.vmsd        455.00 B     | Done  89.27%
-------------------------------------------------------------------------------------------------------------
    5/26                                           ups-vm-aux.xml         13.00 B     | Done  89.27%
-------------------------------------------------------------------------------------------------------------
    6/26	                     vmx-ups-vm-1802602466-2.vswp                    [open excluded]
-------------------------------------------------------------------------------------------------------------
    7/26	                                   ups-vm.vmx.lck                 [skipped excluded]
-------------------------------------------------------------------------------------------------------------
    8/26                                                 vmware-617.log        219.98 KB    | Done  89.27%
-------------------------------------------------------------------------------------------------------------
    9/26                                                 vmware-618.log        263.72 KB    | Done  89.27%
-------------------------------------------------------------------------------------------------------------
   10/26                                             ups-vm.nvram          8.48 KB    | Done  89.27%
-------------------------------------------------------------------------------------------------------------
   11/26                                                 vmware-619.log        223.89 KB    | Done  89.27%
-------------------------------------------------------------------------------------------------------------
   12/26                                  ups-vm-flat.vmdk___hash         82.00 B     | Done  89.27%
-------------------------------------------------------------------------------------------------------------
   13/26                                                     vmware.log        333.84 KB    | Done  89.27%
-------------------------------------------------------------------------------------------------------------
   14/26                                              ups-vm.vmx~          2.85 KB    | Done  89.28%
-------------------------------------------------------------------------------------------------------------
   15/26                                          ups-vm.vmsd.tmp         45.00 B     | Done  89.28%
-------------------------------------------------------------------------------------------------------------
   16/26                                           ups-vm.vmx.tmp          2.85 KB    | Done  89.28%
-------------------------------------------------------------------------------------------------------------
   17/26                                                 vmware-614.log        220.84 KB    | Done  89.28%
-------------------------------------------------------------------------------------------------------------
   18/26                                                 vmware-616.log        358.92 KB    | Done  89.28%
-------------------------------------------------------------------------------------------------------------
   19/26                                                 vmware-615.log        220.83 KB    | Done  89.28%
-------------------------------------------------------------------------------------------------------------
   20/26	                             ups-vm-6b7187e2.vswp                    [open excluded]
-------------------------------------------------------------------------------------------------------------
   21/26                             vmx-ups-vm-1802602466-1.vswp         80.00 MB    | Done  89.28%
-------------------------------------------------------------------------------------------------------------
   22/26	                                  ups-vm-ctk.vmdk                 [skipped excluded]
-------------------------------------------------------------------------------------------------------------
   23/26                                  ups-vm-Snapshot536.vmsn         19.48 KB    | Done  89.98%
-------------------------------------------------------------------------------------------------------------
   24/26	                      ups-vm-000001-sesparse.vmdk                 [skipped excluded]
-------------------------------------------------------------------------------------------------------------
   25/26	                               ups-vm-000001.vmdk                 [skipped excluded]
-------------------------------------------------------------------------------------------------------------
   26/26	                           ups-vm-000001-ctk.vmdk                 [skipped excluded]
-------------------------------------------------------------------------------------------------------------
Total size:                                                                     10.08 GB    | Done 100.00%
-------------------------------------------------------------------------------------------------------------
*** Snapshot was removed ***
-------------------------------------------------------------------------------------------------------------
Backup end date: 2021-05-19T11:35:37
-------------------------------------------------------------------------------------------------------------
Time taken: 00:00:54 (54 sec.)
-------------------------------------------------------------------------------------------------------------
Total time:       54 sec.
-------------------------------------------------------------------------------------------------------------
Full file speed:	                                                                   191.15 mb/s
-------------------------------------------------------------------------------------------------------------
Real data speed:	                                                                   104.84 mb/s
-------------------------------------------------------------------------------------------------------------
Item backup completed without errors
-------------------------------------------------------------------------------------------------------------
Final checksum: 110351964 bytes were sent and confirmed to have been written remotely
-------------------------------------------------------------------------------------------------------------
Data processing completed successfully
-------------------------------------------------------------------------------------------------------------
Removed host <tmp> dir        OK
-------------------------------------------------------------------------------------------------------------
Removed prog <tmp> dir        OK
-------------------------------------------------------------------------------------------------------------
Unlocked backup               OK
-------------------------------------------------------------------------------------------------------------

After this test, I run --reset-cbt, deleted the directory of that vm at the target and started again. Besides that now a CBT 1 full cycle was started, I had the same result of no changed vm name and no registration.

As the xsibackup.log is entirely silent about what is going on, is there any option to increase verbosity to see what is indeed happening?

Board footer