GitHub user Jayd603 added a comment to the discussion: Restoring volume snapshots from secondary storage in new CS cluster
This sounds like the best option. I'll try it out. Thanks! > @Jayd603 Since you’re restoring backups into a totally separate CloudStack > environment, it’s going to be tough to get them to show up without some > database changes. However, I was thinking you might be able to bypass the DB > issues entirely by using the KVM QCOW2 import feature. > > The trick is to register your backup target (the NAS) as Primary Storage > instead of Secondary. If you do that, you can use the 'Import QCOW2 image > from Shared Storage' option under Tools > Import-Export Instances. > > I am referring to this feature > https://docs.cloudstack.apache.org/en/4.22.0.0/adminguide/virtual_machines/importing_unmanaging_vms.html#import-instances-from-shared-storage.. > you can do this from GUI as well ( From Tools --> Import-Export Instances > --> Select KVM --> Select "Import QCOW2 image from Shared Storage" under > Action) > > It’s a bit of a 'hack' because that tool is technically for migrating > external KVM VMs, but I think it can work for your use case. It lets you pick > the raw .qcow2 files directly from the storage and spin them up as managed > instances in your new setup without worrying about the old metadata. The only > catch is that you’ll need a way to map the files back to the right machines. > Since the files are named with UUIDs, you'll need to reference your old > database (or a file list) to figure out which .qcow2 belongs to which VM > before you start the import GitHub link: https://github.com/apache/cloudstack/discussions/12254#discussioncomment-15298158 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
