https://docs.xcp-ng.org/appendix/cli_reference/#appliance-commands

@Bastien-Nollet The delta backup job saves to srv04-incremental and srv12-incremental. The incremental mirror job has srv04-incremental as source and srv12-incremental as destination. The VM that showed no data to copy message was a the "Incremental backup every 4 hours - 8 days retention" backup job. Originally I only had one remote, srv04. I created srv04-incremental and renamed srv04 to srv04-full and used the mirror backup feature to copy all delta backups to srv04-incremental (as I did not want to attempt to move the data on the NFS backend side). Then, I set up srv12-incremental and srv12-full and created mirror jobs to copy from srv04-full and srv04-incremental. Once the mirror backups were completed I switched the normal backup jobs to store backups on both backup servers. I can set up a support connection if you want to remotely check this.

@bvitnik Thanks for your reply! Yes, all of the XCP-ng hosts have been restarted since I started monitoring the /var/log directory due to package upgrades. I also restarted the toolstack 2 or 3 times in the time frame so I think the issue was not caused by some sort of stuck process or similar. I did some research in this regard and also noticed that most people that have an environment of my scale do not encounter this issue (I currently have 105 VMs running). So I also suspect that there is something unusual happening in my pool. I thought about circumventing this issue by implementing a remote syslog server (like graylog) that has enough storage and letting all my XCP-ng hosts write to it. I would really prefer to fix the underlying issue though. Does anybody possibly know some common things that could cause this that I could check? That would be really awesome. Thanks and best regards

When I try to manually configure the management interface as eth0 i get this: [image: 1764648981748-b3fc2ce7-ba9a-4bf9-a39c-7be82b29d5b8-image.png] The NIC appears to be there and connected: [image: 1764649033741-344f8cd0-7d41-464e-a773-3e60c6883a26-image.png]

I hope someone will reply to my post here about how to check status on this but I believe I've resolved the main issue: I disabled and re-enabled the whole task itself yesterday and it ran this morning as scheduled.

@henri9813 yes thank you for correcting my message

@MajorP93 200gb free space was enough in my production system to cause this. The only thing I didn't try was filling it up until I found the point where it started working.

@dinhngtu said in XCP-ng Windows PV tools announcements: @probain The canonical way is to check the product_id instead https://docs.ansible.com/projects/ansible/latest/collections/ansible/windows/win_package_module.html#parameter-product_id The ProductCode changes every time a new version of XCP-ng Windows PV tools is released, and you can get it from each release's MSI: No problem... If you ever decide to have the .exe-file as a separate item. Not bundled within the zip-file. Then I would be even happier. But until then, thanks for everything!