# Ephemeral and persistent disks on GPU VMs: a deletion checklist

Understand GPU VM disk lifecycles before stopping or deleting an instance: ephemeral storage, persistent volumes, backups and a restore test.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/cloud-gpu-ephemeral-vs-persistent-checklist/
Language: en

An ephemeral disk is intended for temporary data, while a persistent resource has its own retention rules. The word persistent does not guarantee survival through every deletion operation. Before ending a GPU VM, identify the storage device, its relationship to the instance and the relevant deletion settings, then test restoration with a control file.

## Document the actual lifecycle

AWS instance store and EBS demonstrate different mechanisms. Instance store is temporary block storage associated with instance resources. For EBS, an attachment's deletion attribute influences what happens at termination. The useful question is therefore not simply whether a disk exists, but what happens to that particular resource under each planned action.

Record whether data survives an application restart, VM reboot, stop and instance deletion. Keep this inventory outside the VM. Otherwise the information needed to recover a resource may disappear together with the environment that contained your notes.

## Map directories to cloud resources

A Linux path describes a filesystem location, not the service's retention contract. A directory named `/data` could live on temporary storage, a separate volume or the boot device. Container platforms may likewise attach different kinds of storage at a familiar workspace path.

Match each important path to a device and resource ID in the control panel. Distinguish public model caches, temporary logs, unique annotations and final outputs. A cache can often be downloaded again, but its recovery still takes time. Irreplaceable work needs an independent copy with a verified reading procedure.

## Run a small restoration exercise

Create a small file containing a random value and save its checksum elsewhere. On a disposable test resource, perform the documented operation your project expects to use. Check the file afterwards and confirm that another environment can read or restore it where required.

| Action | What the test should establish |
| --- | --- |
| Application restart | Data was written to storage rather than kept only in memory |
| VM reboot | The correct resource mounts again |
| Stop | Retention follows the selected disk's rules |
| Instance deletion | A required independent resource remains accessible |
| Replacement instance | The documented restore or attachment route works |

These are questions for each product, not universal answers across providers. Never perform the first destructive lifecycle experiment on the only copy of useful results.

## Assign ownership beyond the VM

A retained volume does not automatically provide a complete backup process. Confirm access after a team member leaves, responsibility for ongoing charges and a review date for archived data. Repeat a small restoration test after changes to images, mount paths or permissions.

The final record should include the disk ID, path, operation, restore destination and date of successful reading. That supports a practical discussion about preserving data when the compute environment changes.

Official references: [docs.aws.amazon.com — InstanceStorage](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html), [docs.aws.amazon.com — preserving volumes on termination](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/preserving-volumes-on-termination.html).

Related guides: [Runpod storage types: container disk, volume disk and network volume](/journal/runpod-container-volume-network-disk/), [GPU EC2 terminated: check the EBS volumes left behind](/journal/aws-gpu-ebs-after-termination/).