@olivierlambert @DustinB @Forza May I suggest that it goes a bit further, unless it already does so. Can the VMs in Xen Orchestra show if it was backed up successfully in the most recent job. As well as when it was last backed up, if you happen to not have the report yet (or read it) you can see at a glance. That way it makes decoding the orange status for the backup job easier, so you know which ones you need to do a backup job run for. Alternatively show which ones failed and were successful, when you get the details for the job (task) in Xen Orchestra following an orange status on Xen Orchestra 6.

Ah great! It should be documented I suppose, ping @thomas-dkmt

@Disbelief5920 Backup VMs from production cluster in datacenter to separate backup storage in same datacenter. (Delta Backup. Retention <X> Monthly, <X> Weekly, <X> daily). Easily, through the scheduling system you can have the system perform Continuous Replication or a standard Delta job. Copy the backup file from production datacenter backup storage to offsite DR datacenter backup storage. (Retention possibly different than production <Y> Monthly, <Y> Weekly, <Y> daily). I think what you'd be looking at would be the "Mirror Backup" job. This'll copy your backup repo to another available repo. copy the backup from production datacenter or offsite DR datacenter to cloud storage (Backblaze) Yes, this can be completed in XO's interface or from your NAS/SAN solutions (or client side server software). Continuous replication from production cluster in datacenter to offsite DR datacenter (1-2x daily for example). I've had CR jobs running as quickly as every 5 minutes between two datacenters. Obviously bandwidth matters, once or twice a day should be perfectly doable. Is it possible to achieve the above by only backing up the production VM one time so it does not need to do 2x snapshots and 2x data copies? (1 for the backup and 1 for the replication jobs? You'd use the Delta job format for the bulk of these. Is it possible to achieve the above with only 1 transfer across the WAN instead of once for the continuous replication and once for the delta backup? No, CR is very expressly any changes that have happened, it's continuous by it's nature @Disbelief5920 said in Backup and Replication Strategy: For example, is there a scenario that would first create a backup from production to onsite backup storage, then replicate across the WAN to the backup storage, then restore the VM from the backup storage to a DR cluster? This was the production NAS/XCP-NG nodes would only have to process/copy the data once, only 1 copy would transfer across the WAN and only 1 restore from offsite backup storage to DR cluster. I'm not 100% on this scenario.... so I don't think I can readily help explain it.

@rtjdamen I was in the same situation I made a new schedule, BCK-Man with a tag BCK-Man. When I needed a manual backup, I added the tag to that VM

I would like to ask a followup question to confirm. so IF using sequences, we should disable the backup tasks on the overview tab?

Hi @olivierlambert, No performance gain to keep the snapshot. It's more the opposite. Leaving the snapshot means it will be only removed in the next job, meaning you'll have more to coalesce. However, it's very stable, CBT tends to have some quirks from time to time, so worth trying on few VMs first. Thanks - perhaps the backup documentation could have a page that covers each of these options and the pro's / con's of enabling / disabling each of them. They seem to be newer options added as they weren't even shown in the webinar video and I couldn't find any mention of them anywhere. Also, if it's better to have this option enabled, then perhaps it could be enabled by default ? I don't think it's possible now. I can ask internally if it's something that's planned already or doable in the future Thanks - that'll be good. Either option will be good. The ability to set the 'Full Backup Interval' against the individual schedule instead of the whole backup task may be all that needs to change. I'll submit a ticket to get this feature request started. Thanks Kent.

@Danp Thank you very much! Missed it

As a separate thought, do you have another instance of XO (or XOA) running somewhere which may have been configured with the xo-config file?

@florent Clear now, thanks!

Question for @florent

@olivierlambert That's awesome. Would they just show up in the detached backups list? Or is there another way to find them? Disregard. I see that they still show up in the restore tab. This is great!

@Danp said in Running a Backup Job for a Pool that wasn't previously in said backup job: @DustinB said in Running a Backup Job for a Pool that wasn't previously in said backup job: Are you suggesting for just this run I remove the old pool from this section and rerun the job? Yes. Making those changes now and running the job. Thanks for confirming

Can confirm [NOSNAP] [NOBAK] works with xen 8.2, xo 3a212. Well NOSNAP can't technicaly work, but it don't break anything.

I decided to install a new server and use ronivay's script from github to install and later update XOCE. It is working well for me and I'm not going to work on fixing the other server now.

@cgasser This sounds like a perfect candidate for the new Backup Sequence feature. See https://xen-orchestra.com/blog/xen-orchestra-5-99/ for full details.

@julien-f Merciiii my config.toml file was located under /root/.config/xo-proxy after restarting xo-proxy.service, I was able to use its local storage as a backup target. It's cleaner than creating an NFS loopback

@Bambos try restarting your hosts.

@McHenry Interesting that the CLI doesn't show the active job, but you still see it running on XO. Though I wouldn't call it a "Hidden Job" since the web console shows the operation. Jobs run in the XO API and not on a given host directly, so this is expected behavior. Would be interesting to see if a given host or pool master can see the running jobs from XO though. . .

@DustinB said in XOA Retention - entries must be sorted in asc order: I've since removed the entries in the long-term-retention field, and will validate if the backup succeeds here in a bit. Once removing the LTR records, backups succeeded. @olivierlambert said in XOA Retention - entries must be sorted in asc order: Hi, It's a known issue that will be fixed this month Good to know, thanks!

@MathieuRA Thank you!