> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.ibee.co.in/docs/tools/snapshots/restore-a-snapshot/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.ibee.co.in/_mcp/server. # Restore a snapshot > Roll back a Cloud VM, create a new VM, or restore a single disk from a snapshot recovery point. Each snapshot creates a **Recovery Point** in the VM's **Snapshots** tab. From there you can roll back the existing VM, spin up a new VM from the recovery point, or restore one captured disk in place. The flow is identical for [automated backups](/docs/tools/backups/restore-from-backup) — both produce snapshot recovery points and use the same restore modes. > **Warning** > > **Restoring a snapshot stops the server briefly.** The platform rolls back the disk and starts the VM again automatically. Connections in flight will be interrupted. ## Open the recovery point 1. On the server detail page, open the **Snapshots** tab. 2. Scroll to **Recovery Points**. 3. Click **Details** to inspect captured disks and mount instructions. 4. Click **Restore** to start the recovery flow. ## Recovery Point Details The Details drawer summarizes: * **Captured disks** — count and total recovery storage (for example `2 captured disks · 60 GB`). * Each disk's label, UUID, target device (`vda`, `vdc`, …), filesystem, size, and capture state. * `mounted` — disk was live-mounted at capture time (typical for the root volume). * `instructions_pending` — data volume captured but unmounted at the guest level; mount it manually after restore. * **Mount Instructions** for each captured data volume. Mount instructions are the standard four-step sequence: ```bash # 1. Format (first time only — skip if the volume already has a filesystem) sudo mkfs.ext4 /dev/vdc # 2. Create mount point sudo mkdir -p /mnt/volume_ # 3. Mount sudo mount /dev/vdc /mnt/volume_ # 4. Persistence — use UUID echo "UUID=$(blkid -s UUID -o value /dev/vdc) /mnt/volume_ ext4 defaults 0 0" | sudo tee -a /etc/fstab ``` The drawer's **View instructions** / **Hide instructions** toggle expands the exact commands for the selected volume. ## Restore modes When you click **Restore**, a side panel appears with the snapshot summary (Recovery Point ID, captured disks, topology, VM disk size, protected size) and three modes. ### Replace Current VM Roll back the current VM's root disk and all captured data disks in place. The VM is briefly stopped, disks are replaced, and it restarts automatically. Use when the existing VM is the right target and you want a clean rollback (e.g. after a bad deploy). > **Restore Impact:** The current VM will be stopped, its root disk will be replaced, and captured data disks will be attached again. ### Create New VM Provision a brand-new VM from the recovery point. The platform suggests a name based on the recovery point timestamp (for example `test-62709Z`) — edit it before confirming. New live block volumes are created from each captured disk and auto-attached to the new VM. > **Restore Impact:** A new VM and new live block volumes will be created from this recovery point and billed as active resources. The **Restore Preview** lists each disk that will appear on the new VM with its target device and original mount path: ``` vmroot-test-clone · vda · / testblockstorage · vdc · /mnt/volume_ ``` Use this for non-destructive recovery, migration testing, or cloning a known-good build. ### Restore Selected Disk Roll back a single captured disk in place on the current VM. Useful when only one volume is corrupted and you don't want to disturb the rest. Pick the disk to restore from the **Captured Disk** dropdown. The preview confirms the change, e.g. `This will roll back vmroot-test-clone (vda) in place.` > **Restore Impact:** The selected disk will be rolled back in place. The VM may be briefly stopped and started again automatically. ## Confirm and run Click **Confirm Restore** at the bottom of the side panel. The platform runs the restore and emits activity events you can follow in the [Activity feed](/docs/infrastructure/cloud-vms/monitoring#activity-feed): * `VM snapshot_restore operation accepted` * `VM snapshot_restore operation started` * `VM snapshot_restore operation succeeded` ## After restore | Mode | Resulting state | | --------------------- | ---------------------------------------------------------------------------------------- | | Replace Current VM | VM resumes on the same IP and hostname with rolled-back disks. | | Create New VM | New VM appears in the list with a fresh IP. Update DNS / callers when ready to cut over. | | Restore Selected Disk | VM resumes with the selected disk rolled back; other disks untouched. | For both Replace and Create New VM, captured **data volumes** are auto-attached but **not auto-mounted** inside the guest. Run the mount instructions from the Recovery Point Details drawer. ## Troubleshooting **Restore is queued but doesn't start** Check the Activity feed for an in-flight operation that's blocking it. Wait for it, or cancel and retry. **New VM has no IP after Create New VM** Wait a minute; provisioning takes longer than a regular deploy because disks are being copied. If the IP stays blank, look for a failed `VM create` event. **Data volume isn't visible after restore** The volume is attached but unmounted. Run the mount commands from **Recovery Point Details → View instructions**. **Wrong disk restored** Take a snapshot of the current state first, then redo the restore against the correct disk. Avoid restore-followed-by-restore on the same disk without a snapshot in between. ## Related pages * [VM snapshots overview](/docs/tools/snapshots) * [Create a snapshot](/docs/tools/snapshots/create-a-snapshot) * [Restore from backup](/docs/tools/backups/restore-from-backup) * [Attach volumes](/docs/infrastructure/cloud-vms/attach-volumes) > Roll back a Cloud VM, create a new VM, or restore a single disk from a snapshot recovery point.