Swapping Block Storage for Object Storage (without breaking everything)

At some point you realise something: block storage feels simple because it behaves like a disk. Object storage does not. And trying to treat one like the other is where things start to get… interesting.

What you’re actually changing

This isn’t just a storage swap. You’re moving from “this looks like a normal filesystem” to “this is a bucket of objects accessed over an API.” That difference matters more than it sounds.

Block storage mounts and behaves like a disk, and works well with apps expecting normal filesystem behaviour. No surprises, Linux expectations mostly hold.

Object storage is an S3-compatible object store, great for large files, backups, and archives, but not designed to behave like a local filesystem. You can make it look like one. That doesn’t mean it behaves like one.

The mistake people make

They mount S3 and expect everything to just work. It doesn’t, especially not with workloads that rename files frequently, rely on file locking, create lots of small files, or expect low latency. If you point something like an *arr stack directly at S3 and hope for the best, you’ve basically signed up to debug edge cases for fun.

What actually works

Treat S3 as storage, not as a disk. That usually means local disk for your working set and S3 as archive and source of truth. So instead of “everything lives on S3”, you end up with “everything works locally, and S3 keeps a copy.”

Keep it simple: /srv/appdata and /srv/downloads stay local, /srv/media lives locally and syncs to S3. No pretending S3 is ext4, no weird behaviour.

Moving the data

Install rclone, configure your Linode Object Storage credentials, then copy the data across:

rclone copy /srv/media linode:YOUR_BUCKET/media --progress

If you want to sanity check it:

rclone check /srv/media linode:YOUR_BUCKET/media --one-way

This is the bit where you make sure you haven’t just moved half your data and called it a success.

Keeping things in sync

Instead of mounting S3, sync to it:

rclone sync /srv/media linode:YOUR_BUCKET/media

Run it on a schedule — hourly is usually fine. Apps behave normally, files exist locally, and S3 gets updated in the background. No surprises.

Rebuilds (the part you’ll care about later)

If your VM disappears, you want a way back. So you do the reverse:

rclone sync linode:YOUR_BUCKET/media /srv/media

Simple, predictable, no guessing.

The “can I just mount it?” question

Yes, you can mount S3 using rclone or s3fs. Should you? Only if it’s mostly read-only, you’re okay with latency, you’ve enabled caching, and you accept that file behaviour is “close enough” rather than identical. For anything write-heavy, it’s usually not worth it.

The actual swap

When you’re ready: make sure all data is in S3, stop anything writing to it, remove the block storage config, apply changes, and rely on local disk plus sync going forward. At that point you haven’t just moved storage, you’ve changed how your system behaves.

The common ways this goes wrong are treating S3 like a normal filesystem, syncing in the wrong direction, assuming metadata behaves the same way, putting secrets somewhere they shouldn’t be, and not testing restore. That last one tends to be discovered at the worst possible time.

Final thought

Object storage is great, it’s just not a drop-in replacement for a disk. If you treat it like one, you’ll spend your time chasing weird behaviour. If you treat it like what it is, it becomes very reliable, very predictable, and very useful.

The shift isn’t technical. It’s conceptual. Once you stop expecting it to behave like a filesystem, everything else gets easier.