Offline
On tomorrow 's release we will:
following this we will add core xo metrics to the openmetrics ( prometheus) export to allow users and support to dig through real world data when needed
Cancelling a backup run is also on our roadmap ,as soon as we have done reworking the tasks to use xo-task on the full chain, and not an hybrid of various iteration of the tasks objects
better tracking of the backup run is also on our roadmap , this is also linked to the task changes plus are some issues with the size on the remote before being able to do this
In any case, both are on our backlog
@Pilow said in Veeam backup with XCP NG:
@olivierlambert I get you.
Same in veeam and synthetic fulls, it's only between the server/proxy and the repository.
but we get a progressing percentage while the job sits while doing the synthetic full.would be cool to "see" the progress of merging.
why ? bad habits from previous technologies used I guess.
Giving better observability is something we are working actively on , this is tightly coupled with being able to stop a task, and I hope we will be able to show the progress soon
@manilx yes, that's it
we should change the "full backup interval" to "base/complete backup interval", to clarify what is a full . And we will do it.
we are reworking the import code , along the new backup code ( https://xcp-ng.org/forum/topic/10664/our-future-backup-code-test-it ) to unify the differetn disk transformation path
For now:
@andrewreid Yes, I can't wait to share it with everybody.
@AlexD2006 thanks for signaling this, we just merged a fix, that fix it on our labs
can you test it on your side ?
https://github.com/vatesfr/xen-orchestra/pull/9202
@AlexD2006 this looks like the right issue, we will look into it immediately ( yesterday was a public holiday in France)
@Andrew then again, with such a precise report, the fix is easier
the fix should join master soon
found it , there was not one, but 2 bugs
albeit small they were putting the xo backup in a incorrect state
the fix is here, and will be merged as soon as possible and then released as a patch for xoa users
https://github.com/vatesfr/xen-orchestra/pull/8780
really thank you everyone for the information
Let me create a card do check this hypothesis ( and do a the fix @andrew )
@andrewperry hi this is an identified issue on xapi / storage side
this commit is making it visible .
Pinging @anthoineb here for more info
@Pa3docypris the other snapshots are correctly deleted ?
are these VM on a specific storage ?
Do you have anythin in the xo-server logs ( like in journalctl ) VDI_IN_USE ?
can you post the full job JSON ( on the top of the backup log there is a download button ) ? eventually by direct chat to me if you prefer to keep it private
On tomorrow 's release we will:
following this we will add core xo metrics to the openmetrics ( prometheus) export to allow users and support to dig through real world data when needed
@benapetr said in Import from VMware err: name: AssertionError: Expected "actual" to be strictly unequal to: undefined:
Hello, since this never had a clear resolution, here is explanation of the bug and why it happens:
There is a bug in disk iteration in that XO vmware plugin (somewhere in that esxi.mjs I don't remember exact location) - it basically expects that all disks of VM exist in same datastore and if they don't it crashes as the next disk in unexpectedly missing (undefined)
Workaround is rather simple - select the VM in vmware, migrate -> storage, disable DRS (important) and then select any DS that no disks current exist on. If you select and DS that is already used by same VM it will sometimes not get fixed! It also may happen even if VM is "apparently" looking like it's on single DS, even if it reports as such, still try to migrate it to another DS, and disable DRS so that really all files, even meta files are in same directory.
Then run XO import again, it will magically work.
thanks you for the input
we were under the assumption that all the disk of a VM are in the same datastore
the fix should be too hard now that you did the hard work
edit: card created in our backlog, I will take a look after the release to see how hard it is to implement
@frank-s said in S3 Timeout:
Apologies if this question has already been asked.
I have a site which is performing mirror backups to minio s3. Generally this is fine, but unfortunately the HITRON router for Virgin Media Business has a habit of hanging from time to time. The router has been changed to no avail. Apparently this is a common problem. So here is the question. If the router hangs while the s3 backup is active, how long have I got to power cycle the HITRON before the s3 connection times out?
Also is there a config file somewhere that can be used to change the timeout?
Thanks.
the timeout for a S3 connection is 10 minutes per default, but it should fail faster if the link is down.
For now the only way to force stop a backup job is to restart the xo(a)
this timeout is not configurable
thanks guy, I will connect in a few hours, and we will investigate tomorrow all day with @mathieura
@flakpyro yes, with pleasure
do you also use the rest api / xo6 ?
do you use proxies ?
@Pilow I think I remember that you have a xoa ? would it be ok to open a support tunnel a give me the number by the chat ( or by a support ticket ) ?
are you querying on of the dashboard or only the individual CRUD api ? rest api or xo cli ?
We could add some debug
@Pilow said in backup mail report says INTERRUPTED but it's not ?:
@florent not really, it is activated and I tried to fiddle a bit with it, why ?
the smaller the changes, the more we can focus on the right component(s). And december release was quite massive ( a good consequence of the team growing)
can you disable it to be sure ?
again, thank you for your help here
