Volumes in DevOps: Learning the Hard Way
How I learned to stop losing data and started using persistent storage
When you’re new to DevOps, you make mistakes. I made several. The biggest one? Running an application with all its data stored directly on the instance, assuming it would always be there.
The Problem: Data Loss
I spun up an instance, cloned my hobby project from GitHub, built the application, and opened it to the internet. Everything worked fine. But I didn’t understand one critical thing: where was my data living?
All the data my application created was being stored directly on that instance. If the cloud provider terminated my instance—due to a missed bill, maintenance, or any unexpected situation—every bit of that data would be gone.
I learned this the hard way. I had collected about ten journal entries for my trading system when I missed a bill payment. The instance was purged. All that data vanished.
Ten entries is painful to lose. But I realized: what if I had three years of data? What if there were 500 to 1000 entries I’d collected over years of trading? That wouldn’t be recoverable. I needed a better approach.
The Solution: Volumes
I asked Claude what to do, and the answer was clear: volumes.
A volume is a dedicated storage unit—think of it like an external hard drive or USB drive attached to your instance. You can attach volumes to instances, and whatever your application writes to that volume persists independently of the instance itself. If your instance gets terminated, your volume stays safe. Your data stays with the volume, not with the machine.
The concept made sense. I provisioned a new instance, bought a volume, and attached it. Problem solved, right? Not exactly.
The Trap: Volumes Aren’t Automatic
Here’s where I made my second mistake. I created the volume and attached it to the instance, but I never actually configured my application to use it.
Every instance comes with a default amount of storage. When you attach a volume, it’s technically connected to the instance, but your application doesn’t know about it. Your data was still being written to the default instance storage, not the volume. I had attached the volume but wasn’t using it.
Think of it like this: you buy an external hard drive and plug it into your computer, but you never change where your applications save files. Your files still end up on the computer’s internal drive. The external drive just sits there.
The solution required two steps.
Option 1: Manual File Transfer
I could manually copy files from the instance to the volume. Volumes appear as mounted directories on your instance—they’re just file paths you can write to. A simple copy operation moves your data from instance storage to volume storage.
Option 2: Configure Docker (Better)
Since I was running my application in Docker, I had a better option. Docker can be configured to store all its data directly to a volume. You mount the volume inside your Docker compose file, point Docker to a specific directory on that volume, and from that moment on, everything Docker creates goes straight to persistent storage.
This required a few steps:
- Find the location of the mounted volume on my instance
- Create a folder inside the volume for Docker data
- Update my Docker compose file to mount that folder
- Shut down the services, make the configuration changes, then restart
After restarting, everything worked smoothly. But I still had old data on the instance’s default storage. One more step: copy that old data to the volume. Once it was moved, I restarted the applications and they synced with the historical data.
Why This Matters
Volumes solved my problem. Now, if my instance terminates for any reason, my data is safe. It’s stored independently on a persistent volume. I can spin up a new instance, attach the same volume, and my data is still there.
The key lesson: just because something is attached doesn’t mean it’s being used. With volumes, you have to actively configure your application to write to them. It’s an extra step, but it’s a necessary one.
If you’re running applications in the cloud, use volumes. It’s that simple. Whatever data matters to you—trade logs, user information, configurations—don’t let it live and die with a single instance. Give it its own storage.