CR - Cannot start copy because suspended

Dezerd

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

poddingue

Hello,

I think the suspended state is deliberate here. With the RAM option on a CR job, the docs say the copy is left suspended on purpose, so you can resume it quickly instead of booting it: https://docs.xen-orchestra.com/xo5/backups#continuous-replication-with-ram.
That would explain why "Start a copy" refuses, since it seems to want a halted VM.

On your first question, I'd expect a shutdown to throw away the captured memory, so the fast resume is gone for that copy until the next run rebuilds it. I'm going from the docs there rather than from experience.

Your second question I can't answer. I don't know the backup internals well enough to say whether changing the replica's state disturbs the chain, and I'd rather not guess when a wrong answer could cost you a backup.

Dezerd

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?

Dezerd

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

poddingue

On your second question I still can't give you a firm answer, and it has now been asked twice, so @Team-XO-Backend would be the people to confirm what changing the replica's power state does to the chain.

On whether "With memory" is the right call, your reasoning does match what the docs say. The "Consistent backup" section is marked deprecated and says RAM enabled backup replaces it: https://docs.xen-orchestra.com/xo5/backups#consistent-backup. So for AD or SQL Server, that is the route the docs point you at now rather than the old quiesced one.

poddingue

Two things, and the first is a correction to what I posted earlier.

I was wrong about the memory option. I said your reasoning matched the docs, and it does, but the docs are wrong on this point. I checked with the backup team: we do not handle application consistency in backups at the moment, quiescing was removed, and restoring a domain controller from a RAM image can roll replicated state backwards and cause replication problems. Nobody would vouch for SQL Server either way. So "with memory" is not the safer choice for AD or SQL, and it may be the riskier one. That was my mistake, and you acted on it.

On this morning's failure, the error is worth reading closely. VM_BAD_POWER_STATE(..., halted, suspended) means XAPI wanted the VM halted and found it suspended. That is the same mismatch you hit at the top of this thread with "Start a copy", except it is now breaking the delta job that ran fine for months before you added the CR.

Two things would help pin it down: does it fail the same way tonight, and does the delta job succeed if you disable the CR job for a single run? If it does, that is a clean reproduction and worth a GitHub issue with this screenshot.

@Team-XO-Backend, this one now has an XAPI error and a clear before and after, so it has moved past being a docs question.