Dezerd

I did indeed make both changes at the same time.

The status of the backup this morning is completely normal (even on ADDS VMs).

I think that the forced shutdown in order to correct the status error caused a problem during the next delta. Why only on ADDS VMs? I can’t explain it.

I had no errors on these VMs at that time.
(Especially since I have another full backup job that doesn’t cause any problems).

It's empty. Why ?

So, as planned, I changed the snapshot to “normal” in the backup job and performed a forced shutdown on the replicated VMs.

This morning, the job status is “successful,” but two VMs (both of which have the ADDS role—this may be a coincidence) are showing this warning:

The type is still delta despite the warning message.

For alle the other VM, the backup seems ok.

Unfortunately, I need to have a CR job that works because we have a constraint this weekend.
However, I'm available to provide you with logs if necessary.

I could let you know if changing the status of the replicated VM (from suspended to forced shutdown) has an impact on the backup chain. (with normal snapshot).

Thank you for that answer.
I will make the following changes:

• Switch the snapshot to normal
• Turn off replicated VMs
• Lanch the job

Is there any documentation with details about the different snapshot modes (Normal, with memory, or offline)?

Thanks.

Hello,

Any answers to these questions?
This morning, the backup didn't run correctly (the first delta backup after yesterday's full backup). For your information, this is a delta job that has been running perfectly for months. I simply added the CR.

For your information, we have not changed the status of the CR VM; it has not changed.

Here are the errors

Thanks for this first reply.

So how restart a VM create :

• with a CR job
• with the snapshot with memory
• and keep the backup chain healthy?

For now, I'm using the "With memory" option because I think it's the best choice for reliably restoring VMs such as an AD or a SQL Server database. Am I wrong?

Hello,

We are currently testing a scheduled CR job to an SR on an xcp-ng host.
This backup takes snapshots with memory.
The VMs backed up to the SR are therefore in a suspended state.
When I try to restart the VM using the “Start a copy” option (to avoid breaking the backup chain), I get a message stating that the virtual machine is in a suspended state but should be shut down. Two questions:

• I assume that if I shut it down, I lose the benefit of suspension?
• Will the backup chain be affected if I change the VM’s state?

Thank you

Thank you.
So this host will have a separate network/storage partition since it will be in a dedicated pool?

Yes, the connection to this host should be quite good.

If I lose XOA on my master host, what is the procedure for start these replication VMs? From another XOA or Xo Lite? Once the incident is resolved, is it possible to merge the replication VM with the original VM?

Hello,

We have two hosts in a pool with 'classic' backups (Backup and delta).

I would like to mount a DR/CR plan by adding a third dedicated host of the first two in order to store the VMs ready to start.
His independence (but I may be mistaken) would allow him not to be subject to a failure of the master host.

How to add it in XOA without putting it in the same pool?

Basically, what are the best practices for this configuration?

Thank you,