Backup to S3? Think Twice...

[savas]

S3 Isn’t a File System. Period.

Let’s start with the obvious: Amazon S3 is an object store, not a file system. It doesn’t work like your C:\ or your external drive or your NAS. That means no folders in the traditional sense (they're just prefixes), no true directory structure, and no standard file operations like move, rename, or append. You can't just open a file, write something to it, and save. In S3, to change a file you basically have to re-upload the whole thing. Even a tiny change requires pushing the entire file again. That might be fine if you're storing static files or logs, but backups are constantly changing, and dealing with this kind of object-level rigidity gets real old, real fast.

No Random Access = Big Headache

Need to restore just a chunk of a big file? Too bad. S3 doesn’t do random file access. It’s all or nothing. That’s fine for images, videos, and static assets. But imagine trying to restore a large PST, VHDX, or database backup. You can't just stream a portion or do a partial restore—you've got to download the whole 20+ GB monster. Now think about bandwidth costs, restore time, and how long your client or boss is going to be waiting on that restore to finish. Awkward silence. You're sipping stale coffee and watching a progress bar crawl like it’s on dial-up. With a proper file system, you can do partial reads or writes, resume broken transfers, and use traditional backup software without duct-taping workarounds together. Huge difference in flexibility.

Latency & Performance: Not Great for Daily Workflows

S3 isn’t designed for speed. It’s designed for durability, not performance. And you’ll definitely feel that if you’re using it for anything near real-time. On a regular file system or local NAS, reads and writes are basically instant. With S3, every read is a web request. There’s overhead—SSL handshakes, authentication tokens, DNS lookups, and more. If you’ve ever tried syncing a large number of files to S3, you know how slow and painful it can be. Upload 10,000 files and watch your hair turn grey. With a local file system, you’re looking at milliseconds. With S3? Seconds per transaction. Multiply that by thousands of files and you're in serious trouble.

No File Locking

S3 doesn’t support file locking. So, if you’ve got multiple users or processes writing to the same object, you’re begging for a conflict or corrupted data. File systems like NTFS handle locks like a boss—try opening a file someone else is using, and the OS stops you. With S3? Good luck. You’re on your own. Maybe it works. Maybe you just overwrote someone’s changes from 20 seconds ago. And for backups? That’s terrifying.

No Built-in Permissions Like NTFS

S3 has access control, sure—but it’s nothing like NTFS permissions. NTFS gives you fine-grained ACLs, inheritance, user and group settings, audit logs, the whole shebang. You can restrict access down to a specific file for a specific user in a specific OU. With S3? It’s IAM roles, bucket policies, ACLs—and it’s messy. Try explaining S3 permission hierarchies to your junior tech. Now compare that to right-click, Properties, Security tab. Which one do you trust more to keep things tight and secure?

No Real Versioning Unless You Manually Set It Up

Local file systems can be paired with software like BackupChain or even Windows’ Shadow Copy to create incremental versions of files automatically. Fast, smart, and efficient. S3 does support versioning, if you turn it on. And when you do, it retains every single version of every object. No intelligent pruning. No built-in aging policies unless you script them yourself. It's more like a pile of snapshots than a smart history. And all those versions? You're paying for them.

S3 Is Sneaky Expensive

On the surface, S3 looks cheap. A few cents per GB? Sweet. But every PUT, GET, LIST, DELETE, COPY operation costs you. Downloading a single file? That’s a GET. Listing a directory? That’s a LIST request—and it might cost you one request per object in a bucket. Backing up daily? That’s thousands of PUTs and GETs. You’ll start to see that line item on your AWS bill grow like a Chia Pet. With a traditional file system or even a local NAS? Zero per-operation fees. You pay for the hardware or storage tier, and that's it. Flat. Predictable. Budget-friendly.

Scripting and Automation Is a Pain

You want to run robocopy or xcopy or use PowerShell to move files around, check timestamps, run deduplication? Nope. Can’t do that natively with S3. It’s not a drive—it’s a web API. You’ll need to use the AWS CLI or SDKs, or some third-party tool like Rclone or DriveMaker Plus to simulate a file system. That’s more moving parts, more potential failure points, and more maintenance overhead. Contrast that with just using a mapped drive or mounting a share over SMB. Game over.

Reliability is not the same as Recoverability

Sure, S3 boasts 99.999999999% durability. But what happens when you delete something by accident? Or overwrite the wrong object? Unless you’ve manually set up versioning and lifecycle policies, it’s gone. There's no Recycle Bin. No Ctrl+Z. Just a quiet sob. Backups should be recoverable, not just durable. With a proper backup system using a real file system, you can set up redundancy, file-level versioning, or even undelete protection. You’re in control.

S3 Is Vendor Lock-In in a Tuxedo

Once you commit to S3, you’re locked into Amazon’s ecosystem. Sure, other cloud providers have S3-compatible APIs, but subtle differences can break your tooling. Try migrating terabytes of backups from S3 to Wasabi or Backblaze. It’s not fun. It’s not fast. And it’s definitely not free. With a standard file system, your data’s portable. Copy it. Clone it. Mount it somewhere else. Use whatever software you want. You’re not married to one vendor’s whims.

Troubleshooting Is a Nightmare

Ever tried to debug a failed S3 transfer? It’s like chasing a ghost through a fog. Logs are vague. Tools are inconsistent. And errors often just say “Access Denied” or “Internal Error.” Now compare that to a local file system: the OS logs it, your backup software logs it, you can reproduce it, and you're usually two Google searches away from a solution. With S3, you're scrolling through AWS forums, Stack Overflow, and wondering why you didn’t just use a drive letter.

Wrap-up: Should You Ever Use S3 for Backups?

Yeah, sometimes. If you’re archiving cold data, storing stuff you rarely touch, or pushing backups from servers located in different data centers, S3 can make sense. But as a primary backup target? Especially for stuff you might need to restore quickly, search, or access like a real file system? Nah. You’re better off with real storage—like NTFS volumes, local NAS, or cloud backup software that emulates a proper drive. Just because everyone’s doing cloud backups doesn’t mean S3 is the best way to do it. There’s a time and place for object storage—but daily backups, fast restores, and low maintenance? That’s still the file system’s turf, no contest. You want backups you can trust—and troubleshoot. Not some weird JSON blob buried in a bucket you can barely query. Keep it simple. Keep it accessible. Use a real drive.