Forum ©XSIBackup: ©VMWare ©ESXi Backup Software
MenuYou are not logged in.
- Topics: Active | Unanswered
#1 Re: General matters » Redirect XSIBAckup-DC 1.7.1.7 output into a log file » 2024-04-07 17:23:23
I realized that the log file that is automatically written includes a lot of #00 (ASCII character zero) before the log output actually starts. How can this be avoided? Opening such a log file with a plain text editor causes problems as you need to scroll down a long time until the relevant log file content is visible.
#2 Feature requests & improvements » XSIBackup-DC 1.7.1.7 prohibit overwriting identical file names » 2024-01-21 08:56:42
- herrep
- Replies: 1
Hi,
In one of my VMs, two VMDKs were referenced that were stored in two different folders but having the same file name:
./VM-folder/disk.vmdk
./other_folder/disk.vmdk
When replicating the VM, all files are written into the same directory so that the second disk, in the backup/replication, overwrites the data of the first disk. For obvious reasons, this problem cannot be easily overcome. However, I recommend raising an error when detecting such circumstances as the backup/replication does not work.
Best regards,
Peter
#3 General matters » Redirect XSIBAckup-DC 1.7.1.7 output into a log file » 2024-01-21 07:12:55
- herrep
- Replies: 2
Hi,
Before upgrading XSIBackup-DC to version 1.7.1.7 I was at 1.5.2.1 where I had no problems to invoke xsibackup while redirecting its output into a dedicated log file. I used the following command, adapted to the new location of xsibackup:
TS=`date +%Y%m%d%H%M%S`
/scratch/XSI/XSIBackup-DC/xsibackup <options> >> "/scratch/XSI/XSIBackup-DC/var/log/xsibackup-$TS.log" 2>&1The result now is that XSIBackup-DC creates a separate log file by its own, stored in /scratch/XSI/XSIBackup-DC/var/log/xsibackup.log. A very small portion of the log file content was in my file /scratch/XSI/XSIBackup-DC/var/log/xsibackup-$TS.log and another part in the automatically created /scratch/XSI/XSIBackup-DC/var/log/xsibackup.log.
As a second try, I removed my redirection and started again. Unfortunately, the written log file did not contain all the output that was shown on screen.
What I would like to obtain is that the full output is written into a file.
Do you have any hints as how to achieve this with the latest version of XSIBackup-DC?
Best regards,
Peter
#4 Re: General matters » XSIBackup-DC 1.5.1.9: Error code 216 signal.c Error code 1537 common.c » 2022-03-30 09:34:38
Hi,
attached below please find the job:
xsibackup \
--replica=cbt \
"VMs(vm)" \
"/backup" \
--options=R \
--quiesce \
--config-backup \
--backup-how=hotAnd here is the result:
Performing a hot backup as per the --backup-how argument.
-------------------------------------------------------------------------------------------------------------
|---------------------------------------------------------------------------------|
||-------------------------------------------------------------------------------||
||| (c)XSIBackup-DC 1.5.1.9: 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
-------------------------------------------------------------------------------------------------------------
PID: 3890004, Running job as: root
-------------------------------------------------------------------------------------------------------------
(c)XSIBackup-DC replicating data to /vmfs/volumes/nas-holzkirchen-backup/hpdl380p/replica-hot
-------------------------------------------------------------------------------------------------------------
Performing --replica action
-------------------------------------------------------------------------------------------------------------
Backup folder '/vmfs/volumes/nas-holzkirchen-backup/hpdl380p/replica-hot'
-------------------------------------------------------------------------------------------------------------
Item number 1 in this job
-------------------------------------------------------------------------------------------------------------
Available space in backup volume: 12656858333184 (11.79 TB)
-------------------------------------------------------------------------------------------------------------
vm Hardware Version is: 14
-------------------------------------------------------------------------------------------------------------
All snapshots were removed, as vm is engaged in a CBT job
-------------------------------------------------------------------------------------------------------------
Virtual Machine Name: vm
-------------------------------------------------------------------------------------------------------------
Creating snapshot VM : vm (powered on)
-------------------------------------------------------------------------------------------------------------
*** Snapshot was successfully created ***
-------------------------------------------------------------------------------------------------------------
Virtual Machine: vm
-------------------------------------------------------------------------------------------------------------
Backup start date: 2022-03-30T00:04:12
-------------------------------------------------------------------------------------------------------------
2022-03-30 00:04:12 | Backing up 28 files, total size is 66.33 GB
-------------------------------------------------------------------------------------------------------------
NUMBER FILE SIZE PROGRESS
-------------------------------------------------------------------------------------------------------------
1/28 vm.vmx 3.12 KB | Done 0.00%
-------------------------------------------------------------------------------------------------------------
2/28 vmx-vm-3606140007-1.vswp [skipped excluded]
-------------------------------------------------------------------------------------------------------------
3/28 vm.vmx.lck [skipped excluded]
-------------------------------------------------------------------------------------------------------------
4/28 vm.vmsd 536.00 B | Done 0.00%
-------------------------------------------------------------------------------------------------------------
5/28 vm_1-flat.vmdk (CBT 111) 64.00 GB | Done 0.00%
-------------------------------------------------------------------------------------------------------------
6/28 vm_1.vmdk 583.00 B | Done 96.49%
-------------------------------------------------------------------------------------------------------------
7/28 vm-aux.xml 140.00 B | Done 96.49%
-------------------------------------------------------------------------------------------------------------
8/28 vmware-722.log [REGEXP exclusion]
-------------------------------------------------------------------------------------------------------------
9/28 vmware.log 1.13 MB | Done 96.49%
-------------------------------------------------------------------------------------------------------------
10/28 vm.nvram 8.48 KB | Done 96.49%
-------------------------------------------------------------------------------------------------------------
11/28 vm.vmsd.tmp 430.00 B | Done 96.49%
-------------------------------------------------------------------------------------------------------------
12/28 vm.vmx~ 3.12 KB | Done 96.49%
-------------------------------------------------------------------------------------------------------------
13/28 vmware-717.log [REGEXP exclusion]
-------------------------------------------------------------------------------------------------------------
14/28 vmware-720.log [REGEXP exclusion]
-------------------------------------------------------------------------------------------------------------
15/28 vm.vmxf 150.00 B | Done 96.49%
-------------------------------------------------------------------------------------------------------------
16/28 vm-d6f15467.hlog 53.00 B | Done 96.49%
-------------------------------------------------------------------------------------------------------------
17/28 vmware-718.log [REGEXP exclusion]
-------------------------------------------------------------------------------------------------------------
18/28 vmware-719.log [REGEXP exclusion]
-------------------------------------------------------------------------------------------------------------
19/28 vm_1-flat.vmdk___hash 82.00 B | Done 96.49%
-------------------------------------------------------------------------------------------------------------
20/28 vmware-721.log [REGEXP exclusion]
-------------------------------------------------------------------------------------------------------------
21/28 vm-d6f15467.vswp [skipped excluded]
-------------------------------------------------------------------------------------------------------------
22/28 vm_1-ctk.vmdk [skipped excluded]
-------------------------------------------------------------------------------------------------------------
23/28 vm.vmx.tmp 3.12 KB | Done 96.49%
-------------------------------------------------------------------------------------------------------------
24/28 vm-Snapshot785.vmsn [REGEXP exclusion]
-------------------------------------------------------------------------------------------------------------
25/28 vm_1-000001-sesparse.vmdk [skipped excluded]
-------------------------------------------------------------------------------------------------------------
26/28 vm_1-000001.vmdk [skipped excluded]
-------------------------------------------------------------------------------------------------------------
27/28 vm_1-000001-ctk.vmdk [skipped excluded]
-------------------------------------------------------------------------------------------------------------
28/28 vm-quiesce_manifest785.xml [REGEXP exclusion]
-------------------------------------------------------------------------------------------------------------
Total size: 64.00 GB | Done 100.00%
-------------------------------------------------------------------------------------------------------------
*** Snapshot was removed ***
-------------------------------------------------------------------------------------------------------------
SHA-1 hashes updated for .vmdk descriptor files
-------------------------------------------------------------------------------------------------------------
Replica registered for VM vm as vm_XSIREP with Id 589
-------------------------------------------------------------------------------------------------------------
2022-03-30T00:05:57 | Error code 1537 at file common.c, line 1537 | Error description: error running command run_backup_cmd(), returned: 1
-------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------
Backup end date: 2022-03-30T00:05:54
-------------------------------------------------------------------------------------------------------------
Time taken: 00:01:42 (102 sec.)
-------------------------------------------------------------------------------------------------------------
Total time: 00:03:23 (203 sec.)
-------------------------------------------------------------------------------------------------------------
Full file speed: 642.52 mb/s
-------------------------------------------------------------------------------------------------------------
Real data speed: 15.33 mb/s
-------------------------------------------------------------------------------------------------------------
Item backup completed with errors
-------------------------------------------------------------------------------------------------------------#5 General matters » XSIBackup-DC 1.5.1.9: Error code 216 signal.c Error code 1537 common.c » 2022-03-30 06:31:12
- herrep
- Replies: 3
Hi,
My xsibackup configuration with option --replica=cbt works well over several weeks, no errors.
Last night, I found the following two errors in the backup.log. When consulting the error.log, I did not receive any additional information, please see below:
2022-03-30T00:05:57 | Error code 1537 at file common.c, line 1537 | Error description: error running command run_backup_cmd(), returned: 1
<list of VMs backed up>), error count is: 2
2022-03-30T00:24:12 | Error code 216 at file signal.c, line 216 | Error description: raised SIGTERM (11) (2) in job, total errors: 11, check error.logThese messages above are a copy of the messages already reported via backup.log. It appears that the second error message is a result of having the first error message, as it was stated below the last VM to be backed up where no issues occurred.
However, I wonder what the first error message means. In fact, it concerns a VM that had been replicated without issues the nights before. The only difference was that there was a manually created snapshot. Does this cause a conflict with the CTK-enabled replication (--replica=cbt)?
Best regards,
Peter
#6 Re: General matters » XSIBackup-DC 1.5.1.4: How to backup all _XSIREP VMs » 2022-01-31 13:03:34
I understood that version 1.5.1.5 includes a fix for REGEXP + --options=O.
However, is there also a fix for the issue when backing up a VM with excluded independent disks?
My scenario is that, in a first stage, I use --replica=cbt and --options=R to replicate an original VM with some independent disks (excluded from replication) to a _XSIREP VM and to get it registered. This stage works fine, no problem. The problem occurs in the second stage, when I want to make a deduplicated backup (no replication, no CBT) of the _XSIREP VM. The weird thing is that when specifying "server_XSIREP" to be backed up, the underlying "server" VM is backed up instead. When I backup a different VM having no independent disks, everything runs fine.
How to create a deduplicated backup from replicated VMs that have independent disks to be excluded?
#7 General matters » XSIBackup-DC 1.5.1.4: Terminate running --backup without garbling repo » 2021-12-09 10:36:08
- herrep
- Replies: 1
Hi,
When using the deduplicated backup functionality of XSIBackup-DC with option --backup, I understood that the integrity of the backup in the chosen repo directory depends on the entire chain of backups performed in this repo.
Lately, I discovered some XSIBackup-DC bugs and tried some different settings where I realized immediately after starting the deduplicated backup that this backup makes no sense. Therefore, I simply terminated ./xsibackup with kill signal SIGTERM.
Now the question arises whether such kind of termination garbles the repo or whether the SIGTERM kill signal causes ./xsibackup to clean up correctly, i.e. the last backed up VM is correctly removed from the repo so that there is nothing to worry.
Up to now, I delet the entire repo and started over again. But this is very time consuming and takes for the initial backup more than 24 hours. So I would appreciate whether it is safe to simply terminate the backup or to make same manual adaptions to keep the repo clean and tidy.
Best regards,
Peter
#8 Re: General matters » XSIBackup-DC 1.5.1.4: How to backup all _XSIREP VMs » 2021-12-09 02:03:36
I have further investigated the issue with XSIBackup 1.5.1.4 backing up the wrong VM. This problem is limited to VMs where I exclude disks because they are independent disk. As long as I backup a _XSIREP VM having no exclusions because there are no independent disks as part of the original VM, the selected _XSIREP VM is correctly backed up when specifying --options=O. As such, I can confirm that this scenario works for conventional VMs.
However, in my scenario, I have a VM named "server" which was replicated and registered as "server_XSIREP". The VM "server" has independent disks which had been excluded from backup. The independent disks are not present in the replicated "server_XSIREP", but they are still referenced in the vmx file of "server_XSIREP", but could not be found, as no path is specified.
Although I explicitly specify "server_XSIREP", the VM "server" is backed up. I tried this with a second VM having independent disks, the same result. I can successfully backup all other _XSIREP VMs, as they do not have independent disks nor exclusions.
#9 Re: General matters » XSIBackup-DC 1.5.1.4: Information or warning treated as error » 2021-12-08 17:30:03
At present, XSIBackup-DC has two major issues in conjunction with estimating whether a backup can be stored at the requested destination.
The first issue is that XSIBackup-DC cannot reliably calculate the required amount of space for a backup. For example, if you exclude files from backup, the size of the excluded files is not deducted from the required amount of space. Therefore, XSIBackup-DC reports a WARNING like this:
Not enough space to backup server: avail 12.46 TB | required 40.69 TB
However, XSIBackup-DC ignores this warning, does not raise any error and successfully completes the backup without any further issues.
Unfortunately, this behavior is not kept the same way for the second issue: Sometimes, the destination system does not correctly report back the amount of available space. This second issue, while resulting in the same situation of not being capable of predicting whether the backup will fail or not, is treated differently:
2021-11-28T21:26:33 | Error code 1547 at file common.c, line 1547 | Error description: could not get remote FS available space at ..., details: Interrupted system call
-------------------------------------------------------------------------------------------------------------
Available space in backup volume: -1 (17179.87 PB)
The result is: If XSIBackup-DC determines that the required backup space does not fit into the available backup space although it does, no error is raised. If the destination system does not report back any available space so that XSIBackup-DC does not know whether the required backup space fits into the available backup space, an error is raised although the backup has successfully completed.
I do not know what design constraints are behind this decision, but from a user experience the same result is treated differently.
#10 Re: General matters » XSIBackup-DC 1.5.1.4 {VM-Name}_XSIREP causes {VM-Name} to be backed up » 2021-12-08 09:54:32
From another post I learned that XSIBackup-DC 1.5.1.4 should correctly backup a _XSIREP VM when selecting the VM to be backed up via a VM selection mask. However, my scenario is different, as I do not use a selection mask for selecting the VMs to be backed up, but XSIBackup-DC in a script by specifying all options and parameters in text form. Consequently, I explicitly specify "server_XSIREP".
What should I debug, as specifying "server_XSIREP" as VM to be backed up with XSIBackuo-DC 1.5.1.4, either with or without --options=O, causes VM "server" to be backed up instead, while VM "server_XSIREP" remains untouched. This is weird. I have repeated this backup already three times, always the same negative result.
#11 Re: General matters » XSIBackup-DC 1.5.1.4: How to backup all _XSIREP VMs » 2021-12-08 09:51:15
What should I debug, as specifying "server_XSIREP" as VM to be backed up with XSIBackuo-DC 1.5.1.4, either with or without --options=O, causes VM "server" to be backed up instead, while VM "server_XSIREP" remains untouched. This is weird. I have repeated this backup already three times, always the same negative result. Worth to note, I do not use a selection mask for selecting the VMs to be backed up, but XSIBackup-DC in a script by specifying all options and parameters in text form. Consequently, I explicitly specify "server_XSIREP".
#12 General matters » XSIBackup-DC 1.5.1.4 {VM-Name}_XSIREP causes {VM-Name} to be backed up » 2021-12-07 19:38:32
- herrep
- Replies: 1
Hi,
When using XSIBackup-DC 1.5.1.4 to back up a VM including the postfix _XSIREP in its name, like "server_XSIREP", the corresponding VM without the _XSIREP postfix, i.e. "server", was backed up instead. The following options were used:
--backup \
"VMs(server_XSIREP)" \
Then I repeated the test by adding another option:
--backup \
"VMs(server_XSIREP)" \
--options=O \
Again, the VM "server" was backed up, and not, as specified, server_XSIREP.
This seems to be a severe bug.
#13 Re: General matters » XSIBackup-DC 1.5.1.4: How to backup all _XSIREP VMs » 2021-12-07 19:32:43
--options=O makes no difference in my setup of XSIBackup-DC 1.5.1.4. Even if I explicitly specify my {VM}_XSIREP to be backed up, then the VM with name {VM} is backed up instead. I will create a separate post for this behavior.
#14 Re: General matters » XSIBackup-DC 1.5.1.4: How to backup all _XSIREP VMs » 2021-12-07 19:25:31
Using XSIBackup-DC 1.5.1.4, I repeated my backup for all _XSIREP VMs with the following options:
"VMs(^.*_XSIREP$)" \
--options=O \
Unfortunately, the result is unchanged. Nothing is backed up:
-------------------------------------------------------------------------------------------------------------
2021-12-07T19:19:24 | Error code 2887 at file xsibackup.c, line 2887 | Error description: could not find any VM in list: ^.*_XSIREP$, please check that the VM files exist
#15 Re: General matters » XSIBackup-DC 1.5.1.4: How to backup all _XSIREP VMs » 2021-12-01 11:43:35
In my brief error description I mentioned to backup (i.e. option --backup) _XSIREP VMs. I do not use --replica, --replica=cbt or --options-R in my backup command. So my quesiton is not related to CBT and also not related to a replication, but to a deduplicated backup.
The issue is further only related to the basically working functionality of --backup that simply ghas trouble to backup VMs having a _XSIREP postfix.
My reference to --options=R was to explain how I generated the registered _XSIREP VMs: I used --replica=cbt and --options=R to replicate an original VM to a _XSIREP VM and to get it registered. As stated in the post, --options=R was set in a PREVIOUS replication, having nothing to do with --backup.
Now my issue is that I want to make a deduplicated backup from the replicated and registered _XSIREP VMs without using CBT at all. As you may see now, I do not chain a replication after a replication.
Therfore, I repeat my initial question as how to run XSIBackup-DC with option --backup on VMs that have a name ending with _XSIREP. According to my findings, XSIBackup backups the wrong VM. It appears that the _XSIREP postfix is simply ignored and the VM mathing the name in front of _XSIREP is backed up instead. And when I use a regular expression, I have no chance as _XSIREP seems to be already internally stripped from the name so that there is no match.
#16 Re: General matters » XSIBackup-DC 1.5.1.1 --replica=cbt with an excluded ctk-disabled disk » 2021-11-30 15:01:31
Thank you very much for clarifying this point!
#17 General matters » XSIBackup-DC 1.5.1.4: How to backup all _XSIREP VMs » 2021-11-28 22:05:10
- herrep
- Replies: 12
Hi,
When trying to back up a long list of replicated VMs that have been registered as _XSIREP VM by using --options=R in a previous replication, I run into two issues:
At first, I defined a long list of VMs to be backed up, like:
"VMs(server_XSIREP)"
The result was a surprise: Instead of backing up server_XSIREP, indeed the original server was backed up! This is a severe bug.
At second, I tried a regular expression to select all VMs ending with _XSIREP:
"VMs(^.*_XSIREP$)"
The result was the following error message:
2021-11-28T21:55:42 | Error code 2887 at file xsibackup.c, line 2887 | Error description: could not find any VM in list: ^.*_XSIREP$, please check that the VM files exist
So now I am stuck as I do not know how to select all my _XSIREP VMs.
Best regards,
Peter
#18 General matters » XSIBackup-DC 1.5.1.4: Calculate backup space when excluding disks » 2021-11-28 21:46:03
- herrep
- Replies: 1
Hi,
The calculation of required disk space for performing the backup is wrong when excluding disks, meaningless whether they are excluded by default (e.g. independent disks) or explicitly (by specifying exclusions in the backup options).
For example, I read the following output in my backup scenario:
Available space in backup volume: 13376550502400 (12.46 TB)
/!\ Not enough space to backup server: avail 12.46 TB | required 40.69 TB
On the other side, despite the alleged lack of free disk space, my backup succeeds, as the so-called required disk space does not exclude the size of the excluded disks.
Would you please adapt this behavior? Thank you very much.
Best regards,
Peter
#19 General matters » XSIBackup-DC 1.5.1.4: Information or warning treated as error » 2021-11-28 21:40:38
- herrep
- Replies: 4
Hi,
Once it happened that the available space in the remote FS could not be determined:
2021-11-28T21:26:33 | Error code 1547 at file common.c, line 1547 | Error description: could not get remote FS available space at /vmfs/volumes/nas-holzkirchen-backup/hpdl380p/replica-hot, details: Interrupted system call
-------------------------------------------------------------------------------------------------------------
Available space in backup volume: -1 (17179.87 PB)
The result was that the report email reported an error for replicating the respective VM:
2021-11-28T21:32:58 | Error code 4701 at file xsibackup.c, line 4701 | Error description: some error/s were raised while backing up: VMs(server.herre.at), error count is: 1
However, as long as the backup can be successfully performed, there is no need to raise an error. WOuld it be more appropriate to raise a warning or info message?
Best regards,
Peter
#20 General matters » XSIBackup-DC 1.5.1.4: Handling of independent disks in _XSIREP VMs » 2021-11-28 21:08:22
- herrep
- Replies: 1
Hi,
When replicating a VM using XSIBackup-DC options --replica=cbt --options=R and having an independent disk, the indepedent disk will be excluded from replication and therefore also not form part of the registered _XSIREP VM.
However, I realized that the vmx file in the replicated _XSIREP VM does not contain the full path of the independent disk, contrary to the full path of the independent disk defined in the vmx file of the original VM.
Is there a specific reason for doing so? I expect issues when restoring this VM from the _XSIREP version, as the path to the independent disk has got lost. With the present setup, I assume that I cannot even start the _XSIREP VM, as the location of the independent disk cannot be found. Is my assumption correct that such a _XSIREP VM canniot be started? At present, I am a bit scared to simply start the _XSIREP VM because its reference to an independent disk which is still in use by the original VM.
I wonder whether it would be dangerous to keep the original path in the replicated _XSIREP VM. Just imagine the case that the original VM is pointing to the independent disk and also, at the same time, the _XSIREP VM. My setup does NOT involve multi-writer mode for the independent disk, as a database is stored on the independent disk and parallel access from two different states of the same server would destroy data consistency.
What is the recommended way of handling such an independent disk in a _XSIREP VM?
Best regards,
Peter
#21 Re: General matters » XSIBackup-DC 1.5.1.1 --replica=cbt with an excluded ctk-disabled disk » 2021-11-28 20:31:55
From your reply I understood that it is technically not possible to replicate an independent disk via XSIBackup-DC, although its path is specified in the vmx file. Is this correct?
#22 General matters » XSIBackup-DC 1.5.1.4: No CBT replica with excluded disks CTK disabled » 2021-11-28 13:48:05
- herrep
- Replies: 1
Hi,
CBT replication works fine when all disks assigned to the VM have CTK enabled.
In my setup, I have a regular disk with CTK enabled and an independent disk that is excluded from replication with CTK disabled.
This is an excerpt of the vmx file:
ctkEnabled = "TRUE"
scsi0:0.ctkEnabled = "TRUE"
scsi0:1.ctkEnabled = "FALSE"
I started the VM with these settings and verified that the ctk file has been created.
Nevertheless, when executing XISBackup-DC in this scenario, I receive the following error:
2021-11-28T13:39:34 | Error code 149 at file esxi.c, line 149 | Error description: no matching CTK entry for disk: scsi0:0.fileName
-------------------------------------------------------------------------------------------------------------
/!\ There aren't any CTK files (-1), run --enable-cbt first, ignoring CBT flag
My other VMs where I have all disks with CTK enabled work fine with CBT replication. Nevertheless, I consider this scenario here as a bug, as the CTK disabled disk is excluded from backup so that there should be no error message.
Would it be feasible to reduce the check whether CTK is enabled to those disks that are actually replicated or backed up?
Best regards,
Peter
#23 Re: General matters » XSIBackup-DC 1.5.1.4: Error code 1522 at file common.c, line 1522 » 2021-11-27 14:51:12
Thank you very much for providing a hint as how to debug this scenario.
Unfortunately, I cannot reproduce this error again. I had some issues with extended permission settings on the NFS mounted target directory. After repairing the permissions I could execute the replication without any errors.
#24 Re: General matters » XSIBackup-DC 1.5.1.1 Backup CBT-enabled _XSIREP VMs » 2021-11-27 12:57:02
What I understood is that there is no way of using CBT on the basis of CTK-enabled disks in a chain of backups/replications where the backed up or replicated disk ("first generation") is backed up or replicated again ("second generation"). If the first replicated disks of the first generation makes use of the CBT feature, the second generation cannot use the CBT feature again.
#25 Re: General matters » XSIBackup-DC 1.5.1.1 --replica=cbt with an excluded ctk-disabled disk » 2021-11-27 12:51:47
UPDATE
Even if you enable CBT for all disks and you don't explicitly exclude the independent disk, the backup routine will just skip it for being innaccesible. The only drawback would be to have to manually exclude it from the .vmx file when restoring.
Could you shed some light on the CTK-enabled independent disk that is not explicitly excluded from backup?
I would expect that a disk that is not excluded will always be backed up or replicated. However, you wrote that the backup routine will skip the independent disk. This is what I do not understand. Why should the independent disk be excluded from backup when do not explicitly exclude it?