Object storage backup plan for teams with lots of files

Why files need their own backup plan

A database backup does not protect the whole product.

In many apps, the database stores names, IDs, and file paths, while the actual customer content lives in object storage buckets. That includes product images, user uploads, invoices, exports, contracts, and media files. If the bucket is wiped or files are overwritten, the rows in the database can still look fine while the product breaks for users.

A simple way to think about it:

• The database says what should exist.
• The bucket holds what users actually open or download.
• If those drift apart, the app looks broken even when the database is healthy.

Teams get caught by this all the time because file loss happens fast. One cleanup job with the wrong prefix can delete thousands of objects in seconds. A bad deploy can change bucket names, overwrite paths, break permissions, or point the app at an empty location.

File problems also hide well. Logins still work. Dashboards still load. Then a customer tries to open a document, download an invoice, or fetch a report and gets an error. By that point, new writes may already have changed the state you hoped to restore.

Files need their own backup rules. You need protection from operator mistakes, deploy mistakes, and quiet damage that spreads over hours or days.

For a small SaaS product, losing files often hurts more than losing metadata. A missing avatar is annoying. Missing receipts, signed PDFs, or customer uploads can stop support, billing, or onboarding the same day. If your product stores lots of files, treat buckets as production data, not disposable storage.

A sensible plan starts with three basics: keep older versions, make destructive actions harder, and practice restore before anything goes wrong. Skip those, and one bad command can turn a normal release day into a long week.

What to protect first

Start with an inventory, not a setting. Otherwise, teams protect throwaway files and miss the bucket that actually matters.

Most products have three broad groups of files: user uploads, generated files, and internal assets. User uploads usually need the strongest protection because you often cannot recreate them. If a customer uploads a signed contract or 5,000 product photos, those files are gone unless you have them somewhere else. Generated files such as thumbnails, exports, or resized media usually matter less because you can rebuild them from source data, even if that takes time. Internal assets sit in the middle. Some are easy to recreate. Others exist in one old folder on one laptop, which makes them more fragile than teams expect.

Separate critical buckets from temporary ones early. A bucket for customer documents should not share the same retention and delete rules as a bucket for thumbnails or import scratch files. When everything sits under one set of rules, cleanup gets risky and restore work gets slower.

For each bucket, write down two labels in plain language: "can rebuild" or "cannot rebuild." Be strict. If rebuilding depends on a missing script, an old third-party service, or manual work from three people, treat that data as "cannot rebuild." That one label shapes your versioning, retention, and recovery steps.

You also need a simple ownership map. Note who can write, overwrite, and delete files in each bucket. Include the app, background workers, admin panels, CI jobs, and support scripts. Many bad deploys do not destroy data because storage failed. They destroy data because one job had delete access it never needed.

A small spreadsheet is enough: one row per bucket, one owner, one risk level, and one short recovery note. For most teams, that takes less than an hour and gives a clear order for what to lock down first.

Set rules before you change settings

Storage settings help only when the team agrees on what it is trying to recover and who may touch production buckets.

Write recovery goals in plain language. Skip technical jargon and describe the business effect. "If product images disappear, customers must see them again within 2 hours" is clear. "We can lose no more than 15 minutes of new uploads" is clear too. Support, engineering, and product can all work from that.

Old versions also need a time limit. Keep them too briefly and a bad deploy can erase your safety net before anyone notices. Keep them forever and storage bills grow while old data becomes harder to manage. Different buckets usually need different rules. Product images might need 30 to 90 days. Temporary exports often need much less.

Deletion rights should be narrow. Most people who upload or replace files do not need permission to delete buckets, purge old versions, or edit lifecycle rules. Give that access to a very small group and make sure they use separate admin accounts for risky work. Shared credentials cause more damage than teams expect.

Bulk changes need named approval. That includes sync scripts, cleanup jobs, lifecycle edits, bucket policy changes, and migrations. A simple process works well: one person prepares the change and writes the scope, another checks the bucket, prefix, and delete behavior, and the team records who approved it and when. For large deletes, confirm the restore path before anyone runs the job.

This does not need a thick policy document. One short page is enough if a new engineer can read it in three minutes and understand who may delete, how long versions stay, and who must approve a cleanup job.

Use versioning without making a mess

Bucket versioning is usually the first setting to turn on. It gives you a second chance when someone overwrites a file, deletes a folder, or a deploy pushes the wrong assets. Without versioning, one bad sync can replace thousands of files and leave nothing to roll back to.

Turn it on before the next release, not after the first mistake. Then test it on one sample file. Upload version one, overwrite it with version two, delete it, and restore the older copy. If your team cannot do that in a few minutes, versioning is not helping yet. It is just extra storage.

A small drill is enough:

• Upload a file with a visible change.
• Replace it and confirm the bucket kept both versions.
• Delete the current file and verify the older version still exists.
• Restore the older version and open it in the app, not just in the storage console.

Keep older versions longer than you first expect. Some mistakes show up fast, but others sit quietly for days. A broken image path, a bad deploy script, or a bulk update can touch files long before anyone notices. Thirty days is a sensible starting point for many teams. If your release cycle moves slowly, keep them longer.

Versioning can also get messy if nobody manages it. Old copies pile up, especially for large media files and files that change often. Set expiry rules for noncurrent versions and check storage growth every month. Watch total bucket size, older-version size, and object count if your provider shows them. If storage jumps after every deploy, fix the deploy process instead of paying to keep endless leftovers.

You do not need every old file forever. You need a clear recovery window and a restore process people have already tried.

Add deletion controls that stop easy mistakes

Most file loss starts with a normal account doing the wrong thing at the wrong time. One script points at the wrong bucket. One deploy job runs a cleanup step too broadly. Thousands of files disappear in minutes.

Versioning helps, but it does not save you if someone can also remove old versions or change retention rules without any friction.

Who can delete what

Start with roles. Most people and most apps do not need permanent delete rights in production. Product teams usually need to upload, replace, and read files. Hard delete rights should stay with a very small group, using separate accounts made for that work.

That split matters. A deploy account should publish new assets and leave old ones alone. A cleanup account can remove files, but only after a deliberate check. If the deploy pipeline breaks, it should fail to delete rather than succeed too broadly.

Lifecycle changes need the same care. A bad lifecycle rule can erase old versions as quickly as a person can. Treat changes to retention, expiration, and version cleanup like production changes that need review by another person.

A simple setup prevents many common mistakes:

• Block permanent delete for day-to-day users and deploy jobs.
• Limit lifecycle edits to a small admin group.
• Deny mass-delete tools on production buckets unless a break-glass process approves them.
• Use separate credentials for deploy tasks and cleanup tasks.
• Log delete actions and review unusual spikes.

One small example shows why this matters. A team ships a frontend update with a bad path in its asset sync job. The deploy account can upload the new files, but it cannot wipe the whole bucket. The job fails, the team fixes the path, and customer images stay online.

Oleg Sotnikov often pushes teams toward this kind of separation in production systems because it cuts off the most common failure mode: human error with broad permissions. It is boring, and that is exactly why it works.

Run a restore drill step by step

A backup plan is only real if someone can restore files under pressure. The best test is small and plain.

Start with one folder your product uses every day and one file added recently. If your app stores product images, pick a folder for one category and a fresh image inside it. Recent files are better than old samples because they show what the app writes now, not what it wrote six months ago.

Use this order for the drill:

• Restore into a separate bucket or a clearly named test path first.
• Compare the restored file with the current one, including filename, size, content type, cache headers, tags, and timestamps.
• Check access rules and permissions the same way the app does.
• Measure the full restore time, from the first action to the final check.
• Write down the exact steps, commands, screens, and approvals the team used.

Keep the first restore away from production. Teams get into trouble when they rush the last step and overwrite good files with incomplete copies. A test location gives you room to inspect everything before you touch live data.

After the single file works, try the whole folder. Folder restores fail in messier ways. Files may come back under the wrong path, metadata may be missing, or only the originals return while resized copies stay gone.

Timing matters more than many teams expect. A restore that takes 20 minutes may be fine for internal documents, but painful for a store that loses product images during a deploy. Write down the time, the blockers, and who had enough access to perform the restore.

Keep the notes short and exact. Then ask one teammate who did not set up the bucket to follow them. If that person gets stuck, the drill did its job. You found the weak spot before a real incident did.

A simple example: a deploy wipes product images

A common failure starts with a small config mistake. A new release goes live, and the app writes image requests to the wrong bucket path. Nothing crashes. The site still loads. Product pages even look normal in a few cached views, so the deploy passes a quick check.

Then the cleanup job runs.

It scans the old path, decides those files are no longer used, and deletes them. A few minutes later, customers open product pages and see broken images. The first alarm often comes from support, not engineering, because support sees the tickets before anyone checks logs or dashboards.

This is why file protection cannot ride along with database backups. The database may still have every product record, image URL, and metadata field. None of that helps if the files behind those URLs are gone.

A team without version history usually loses time in the same pattern. They check the app. Then the CDN. Then the database. Only after that do they notice the deploy changed the bucket prefix and the cleanup task removed the old files.

If versioning is on, recovery is much shorter. The team can stop the cleanup job, find the deleted prefix or object set, restore the previous versions, and test a few pages before reopening traffic. That still takes work, but it is a repair job, not a disaster.

The drill matters as much as the setting. A team that has practiced this once already knows who pauses automation, who restores objects, and who checks frontend pages after the restore. That can cut a messy two-hour incident down to 15 or 20 minutes.

Deletion controls help too. If the cleanup job can only mark files for review, or if permanent deletes need a separate step, one bad deploy does far less damage.

This example is simple, but it is common. Products with lots of files usually break in quiet ways first. That is why recovery needs practice before the bad deploy happens.

Mistakes teams make with object storage

The first mistake is obvious once you see it: teams protect the database and forget the bucket. That looks harmless until a deploy removes product images, user uploads, invoices, or export files that never lived in the database in the first place.

Another mistake is trusting sync jobs too much. A sync tool does not know the difference between a good change and a bad one. If someone deletes the wrong folder or a script writes empty files, the sync job can copy that damage everywhere in minutes.

Many teams also keep delete power in one broad admin account. One stolen password, one rushed cleanup, or one bad script can wipe large parts of a bucket. Separate accounts, narrower permissions, and extra review for destructive actions sound dull, but they prevent a lot of incidents.

Restore testing gets skipped until people are already under pressure. Then the team learns that versioning was off, old file versions expired too early, or nobody knows which command restores one folder without touching newer data. A backup you never test is a guess.

Generated files get missed all the time. Teams remember the originals, but forget thumbnails, resized images, reports, PDFs, audio previews, and exported archives. Sometimes you can rebuild them, but rebuilding may take hours and put extra load on the app right when users already see broken pages.

The pattern is simple: buckets need the same care as databases. Use versioning, tighten delete rules, and run restore drills people actually complete.

Oleg Sotnikov often works with companies that want to cut cloud waste without making recovery weaker. The useful starting questions are simple: which files matter, who can delete them, and how fast can the team bring them back after a bad deploy?

Quick checks for this week

Most teams can find the biggest gaps in one short session. Pick one production bucket, one recent file, and one teammate who did not set the storage up. A fresh pair of eyes usually spots weak points faster than another settings review.

• Verify that versioning is active on every production bucket.
• Recover one small file from an older version and time the task from start to finish.
• Review who can delete objects, older versions, or entire buckets, including CI jobs and old access keys.
• Read lifecycle rules line by line and compare them with real recovery needs.
• Write the restore steps and drill result somewhere the team can reach during an incident.

One simple test makes this real. If a script deletes 500 product images during a deploy, you need to know two things right away: older versions still exist, and someone on the team can bring them back without guessing.

If your current setup passes those checks, you already have a better shot at bad deploy recovery than many teams that only back up their database.

What to do next

Start with the buckets that would hurt most if they vanished for an hour. In most products, that means customer uploads, product images, invoices, exports, and reports.

Do not wait for a perfect plan. Fix delete rights first.

Most file loss does not come from a rare disaster. It comes from a person, script, or deploy removing the wrong files with too much access. Cut hard delete permissions down to a small group of admins or service accounts, and separate everyday upload access from delete access wherever you can.

A practical order looks like this:

• Pick the top 1 to 3 buckets that hold customer-facing files.
• Turn on versioning and set a retention window that fits your storage budget.
• Review who can delete objects, prefixes, or whole buckets.
• Put one restore drill on the calendar every month.

Keep the drill small. Recover a few deleted files, one overwritten file, and one full folder into a safe test location. Time the work. Write down what slowed the team down, whether that was missing permissions, unclear naming, or trouble picking the right version.

Monthly drills beat a backup document nobody reads. A 20-minute practice run will tell you if the backups work, whether the team knows the steps, and how long a real recovery will take.

If you manage lots of files, resist the urge to spread effort across every bucket at once. One protected bucket with versioning, tighter deletion controls, and a tested restore path is better than ten half-finished setups.

If you want an outside review, Oleg Sotnikov at oleg.is helps startups and small teams sort buckets by risk, tighten delete permissions, and rehearse restores through Fractional CTO advisory. A short review is often enough to catch the obvious gaps before they turn into an expensive mistake.