Hi,
Thank you for your report.
The bug is introduced by the recent version of a library that we are using.
We'll fix it ASAP.
Hi,
Thank you for your report.
The bug is introduced by the recent version of a library that we are using.
We'll fix it ASAP.
@s-pam said in Multiple remotes in a backup - how is retention calculated:
OK Great. So if I set retention to 10, it would keep 10 copies on each remote?
Yes. it will keep 10 copies on each remote.
Hi,
For the first question, you can use cpusMax
to set the CPUs limit. xo-cli vm.create cpus=2 cpusMax=4
Currently, there is no way to add a predicate to the job execution.
But, it's possible to do a work-around that responds to your need using xo-cli
and your cron
.
You can let your cron
run manually the backup job using xo-cli backupNg.runJob id:jobId schedule:scheduleId
.
@Anonabhar It seems that the property snapshot-of
isn't correctly reported by XO
. Did you tried to disconnect/reconnect the server containing this snapshot to see if it resolves your issue?
And please give me the version of your xo-server
.
Hi,
Thank you for your report.
Indeed, there is an issue with the display of Disk (Used/Total)
.
The fix for this issue is under validation, it will be merged ASAP.
@pdonias Indeed, it's related to the audit changes.
@cocoon Thank you for your report.
I've just created a PR on Github which fix this issue.
Please follow it to get it's evolution. Feel free to test it and give us your feedback.
Thank you!
Hi,
Unfortunately, it's not possible to do it. You can only define days which the backup will be executed or a days of the week without week interval.
I've created a feature request on Github. Please follow it to get its evolution.
The CR
is a functionality which exports the VM
at the first time then it exports only the diff for optimization.
This functionality needs a snapshot to be kept on the VM
. Unfortunately when a job contains two schedules which one is for CR
, one schedule will delete the snapshot created by the CR
then the CR
will always export the full VM
instead of the diffs.
Hi,
For your first question, created snapshots will not interfere with the CR
.
For your last question, by design and performance, you can' t set one CR
for rotating servers.
So, you need:
CR
with enabled Rolling Snapshot
which will backup your VM
from XCP01
to XCP02
and will create 5 snapshots.CRs
one will backup your VM
from XCP01
to B01
and the second will backup it from XCP01
to B02
. These jobs will create 2 snapshots.Total snapshots created by these jobs: 7
Hi,
Thank you for your report.
The bug is introduced by the recent version of a library that we are using.
We'll fix it ASAP.
Indeed, all backups are independent. Each execution results on a backup and only removes its created backups regarding the retention.
For the third point, you want to backup VMs using a live ISO? What do you expect as backup behavior? Thank you
Hi @mauzilla
Hi,
This error can be triggered on parsing a non-JSON data by using JSON.parse()
or JSON.parse('u')
.
Please install xo-cli and give me the resulted file of the bellow command.
xo-cli backupNg.getAllLogs ndjson=json:true @=<outputFilePath>
Hi @xo-g ,
We don't use any specific order to pick the VMs
to backup.
@s-pam said in Multiple remotes in a backup - how is retention calculated:
OK Great. So if I set retention to 10, it would keep 10 copies on each remote?
Yes. it will keep 10 copies on each remote.
Hi @S-Pam
The backups' retention is specific to schedules. So, the schedule's retention is applied to all backup job's remotes.
@nodesocket Did you previously canceled a VM export? This can be linked to this issue https://github.com/vatesfr/xen-orchestra/issues/5535.
Please restart your xo-server
to see if it resolves your issue.
@nodesocket Hi,
Can you check how many parallel VMs
can you export in this configuration /etc/xo-server/config.toml
? Did you canceled an export before?
Thank you