GitHub user prashanthr2 added a comment to the discussion: Restoring volume snapshots from secondary storage in new CS cluster
@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-15288682 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
