Hello,
I have windows 2008R2 with SQL 2008R2 and a database of 4.3Tb, I use CR successfully (for 2+ years now), I do the transfer on a LAN link in http mode.

For a transfer on a 1G LAN, you will have a transfer time of 60-72 hours. You must set in XCP-ng the time to kill the task for 72 hours minimum, in /etc/xapi.conf line 306 set: pending_task_timeout = 259200 # 3 days in seconds.

For a transfer on a 10Gb LAN you will have a transfer of 7-14 hours.
I don't use snapshot with memory but the recovery was ok, I had an event.

Can you put an extra message at the Full backup interval, which will display what step it is until the next Full backup.
For example, as in the photo below, the first is the current one and the second is the desired one.

original one

with the desired modification

Thank you

For me is ok with fixTasks branch

I can confirm that the file *.iso importing is converted to *.img
Importing

File on share is

File on XOCE, commit 3baa37846e6dbe775a8891f51f7eaebbbb28bea6

Export the current configuration --> Settings/config.
Install an XOA appliance or manual install.
Import the saved configuration.

It seems that the task failed 5 minutes a go, with the error >> HTTP connection has timed out <<, I restarted the task and now everything is displayed.

Thank you

Hi,

I compiled version f4bf56f159db7cc6020060252fadd4a91f17641f
and I get the warning below

eslint-config-standard@17.0.0" has incorrect peer dependency "eslint-plugin-n@^15.0.0"

Backup Delta always refers to the last Full Backup. So the ones before the Full Backup can no longer be restored on a backup made after them

It is working for me to, thank you

Fallow the steps from here
https://xcp-ng.org/forum/topic/6940/xo-task-watcher-issue-cr-broken/40?_=1676708514974

@Andrew
I know about xsconsole, I thought there was something like that in XO as well as in the mentioned post where XCP-ng Center is used for this.

One more question.
How to change Management, let's say, on eth3. In the image below.

I can confirm that the file *.iso importing is converted to *.img
Importing

File on share is

File on XOCE, commit 3baa37846e6dbe775a8891f51f7eaebbbb28bea6

I will try to use this option as well, although I don't like that the files are stored as UUID.iso, I prefer to have them as names.
I prefer to have RockyLinux.9.2.iso than to have 89c425b6-42b7-11ee-be56-0242ac120002.iso.
If I can no longer recover the metadata, these UUIDs are of no use. You must identify them first.

Export the current configuration --> Settings/config.
Install an XOA appliance or manual install.
Import the saved configuration.

Windows needs a 100 GB min HDD, not 32 GB. If you want to upgrade the system with 32Gb, it's a 100% fail.

@olivierlambert
you're right, but you can't always do everything on time. And maybe you reach to this stage.
I shared this so that others, probably, can reach to this stage.
I came out with 0% damage.

This guide is for the ext4 variant with vhd.
This guide does not 100% guarantee my result for you. It is an option in case there is no other chance.

Perhaps such an option can be implemented in XO

This week I had the experience of running out of space for the coalesce task.
Real disk space 439.94 Gb, allocated space for vhd 300Gb, 139Gb executed changes, the remaining space for coalesce is 16Mb ( insufficient, minimum recommended space is 10% free = 40Gb ).

Step 0 , status of problem

Step 1.
Stop vm and move vhd to an SR with more space << command line on xcp-ng server or MC>>
1.1 move coalesce vhd first

1.2 move base vhd.

2. Rescan on the destination disk after copying the file.
   

2.1. The coalesce process started after a disk rescan, now I have the disk connected and attached to the VM, it works without data loss problems.
.

This guide gave 100% success for me, but it is not bullet proof for you so test before use

This happens when CR gives an error (does not complete backup until the end) .
Maybe an option can be activated so that Auto Start is no longer taken into account for a CR. That depends on the XO team.
The solution, for now, is that, before restarting:

• delete CR with problems ( XO importing ....)
• disable auto start on CR backup, before restarting server.

Another option is to enter on ssh on the server and stop CR with problems that started.

When I compile commit 2652c879175cdc3be65aaa2d0671c45ed33536c6
I get

warning "workspace-aggregator-47862239-6107-40a5-acc1-24242c462977 > @vates/node-vsphere-soap > soap@1.0.0" has incorrect peer dependency "axios@^0.27.2".