I lost my work when I stopped a cloud GPU machine. How do I actually keep files between sessions?

This page may contain affiliate links from which Blur Studio earns commissions.

Losing hours of setup because a machine's storage disappeared when it stopped is one of the most common, and most avoidable, mistakes with rented GPU compute. The fix isn't complicated once you understand that Runpod, like most GPU rental services, offers several different kinds of storage with genuinely different lifespans, and the one you pick matters far more than people expect going in.

The four storage types, and what actually happens to each

Storage type	Survives a stop?	Survives Pod deletion?	Price
Container disk	No	No, clears entirely	$0.10/GB/month
Volume disk	Yes	No, deleted with the Pod	$0.10/GB/month running, $0.20/GB/month stopped
Network volume	Yes	Yes	$0.07/GB/month under 1TB, $0.05/GB/month over
Global volume	Yes	Yes	$0.09/GB/month plus IOPS charges

If you lost files when stopping a machine, the most likely explanation is that your work was sitting on container disk, which is explicitly temporary, meant for the operating system and session files, not for anything you need to keep. It clears the moment the Pod terminates, by design, not as a bug.

Which one you actually want

For work you want to survive a stop and restart of the same machine, volume disk is the right choice, and it costs the same $0.10 a GB a month whether the machine is running or stopped, though the stopped rate doubles to $0.20. It can also be encrypted at rest if you set that up when the Pod is created, worth knowing that Runpod's own documentation notes the encryption key can't be retrieved afterward and bring-your-own-key isn't supported, so don't lose track of your own access to the Pod itself.

For work you want to survive even deleting the Pod entirely, or that you want to share across multiple Pods, a network volume is the right call. The one real catch: a network volume must be attached when you first create the Pod, and Runpod's documentation states plainly that it cannot be detached later. Decide on this before you launch the machine, not after. Network volumes are not encrypted at rest, which matters if you're storing anything sensitive on one; see our guide on keeping business data safe on a rented GPU for how to think about that.

Global volume is a newer option built for read-heavy workloads like serving a model, priced slightly higher at $0.09 a GB plus IOPS charges, and also not encrypted at rest. It's the right fit specifically when multiple Pods need fast, simultaneous read access to the same large files, model weights being the most common case. A walkthrough is in stopping big model files from re-downloading.

Runpod says this isn't for long-term storage

Worth repeating plainly: Runpod's own guidance is that none of these storage types are meant to be your only copy of anything important long-term. Idle storage keeps billing every month whether you're using it or not, and storage services in general carry more operational risk than a dedicated backup solution built for that purpose. Back up anything genuinely important to Google Drive, S3 or a similar service separately, and treat Runpod's storage as working space for an active job, not an archive. The same billing risk applies to forgotten machines, see avoiding a surprise bill from a forgotten cloud machine.

Step by step: how to set this up right

1. Decide before you create the Pod whether you need storage to survive just a stop (volume disk) or a full deletion too (network or global volume), since the network volume decision specifically can't be changed later.
2. Attach the right storage type at creation time, not after.
3. Keep genuinely important files backed up elsewhere (Google Drive, S3 or similar), separate from whatever Runpod storage you're using for active work.
4. Test a stop and restart early, on a non-critical job, to confirm your setup actually behaves the way you expect before you rely on it for real work.
5. Delete storage you're not actively using. Idle storage bills monthly regardless of whether anything's touching it.

What I'd actually tell you

Most people who lose work this way didn't do anything wrong except not knowing container disk was temporary by design. Once you know the four types and what each one actually survives, this becomes a five-minute decision at setup time rather than a painful lesson after the fact. The one habit worth building regardless of which storage type you use: back up anything you'd be upset to lose, somewhere outside Runpod entirely, since even persistent storage here isn't meant to be your only copy.

A worked example: losing a day of fine-tuning setup

Say a small team spends several hours configuring a training environment, installing specific library versions, downloading a base model, setting up scripts, all on a Pod's default container disk because nobody specifically chose otherwise at setup time. The job runs overnight, finishes, and someone stops the Pod the next morning to save on billing while they review the results, only to come back a day later and find every bit of that setup gone, because container disk clears the moment a Pod stops in certain configurations and the team never moved their work onto volume disk. Rebuilding the environment costs another few hours, entirely avoidable if volume disk had been selected from the start for the small additional monthly cost of persisting it. The lesson isn't "GPU rental is unreliable," it's "pick the storage type before you start the work that depends on it," since the fix costs nothing once you know to make the choice deliberately.

A second example: sharing model weights across several Pods

A team running inference across multiple GPU instances at once, splitting a workload for speed, needs every instance to access the same large model weights without each one downloading its own separate copy, which wastes both time and storage cost. A network volume or global volume, attached to each Pod at creation, solves this by letting every instance read from one shared storage location rather than duplicating gigabytes of model files across machines. The choice between the two comes down to the access pattern: a global volume is built specifically for this kind of simultaneous, read-heavy access across multiple Pods, while a network volume works for shared storage too but is more commonly used for a single Pod's data that needs to outlive that Pod's deletion.

Common mistakes with GPU storage

• Not deciding on storage type until something's already lost. The decision costs nothing to make at setup time and a great deal of rework to learn about after the fact.
• Treating any Runpod storage as a permanent archive. Even persistent storage types here keep billing monthly and aren't built as a dedicated backup service. Important files belong on a real backup system too, not just persistent cloud storage.
• Forgetting that a network volume decision is final at Pod creation. Unlike most settings you can change later, this one locks in immediately, so get it right before launching, not after discovering you need it mid-project.

How I'd approach this

When I set up a Runpod workflow for a client, I pick the storage type deliberately based on what actually needs to survive, and I build in a real backup path from day one rather than relying on rented storage as the only copy of anything that matters. Get in touch if you want this set up correctly the first time instead of learning it the way most people do.