Cloud GPU Data Persistence: Keep Data Across Restarts (2026 Guide)

Cloud GPU data persistence isn't one setting you flip once and forget. It's a different answer for every action you take and every volume provider sitting underneath your instance. Reboot a Spheron AI instance and nothing moves. Park (stop) it and the disk stays, but only on the two providers that support Park. Hot-attach a volume to a job that's already running and it mounts without touching existing data, except on one provider where the same action restarts the VM. Terminate the instance and the root disk is gone for good, while a persistent volume you created separately keeps living until you delete it yourself. Here's the lookup table for which action does which, and the exact dashboard steps for the part most guides skip: getting a volume onto a GPU instance that's already running.

TL;DR: Cloud GPU Data Persistence on Spheron, by Volume Provider

• Reboot: The instance's own disk and any attached persistent volume both survive unchanged, on every provider.
• Stop (Park): Only Spheron AI and Spheron ES support it. GPU billing stops and the disk stays as-is; Spheron's Park feature has the full mechanics.
• Hot-attach: Spheron AI, Spheron ES, and Verda support attaching a volume to a running instance; Spheron ES restarts the VM to do it, the other two don't.
• Terminate: The instance's own disk is deleted immediately. A persistent volume isn't; it keeps existing and billing until you delete it.
• Cost: Spheron's standard persistent volume rate was roughly $0.00016/GB/hr as of 12 May 2026, billed separately from compute (comparison below).

Ephemeral vs Persistent Storage: What Cloud GPU Data Persistence Actually Means

The two terms get used loosely, so it's worth pinning down what each one actually covers before the provider-by-provider table.

Ephemeral storage is the disk that ships bundled with the instance itself. It has no separate lifecycle: it lives and dies with that one instance, and what "dies" means depends entirely on the provider. AWS is the clearest version of this. Per AWS's own EC2 documentation, "the data on an instance store volume persists even if the instance is rebooted. However, the data does not persist if the instance is stopped, hibernated, or terminated. When the instance is stopped, hibernated, or terminated, every block of the instance store volume is cryptographically erased." AWS's own advice follows from that: copy anything you need off instance store to EBS, S3, or EFS before you stop the instance, since there's no way to configure instance store to outlive it.

Spheron's version of the instance's own disk is more forgiving than that, but only on two of its providers. On Spheron AI and Spheron ES, Stop parks the instance instead of destroying it: the disk and everything on it stay exactly where they were, and Starting it again returns the same disk and the same contents. That's a real middle state between "running" and "gone" that AWS instance store doesn't have. It still disappears on Terminate, though, same as anywhere else; Park only changes what Stop does.

Persistent storage, on the other hand, is a volume you create on purpose, independent of any instance. Spheron's volume-mounting docs describe the workflow directly: volumes are created from the Create Volume page. Once created, that volume has its own lifecycle. It doesn't care what happens to the instance it's attached to. Spheron's own docs put it plainly: you can "create persistent storage volumes that exist independently from your instances," then "attach a volume to a running instance, detach it without losing data, and reattach it to a different instance later."

The practical test for whether something counts as persistent: does the storage have a lifecycle of its own, separate from any single instance? If deleting the instance also deletes the data, that's ephemeral, however generous the provider is about reboots and stops along the way. If the data keeps existing (and keeps billing) after the instance is gone, that's persistent.

Step-by-Step: Attaching and Hot-Attaching a Volume on Spheron

Hot-attach is the part most feature write-ups mention in passing and never actually walk through. Here's the full flow, start to finish, for a volume provider that supports it.

1. Open Create Volume in the dashboard. Under the Volumes section, select Create Volume.
2. Choose a provider. Spheron AI, Spheron ES, Verda, or Sesterce. Spheron MS doesn't show up in this flow, since it only accepts a volume at deployment, not afterward.
3. Name the volume and set its size in GB. Stay inside that provider's ceiling, covered in the comparison table below.
4. Attach it to a running instance. Open the instance's details panel and choose Attach Volume, then pick the volume from step 3. On Spheron AI and Verda, hot-attach to a running instance is available with no interruption to the instance. On Spheron ES, the same attach action works but restarts the VM; data is preserved through that restart, so budget for a brief reboot rather than a zero-downtime mount.
5. Hot-detach it when the job is done. Detaching requires unmounting the volume from inside the instance first, then detaching from the dashboard. The volume's data is preserved after detachment and is immediately available to attach somewhere else, including a different instance entirely.
6. On Spheron MS, skip steps 4 and 5. Configure the single supported volume at deploy time instead; there's no later attach point on bare metal.

What Survives a Stop, a Park, and a Terminate, and What Doesn't

This is the table most GPU cloud explainers skip entirely, because they treat "storage" as one thing instead of two separate resources with two separate rulebooks.

The row worth rereading is Terminate. A terminated Spheron instance's own disk is gone immediately, no recovery path. A persistent volume attached to that same instance is a completely different resource: volumes persist independently of instances, and data is not lost when an instance terminates; volumes must be deleted explicitly. That's also the detail that costs people money if they don't know it. A volume doesn't clean itself up when the instance using it goes away. It sits there, billed, until someone deletes it.

Volume Providers Compared: Spheron AI, Spheron ES, Verda, Sesterce, Spheron MS

Spheron aggregates pricing and capacity from 5+ providers and sources from its certified data center network rather than operating as a single provider, and that extends to how storage works: there's no one set of volume rules across the marketplace, there are five.

A few things worth calling out in that table beyond the raw numbers. Spheron ES's multi-instance attach is a genuinely different capability from the single-attach model Spheron AI uses: an ES volume can serve more than one instance at a time, which matters for workloads where several nodes need read access to the same dataset. Verda works the same way for multi-attach, letting a shared volume feed multiple compute nodes without copying data between them, a pattern covered in more depth in Spheron's roundup of Verda alternatives for teams weighing Verda specifically against other European options.

Spheron MS sits at the opposite end. One volume, 16 TB ceiling, deploy-time only, and (as covered above) no Stop or Park at all on top of that: an instance you're finished with on Spheron MS should be terminated rather than parked, since parking isn't an option there. If your workload needs flexible, hot-attachable storage and you're currently planning around bare metal, Spheron AI or Spheron ES is worth checking first; Spheron MS is the right call when you specifically need bare metal and your storage needs are fixed and modest.

Spheron's standard persistent volume rate was roughly $0.00016/GB/hr as of 12 May 2026, billed separately from GPU compute, and active team discounts apply automatically at creation or resize with no coupon or ticket needed. For comparison, Runpod's pricing docs list $0.10/GB/month for its persistent volume disk while a pod is running, and $0.20/GB/month, double the running rate, once the pod is stopped, as published in October 2026. That inversion is the opposite of what most people assume "stopped" means for storage, and it's a good reason to read a provider's parked-rate math line by line before relying on it.

Pricing fluctuates based on GPU availability. Spheron rates above are live as of 14 Oct 2026; other providers reflect their most recent published rates and may have changed. Check current GPU pricing → for live rates.

One operational fix worth knowing about if you've hit it before: volumes attached to a crashed, stopped, failed, or deleted instance used to stay locked indefinitely, with no way to reclaim them short of a support ticket. Spheron's April 2026 release fixed that by skipping terminated, failed, stopped, and deleted deployments when checking whether a volume is actually in use, so a volume orphaned by a crashed instance is immediately available to attach elsewhere.

Checkpointing and Model-Weight Patterns That Depend on This

Everything above matters most for exactly two kinds of data: checkpoints you can't afford to lose, and datasets too large to re-download every time you spin up a new instance.

For checkpoints, the safe pattern is to write them to a persistent volume, not the instance's own disk, even on a provider where Stop preserves that disk. The reasoning is simple: Stop only protects you from Stop. It does nothing if someone (or an empty account balance) terminates the instance instead, and running out of account credit destroys every instance regardless of state, stopped ones included. A checkpoint written to a persistent volume survives all of that, because the volume's lifecycle was never tied to the instance in the first place.

The setup that holds up in practice is boring on purpose: mount the persistent volume at its own path (/mnt/checkpoints, not the instance's root disk), point the training framework's checkpoint callback at that mount instead of its default /workspace or /root location, and save on a fixed step interval rather than relying on a graceful shutdown to flush the last one. A $3.96/hr H100 instance set up this way can be terminated outright, swapped for a different GPU type, or recovered after a spot preemption, and the only checkpoint that's missing is whatever ran between the last save interval and the interruption, never the whole run. Skip the separate mount and write checkpoints straight to the root disk instead, and that same interruption takes the checkpoint with it.

For datasets, the calculation is about redeploy cost rather than data loss. Re-downloading a multi-terabyte pretraining corpus every time you provision a fresh instance is slow and, on a metered connection, not free either. Storing the curated dataset on its own persistent volume once, then hot-attaching it to whichever instance needs it that week, turns a redownload into a mount. This is the exact use case Spheron's guide to pretraining data curation with NeMo Curator, Datatrove, and FineWeb-style pipelines runs into: the curated output of those pipelines is large, expensive to regenerate, and reused across many training runs, which is precisely the profile that belongs on a persistent volume instead of an instance's own disk.

Common Mistakes With Persistent Volumes on GPU Cloud

A handful of mistakes come up often enough with persistent storage to call out directly.

• Writing checkpoints to the instance's own disk and assuming Stop protects them. It does, right up until someone terminates the instance instead, which deletes that disk immediately with no recovery path. A persistent volume doesn't have this failure mode.
• Forgetting Spheron MS can't hot-attach. If a workload might need more storage later, plan the volume at deployment time on MS, since there's no way to add one afterward without redeploying.
• Leaving unused volumes around after the instance that used them is gone. Volumes don't self-delete when an instance terminates; they keep existing, and keep billing, until someone deletes them explicitly. A quick pass through the dashboard's Volumes list after wrapping up a project is the fix.
• Assuming a hot-attach is always zero-downtime. It is on Spheron AI and Verda. It isn't on Spheron ES, where the same attach or detach action restarts the VM. Budget for that reboot if the workload is latency-sensitive.
• Treating "persistent" as a guarantee against running out of funds. An empty account balance destroys instances regardless of their stopped or running state. It's a separate failure mode from anything covered in the table above, and the fix is a balance alert, not a storage choice.

Cloud GPU data persistence, in the end, comes down to knowing which of two resources you're actually relying on for any given piece of data: the instance's own disk, whose fate depends on the action and the provider, or a volume you created on purpose, whose fate depends only on whether you deleted it. Get that distinction right once and the rest of the table above is just reference material.

Picking the wrong storage layer for a checkpoint or a training dataset is an expensive mistake to find out about after a terminate. Spheron's persistent volumes exist independently from any one instance, with hot-attach on Spheron AI, Spheron ES, and Verda, so your data outlives the instance that first used it.

Get started on Spheron →