Hello @ZakariyaKhalaf Could you show some logs for task? Do you have DNS with resolve of this name?

@andreargamgroup I can confirm that the same behavior occurs when you are using a password with UTF-8 characters. I will let you know when the fix for this problem will be ready.

Hello @user If you still have this problem, please send us the full DEBUG logs of this operation (server and node logs). If you cannot attach logs to this thread, you can put them somewhere, e.g. OneDrive or similar, and send the link. Here is the documentation on how to switch logs to debug: Logs in DEBUG

@VP Please also try to restart service, it might help. systemctl restart vprotect-server && systemctl restart vprotect-node Best regards Jan Leszczyński

@a-spinek thanks for your fast answer. This explains all.

I resolved this issue with this command: ip addr del 10.10.122.13/24 dev enp3s0

Hi, I can't see the images you uploaded. Storware had some issues with duplicated rules. It was already fixed so I would recommend updating to the latest version 6.1.0 (6.0.0 will also be fine).

Hi! After deep analysis we found, that issue is caused by deleting of snapshots files without merging it to vm. We do not this kind of operation, so it could be done only by user itself. Regards

@tomasdeltell Yes, it is.

Hi! @user NFS4.2 have support to synthetic backup, but it is necessary to use XFS under NFS share. NFS only provide possibility to use synthetic file system under share, we support XFS as Synthetic FS. The same error you have in XCP-ng. Regards

@lsroga I disconnected cdrom and ran inventory but still the same issue. I've emailed you the latest logs.

@djaw Thank you for the solution! I'll try it!

Hi, this is a known error and the fix is already in the testing phase. I will let you know when it will be available for download.

@sistemisti I solved it myself, I delete 3 VMs from the virtual environment even though I deleted all the backups of these VMs, vprotect counted them as backuped vm

@Argus thanks very much!

@Argus Thank you. I just checked my instance and for some reason it is backing up now. The jobs are still running, but they are not failing yet. I do not recall making any changes since the last communication and I will continue to monitor for results.

@tanawat do you have the same error during backup? Can you send the log from Node (/opt/vprotect/logs/node_name/vprotect_daemon.log) and from vmware service (/opt/vprotect/logs/vmware/vprotect_vmware.log) ? We need log just after the backup.

@KLM You can delete backups by removing VMs from the list in the Instances tab.

Hi @matti Disk Image Transfer requires RHV to be in version 4.3+. For version 4.2 you can only use the disk attachment strategy which gives you the possibility to do only full backups. This strategy also requires having a node installed inside the RHV cluster as a proxy vm. https://storware.gitbook.io/backup-and-recovery/protecting-virtual-machines/virtual-machines/red-hat-virtualization#disk-attachment-with-proxy-vm