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.
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.
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 @hdstart,
I believe you have version 6.2.0 in mind
If yes, please edit /opt/vprotect/vprotect.env
file and uncomment below lines:
#LIBGUESTFS_BACKEND="direct"
#LIBGUESTFS_BACKEND_SETTINGS="force_tcg"
then restart vprotect-node service and rerun the backup.
Thank you for your suggestion. I will submit a request to update the documentation accordingly.
Hi,
Did you select the correct backup destination in your policy?
Could you please confirm which user account is being used to connect to vCenter? Additionally, could you provide the versions of both vCenter and the ESXi hosts?
Hi,
The error OPEN_DISK_HANDLER. Error code: 13 typically indicates an issue with accessing the disk or file. This is most often related to a network connection problem or a file access/permission error within VMware. Could you please attempt to restore this VM to a different datastore? Additionally, have there been any recent updates to VMware vCenter or the ESXi hosts?
Thank you for your suggestion. I will submit a request to update the documentation accordingly.
Hi, Proxmox usually requires the use of a root account (most of the command line tools are currently root only). Therefore, we also recommend using a root account to connect with Storware.
As a workaround, you can try to add this user to the sudo group, but we do not guarantee that all functions will work properly. Such a scenario was never tested and is not supported.
Hello @jako,
thank you for the great idea! I will put this in our backlog
Hi @hdstart,
I believe you have version 6.2.0 in mind
If yes, please edit /opt/vprotect/vprotect.env
file and uncomment below lines:
#LIBGUESTFS_BACKEND="direct"
#LIBGUESTFS_BACKEND_SETTINGS="force_tcg"
then restart vprotect-node service and rerun the backup.
Hello @victors,
This new limitation was introduced in the 6.2 version of Storware Backup & Recovery. In this strategy, you can make only full backups of OpenStack instances because every time a snapshot is kept on the VM, the disk type changes to QCOW2.
Incremental backups are only available for CEPH volumes in SSH/libvirt strategy,
@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.
@andreargamgroup Sorry for the late response. This error is thrown from the Python packages.
if isinstance(username, str):
username = username.encode('latin1')
if isinstance(password, str):
password = password.encode('latin1')
Do you have special characters in the password? If yes, can you try to set a password with only letters and check if this will work as a workaround?