Persisting Notebook Data in Google Colab with Google Drive
Colab runtimes wipe /content when they disconnect. Learn when to mount Google Drive for checkpoints and when to copy data back to local VM storage.
22 Jan 2026, 08:32 UTC

Your training checkpoint vanished after a coffee break
You start a training run in Google Colab, save a checkpoint to /content/checkpoints/epoch_3.pt, and close the tab. When you reconnect hours later, the file is gone. Colab provides a temporary Linux virtual machine (VM) for each notebook session. Files written to /content live only on that VM’s temporary disk. When the runtime disconnects—after inactivity, a maximum time limit, or a manual reset—the disk is recycled and everything on it disappears.
The practical takeaway: treat /content as scratch space, not durable storage. For anything you need later, write it to Google Drive or another external location before the session ends.
What survives a runtime disconnect
Not everything in Colab is temporary. The notebook file itself lives in Google Drive if you saved it there, and your Google account persists. But the runtime environment does not:
- Files under
/content: lost on disconnect. - Packages installed with
pip install: must be reinstalled in a new runtime. - Environment variables and mounted drives: not preserved across sessions.
Google Colab provides the google.colab.drive module to mount your Google Drive at /content/drive. This is a network mount: the files stay on Drive, and Colab accesses them over the network during the session. It works well for reading datasets and saving model checkpoints, but it is not the same as local disk.
Worked example: save a checkpoint to Drive
Run this in a Colab code cell. You need a Google account and permission to authorize Colab to access your Drive.
from google.colab import drive
drive.mount('/content/drive')
After running the cell, Colab displays an authorization link. Click it, sign in with the Google account that owns the Drive, copy the verification code back into the Colab prompt, and press Enter. Once authorized, Drive appears under /content/drive/MyDrive.
Create a project folder and save a file there:
import os
checkpoint_dir = "/content/drive/MyDrive/colab_projects/my_model/checkpoints"
os.makedirs(checkpoint_dir, exist_ok=True)
checkpoint_path = os.path.join(checkpoint_dir, "epoch_5.pt")
# Example placeholder: replace with your actual model save logic
# torch.save(model.state_dict(), checkpoint_path)
# Create a small marker file so we can verify persistence
with open(checkpoint_path, "w") as f:
f.write("placeholder checkpoint")
print("Wrote:", checkpoint_path)
Expected check: after the cell runs, ls -lh /content/drive/MyDrive/colab_projects/my_model/checkpoints/ should list epoch_5.pt. Because the file is on Drive, it should still be there after you disconnect and reconnect the runtime.
Risk: Do not share a notebook that contains an OAuth authorization code or refresh token. The mount authorization is tied to your Google account.
When Drive is the wrong place for active data
Drive mounting solves persistence, but it introduces latency. Reading many small files randomly from /content/drive is slower than reading from /content because each request travels over the network to Google Drive.
| Location | Best for | Survives disconnect? |
|---|---|---|
/content (VM disk) | Active training data, working copies, scratch files | No |
/content/drive/MyDrive (mounted Drive) | Datasets, checkpoints, outputs, notebooks | Yes |
A practical pattern: copy a dataset from Drive to /content at the start of training, then write checkpoints back to Drive as they finish. This keeps fast local access during training while preserving results after the runtime ends.
Verify before you disconnect
Open Runtime > Disconnect and delete runtime, then reconnect. Run:
!test -f "/content/drive/MyDrive/colab_projects/my_model/checkpoints/epoch_5.pt" && echo "persisted" || echo "missing"
If you see persisted, the file survived on Drive. If you see missing, check the mount path and OAuth authorization.
Also confirm your hardware accelerator before starting a long job: Runtime > Change runtime type shows whether a GPU or TPU is available for your account. Exact idle and maximum session limits vary by Colab tier and demand, so do not assume a specific timeout.
Closing
Colab is convenient for interactive compute, but its runtime storage is intentionally temporary. Mount Google Drive when you need files to outlive the session, copy working data to /content when you need speed, and always verify a checkpoint exists outside /content before you close the tab.
0 replies
A thoughtful contribution can make all the difference. Be the first to share one.