Helper CTO Series 10 | Does Your AI Product Have Backups: The Minimum Standard for Database and Files

"Backups? The hosting provider probably backs that up for us, right?" Whenever we hear the word "probably," we already know the answer is usually no. What's the cost? A very common scene: one day a database record gets deleted by accident, and after digging around, the most recent backup turns out to be six months old — and nobody's ever tried opening it to see if it even works. It's not that you don't value your data — backups were never a "feature," so nobody thought to ask AI to add them along the way. Here are the three misconceptions we most often have to correct first when we take over a system.

Three misconceptions about backups

• Misconception one: the hosting provider backs it up for me. Most hosting providers offer "snapshots": possibly off by default, stored in the same place as the server itself (so if that provider's region goes down, your backup goes down with it), and covering the entire machine — pulling out one specific order from inside it is a real hassle. The hosting provider is responsible for the machine staying alive, not for your data staying intact.
• Misconception two: having Git means having a backup. Git stores code, not data. Customer lists, orders, and user-uploaded photos are never in there. Lost code can be rewritten; lost data can't.
• Misconception three: having a backup means you can always restore it. A backup file existing doesn't mean it's complete, doesn't mean it isn't corrupted, and doesn't mean anyone knows how to turn it back into a working system.

Database and uploaded files are two different things

A system's data usually splits into two types, and backups need to handle them separately:

• The database: structured data like customers, orders, settings, and logs. It's a constantly changing whole, and the approach is to export the entire database into a file on a regular schedule.
• Uploaded files: images, documents, and videos users have uploaded. These live scattered across a folder on the server or in cloud storage, with the database only recording "where the file is," never the file itself.

Back up only the database, and after restoring, every order exists but every product image is broken. Back up only the files, and after restoring, every image exists but nobody knows which one belongs to whom. The gap between vibe coding and real system architecture covers exactly this: where data ends up living in an AI-built product is usually "wherever was convenient at the time," so before you can back anything up, you first need to know how many different places the data is scattered across.

The bare minimum: four items

This isn't enterprise-grade practice — it's the baseline any product with real customers should already have.

• Frequency depends on data volume: once a day means a worst case of losing one day — scale it up if the volume is large.
• Access to backups stored elsewhere also needs to be controlled — that file contains every one of your customers' data.
• A backup file is itself a potential leak source, just like the keys covered in the security landmines AI-written code steps on most — store it in the wrong place and you've handed it over.

It only counts as a backup once you've tested restoring it

Backups tend to fail quietly: the schedule stops running and nobody notices, the backup file gets truncated because storage ran out, the database password changed but the backup script never got updated, or the backup was stored in an account that later got closed. In every one of these cases, you'll see "a backup file exists" — right up until the day you need it and discover it won't open. Testing a restore isn't complicated — the point is actually doing it:

• Find somewhere unrelated to production, and restore the most recent backup there.
• Log in and spot-check a few recent records to confirm the content is correct.
• Open a few images and uploaded files to confirm they're viewable.
• Note how long the restore took — that's how long a customer would have to wait if something actually went wrong.

A restore test also checks something else: whether anyone actually knows how to do it. If only one person knows, and the steps were never written down, what you have is a backup plus a single point of failure. None of these four standards is individually hard — what's hard is the ongoing part, "every day" and "every quarter." Whoever's building the product is thinking about the next feature, and a backup working a hundred times in a row goes unnoticed — only the one time it doesn't gets remembered.

Nerdtechnic treats backups as a baseline part of maintenance

• Backups aren't an add-on: bundled with monitoring and security updates into basic maintenance, starting at NT$6,000/month, billed monthly, and you can stop anytime.
• Fixed in the first week of a takeover: this is the first item in the fix order covered in demo-ready isn't launch-ready, because skipping it is unrecoverable.
• We can prove it's actually running: a response within 1 business day when the server or a service goes down, backup and restore status logged, and handed over to you when the engagement ends.

Whoever's responsible for the system should be responsible for its backups — and be able to prove the restore actually works.

Backups are one of the first things we fix in week one whenever we take over a system as Helper CTO — like an in-house tech lead, just not on your payroll, with the same team handling takeover, maintenance, and improvement. The first step is a 60-minute system health check: we only need to see the code, no credentials to your production environment required, and within 3–5 business days you'll get a one-page report, and the current state of your backups is one of the items covered. If you can't even answer "when was the last backup," you can start here: Helper CTO: System Maintenance Plan.