DR worst case planning Part 2
-
First , I apologize for the long question.
Is there any reason that I couldn't use something like Clonezilla or Rescuezilla to make a image of my XCP-NG host drive (where the actual hypervisor is installed) ?
Maybe once or twice a year, during some scheduled downtime, I make an image of the XCP-NG system volume.
My thoughts being:
- I now have an exact replica of my XCP-NG host drive and can be easily moved / copied / taken off site.
- In theory...if I have a complete loss of my local hardware (my XCP-NG host and the local SR on that physical host...due to fire / natural disaster/ whatever) I should be able to restore this image on like (or similar) hardware.
- Once the image is restored, the XCP-NG host should automatically connect to my backup location (remote NFS in my case) assuming it has a path and can "see" the remote, but will not see any local SR (because they don't exist anymore ).
- So I simply create a new local SR.
- I could then install a new XO instance (on the newly created local SR), and restore the XO config (metadata) from my backup location.
- at this point via XO I should be able to see all the backups and DR backups (in my backup location) of the VM's that were stored on the local SR (the one that no longer exists).
- XO will not be able to "see" any of the VM's that previously existed on the old (vanished) SR.
*XO should be able to at least see and start the DR machines that are located in the backup location (yes?). - I could then copy / move / save the disaster recovery machines back to the local SR at my own pace.
and now the questions (before I test this in a lab):
Does this make sense ?
Do you see any obvious issues where this falls apart?
Would I be able to "restore" VM's ? Or would they not restore because of the SR UUID change, or because the original VM no longer exists ?The big benefit I see is that all the UUID's would remain the same just about everywhere (except the newly created SR??).
Most of the leg work would be done by XO, once the metadata config is restored.Thank you for any input or ideas.
-
Hi,
It's a lot easier to do a pool metadata backup, it will yield the exact same result for few KiB stored in a XO backup repository. You do usually combine regular and metadata backup (because you never know which of the host or the SR will die, or maybe both).
In any case, XO is able to restore anything from the BR (backup repo or "remote") even on a completely brand new hosts with a complete different hardware, it's fully self contained and agnostic.
-
"In any case, XO is able to restore anything from the BR (backup repo or "remote") even on a completely brand new hosts with a complete different hardware, it's fully self contained and agnostic."
--- Understood. Thank you!
I was under the assumption that there may be issues with the XCP-NG host / backups etc... when UUID's are changed ? (recovering a lost host ) Or even restoring the XO config may be
not quite as easy as maybe it should be.... restoring a downed hostI understand that the referenced post (above) is a few years old....and that maybe things have changed regarding the procedure.
In my mind .... having an image available (during a high stress situation) that is already setup and ready to go seems like a good idea.
But I also see the beauty of being able to restore the XCP-NG host and config back to a system that may be installed on completely different hardware. That is pretty awesome.
Maybe I'll try a dry run in a lab situation to see which one feels better.
Thank you again for your time and consideration.
-
Since 2020, we added pool metadata restore for exactly this
It should be really straightforward. The best way to validate it, is to use an experimental host, backup metadata, then reinstall a fresh XCP-ng from scratch on top of it, and then restore the metadata. That should work out of the box
