# How to back up and restore a Quake AI VM

Source: https://docs.quake.ai/docs/compute/how-to/backup-and-restore
Markdown: https://docs.quake.ai/docs/compute/how-to/backup-and-restore.md

---

# How to back up and restore a Quake AI VM

Protect a VM with snapshots, copy backups off-project for disaster recovery, and run a restore drill that proves you can boot from the backup. Instance snapshots live in the same project as the source VM. Treat same-project snapshots as a quick rollback tool, not a full DR strategy by themselves.



A snapshot stored in the same project as the instance protects against accidental deletes inside that project, not against project-wide loss or regional incidents. Copy an image or export to [object storage](/docs/object/how-to/create-container) in another project or off-cloud for true recovery distance.



<PrerequisiteBlock methods={["console", "cli", "api", "terraform"]}>

- A running [instance](/docs/compute/how-to/create-instance) with a boot volume
- Optional: a second project or S3-compatible destination for offsite copies

</PrerequisiteBlock>

## Layer 1: Same-project snapshot

Follow [How to create an instance snapshot](/docs/compute/how-to/create-snapshot) before risky changes (package upgrades, configuration edits, migrations).

<MethodTabs>
<Method label="Console">

Use **Compute** > **Instances** > **Create Snapshot** on the instance row (wording may vary; see the snapshot how-to for the current Console path).

</Method>
<Method label="CLI">

```bash
openstack server image create --name myapp-backup-$(date +%Y%m%d) MY_INSTANCE
```

</Method>
<Method label="API">

Use the Compute API `POST /servers/{server_id}/action` with the `createImage` action. See [Instances API reference](/reference/compute/instances-api).

</Method>
<Method label="Terraform">

Manage snapshots with the `openstack_images_image_v2` data source after creation, or trigger snapshots through a null_resource provisioner that calls the CLI in CI.

</Method>
</MethodTabs>

## Layer 2: Copy to another project or export as a file

Quake AI instances boot from a Cinder volume. `openstack server image create` registers a thin Glance image that references the backing volume snapshot; the Glance entry reports `size: 0` and holds no downloadable bytes. See [Instance snapshots CLI reference](/reference/compute/snapshots-cli) for the full boot-from-volume behavior.



`openstack image save --file myapp-backup.qcow2 BACKUP_IMAGE_ID` against the Layer 1 snapshot image completes without error but writes a 0-byte file. The disk data lives in the Cinder volume snapshot, not in the Glance shim.



Pick the path that matches your recovery goal:

| Goal | Path |
| --- | --- |
| Launch from the backup in another Quake AI project | [Share the snapshot image](#share-the-snapshot-with-another-project) |
| Store a qcow2 file in object storage or off-cloud | [Export through a temporary volume](#export-a-qcow2-file-for-object-storage) |

### Share the snapshot with another project

1. Create the Layer 1 snapshot and note its Glance image ID or name.
2. Share the image with the destination project:

```bash
openstack image add project BACKUP_IMAGE_ID DESTINATION_PROJECT_ID
```

3. In the destination project, accept the member if your workflow requires it, then launch a drill instance from the shared snapshot image. See [Images service CLI reference](/reference/compute/images-cli#members).

The destination project boots from the shared snapshot image; Nova clones the backing volume snapshot into a new boot volume in that project.

### Export a qcow2 file for object storage

Work from the Cinder volume snapshot that holds the bytes:

1. Resolve the backing volume snapshot ID. Match the snapshot name from Layer 1 in `openstack volume snapshot list`, or read `block_device_mapping` from `openstack image show BACKUP_IMAGE_ID`.
2. Create a temporary volume from that snapshot (size must be at least the source boot volume):

```bash
openstack volume create \
  --snapshot VOLUME_SNAPSHOT_ID \
  --size BOOT_VOLUME_SIZE_GIB \
  export-src-vol
```

Wait until the volume status is `available`.

3. Upload the volume to Glance as a full image (not a thin snapshot shim):

```bash
openstack image create \
  --volume export-src-vol \
  --disk-format qcow2 \
  --container-format bare \
  myapp-export-$(date +%Y%m%d)
```

4. Wait until the export image is `active` and `size` is greater than zero:

```bash
openstack image show myapp-export-$(date +%Y%m%d) -c status -c size
```

5. Download the file:

```bash
openstack image save --file myapp-backup.qcow2 myapp-export-$(date +%Y%m%d)
```

6. Upload the file to object storage with the S3 CLI and your [S3 credentials](/docs/object/how-to/create-s3-credentials).

7. Delete the temporary export image and volume when the upload finishes:

```bash
openstack image delete myapp-export-$(date +%Y%m%d)
openstack volume delete export-src-vol
```

## Layer 3: Restore drill

Prove the backup works before you need it:

1. Launch a **new** instance from the snapshot or saved image ([create instance](/docs/compute/how-to/create-instance)).
2. Attach the same security groups and floating IP pattern as production (or test on a temporary floating IP).
3. Run application health checks (`systemctl status`, HTTP probe, database migration status).
4. Delete the drill instance when finished.

Document the drill cadence in your runbook (monthly or after major releases).

## See also

- [How to create an instance snapshot](/docs/compute/how-to/create-snapshot)
- [How to create an image](/docs/compute/how-to/create-image)
- [Instance snapshots CLI reference](/reference/compute/snapshots-cli)
- [How to schedule volume snapshots and restore data](/docs/block/how-to/schedule-snapshots-and-restore)
- [Automated backups with object storage](/docs/quickstart/automated-backups)