Google Colab Drive Mounting: Engineering Trade-offs and a Practical Pattern

Google Colab notebooks run on virtual machines that disappear after inactivity or a session timeout. Any data you write to the local /content folder is lost the moment the runtime recycles. If you've ever lost hours of training progress because the VM terminated mid-epoch, you're facing the same engineering decision every Colab user confronts: how to persist data without sacrificing speed.

Useful takeaway: mount Google Drive only when you need persistent storage, keep working datasets on the local SSD for fast I/O, and checkpoint model state or results to Drive periodically. This pattern balances convenience, performance, and security.

How Colab's filesystem works

Colab notebooks execute on ephemeral virtual machines. The local filesystem at /content is tied to the runtime's lifecycle. When the session ends—whether by inactivity, a timeout, or an explicit disconnect—the VM is terminated and its disk is wiped. This design protects the service from resource abuse, but it means any files you save, datasets you download, or model checkpoints you write disappear unless you explicitly move them elsewhere.

When to mount Google Drive

The supported way to add persistence is google.colab.drive.mount('/content/drive'). Running this cell opens an OAuth consent screen; after approval, your Google Drive appears under /content/drive/MyDrive. Because the mount uses FUSE (Filesystem in Userspace), read and write operations travel over the network rather than hitting local disk. That means latency is higher and throughput is lower than the native SSD. A common rule of thumb: use Drive for checkpoints, logs, and final artifacts; keep intermediate training data on the local /content SSD and copy only what you need back to Drive.

A practical pattern: local SSD + periodic Drive sync

Run these snippets in a Colab notebook cell. No special permissions are needed beyond your own Google account; the mount step triggers an authorization prompt. Start by mounting Drive if it isn't already mounted:

from google.colab import drive
drive.mount('/content/drive')  # follow the OAuth consent prompt

Copy your dataset from Drive to the local SSD once, where I/O will be fastest:

import shutil
shutil.copy2('/content/drive/MyDrive/dataset.zip', '/content/dataset.zip')

During your workflow, read and write to /content for speed. At regular intervals—or before you expect the runtime to disconnect—copy updated checkpoints back to Drive:

shutil.copy2('/content/checkpoint.pt', '/content/drive/MyDrive/checkpoints/')

If the VM recycles, reconnect the runtime, re-mount Drive, and copy the latest checkpoint back:

shutil.copy2('/content/drive/MyDrive/checkpoints/checkpoint.pt', '/content/')

This pattern means you only transfer data a few times per session, keeping the bulk of your I/O on the local SSD while retaining persistence for the artifacts that matter. Adjust the placeholder paths (dataset.zip, checkpoint.pt) to match your project.

Security, secrets, and collaboration

Mounting Drive grants the notebook broad access to your Google Drive; running an untrusted notebook while Drive is mounted can expose your files, so unmount or avoid mounting when executing code you don't trust. Colab also provides a Secrets feature (accessible via the key icon in the notebook UI, or programmatically through google.colab.userdata) that stores API keys outside your code and outside Drive. Prefer that over saving credentials to a Drive-mounted file. When sharing notebooks, remember that Drive mounting is per-user and per-session: collaborators will see a prompt to mount their own Drive, and path assumptions like MyDrive may not hold. Plan your code to accept a base path as a parameter so the same notebook works whether Drive is mounted or not.

Limitations and how to verify

FUSE-mounted Drive behaves poorly with many small files or heavy random I/O; it is not a substitute for a real database or object store. Session length limits and GPU availability also vary by Colab tier and change over time, so check the current limits in the product UI rather than assuming a fixed runtime duration.

Quick verification checklist:

1. Run the mount cell and confirm /content/drive/MyDrive appears in the file browser.
2. Write a test file with open('/content/drive/MyDrive/test.txt','w').write('hello'), disconnect the runtime, reconnect, re-mount, and verify the file persists.
3. Time a copy of the same dataset from Drive and from /content to observe the local-vs-mounted I/O difference.
4. Check the Colab UI for your current tier's runtime limits and session policies before planning long jobs.