Setting Up Backups: Letting AI Wire the Safety Net While You Decide What You Can’t Lose

Your app is live and it’s holding real data now. Real users, real accounts, real things they’ve typed in and saved and expect to still be there tomorrow. Say you’re building a tool that lets small nonprofits track their donors and donations. At some point the thought lands that if something went wrong (a bad deploy, a corrupted database, a mistaken delete) all of that could just be gone. So you ask your AI assistant to set up backups. A minute later it’s done: a nightly job that dumps your whole database, stores it somewhere, and rotates the old copies out. It reads like the responsible thing a real operation does. You check the box in your head and move on, feeling covered.

And you might be. Or you might have a nightly backup of everything that quietly fails to protect the one thing you’d actually panic about losing, in the one way it’s most likely to disappear. A donor emails in March asking you to correct a gift they made in January, and you go to look, and you realize your backups only go back thirty days, so the correct earlier version is gone. Or a bug silently corrupts records for a week before anyone notices, and every backup you have is a copy of the already-broken data. The backup ran every night exactly as told. It just wasn’t protecting against the thing that actually happened. The careless version of this job isn’t asking AI to set up backups. It’s accepting a generic backup scheme and assuming that “backups exist” and “the thing I can’t afford to lose is safe” are the same sentence.

What this job actually is

Setting up backups is two jobs that get treated as one. The first is the mechanism: actually copying your data somewhere safe on a schedule, storing those copies reliably, rotating out old ones, and making the whole thing run without you babysitting it. That’s real, fiddly engineering work, and AI is genuinely good at it. It knows the tools, it knows how to schedule the job, it can wire up storage and handle the rotation and make sure a failed backup doesn’t fail silently. Handing AI the plumbing is a fine idea; it’ll build a solid, working backup pipeline faster than you would.

The second job is deciding what you’re actually protecting, and against what. Which data would genuinely hurt to lose, and how much of it, and how far back? How much of it can you afford to lose measured in time, an hour, a day, a week? What are you protecting against: a server dying, a bad deploy, a slow corruption nobody catches for days, a user deleting something they didn’t mean to, your own hosting provider having a very bad day? And here’s the one people skip entirely: can you actually get the data back when you need it, or do you just have files you’ve never once restored from? That’s not plumbing. It’s a judgment call about what matters and what failure you’re really guarding against.

Here’s the distinction that matters: AI can generate the backup mechanism, but deciding what you’re protecting and against what is yours. A backup that runs is not a safety net that holds. The value of backups shows up only in the worst moment you’ll ever have with your app, and whether they save you then depends entirely on choices made now: what got copied, how far back it reaches, and whether it can actually be restored. AI can build a flawless nightly dump and still leave you exposed, because it doesn’t know which data is precious, how much loss you can stomach, or which disaster is the realistic one, and it can’t know any of that unless you tell it.

How to delegate the mechanism

So lean on AI for the part it does well, which is building the pipeline once you’ve decided what it needs to do. The careless version is “set up backups,” which produces the generic nightly dump that may or may not fit your actual risk. The good version starts with you naming what you’re protecting and against what, and then hands AI the job of building a mechanism that matches.

Once you’ve decided the shape of what you need (this data, this often, kept this far back, restorable this way), AI is exactly the right tool to make it real. Ask it to build the backup job on the schedule you chose, to store the copies somewhere separate from your live system so one failure can’t take out both the data and its backup, and to rotate old copies according to the retention you decided on. Ask it to make sure a failed backup makes noise instead of failing quietly, because a backup system nobody’s watching has a way of stopping without telling anyone. Ask it to write down the restore steps clearly, so the procedure exists before the emergency does.

The move that makes this delegation good is asking AI to build a restore path, not just a backup path. Most backup setups are really only half a system, because they copy data out and never prove they can put it back. Ask AI to give you a way to actually restore from a backup into a safe test spot, so you can confirm the copies are real and usable and not just files taking up space.

What you don’t do is ask AI to decide what to back up and how long to keep it. The moment you say “set up sensible backups for my app,” you’ve handed off the judgment, and AI will give you the safe-sounding default (nightly, everything, keep thirty days) because with no idea what you’re protecting or what you’re afraid of, a generic scheme is the only honest thing it can build. Keep the ask on mechanism. Here’s what to copy, here’s how often, here’s how far back, here’s where to put it; build me that, make it loud when it fails, and give me a way to restore it.

The judgment you keep

What you’re protecting, how far back, and against which disaster is the call, and it’s yours because it turns on something AI can’t see: which data you truly can’t afford to lose and which failure is the one you actually need to survive.

This is hard because the generic backup feels like enough. It runs, it produces files, it looks like protection, and it’s genuinely better than nothing. The trap is that “better than nothing” hides how it might not be better than the specific disaster coming for you. The judgment is in thinking concretely about your own worst days: not “what if I lose data” in the abstract, but “if a bug corrupted donor records and nobody noticed for ten days, would any of my backups still hold a clean copy?” and “if someone deletes a donor by accident, can I bring back just that one without rolling the whole app back a day?” Those are different disasters that need different protection, and a single nightly full dump answers some of them and not others. For the nonprofit tool, if donation records are the thing that absolutely cannot be wrong or lost (because they’re what people file taxes and run audits against), then thirty days of retention might be nowhere near enough, and slow corruption might be a bigger real threat than a server dying.

AI can’t make this call because it doesn’t know what’s sacred in your data or which failure is realistic for you. It can build any backup scheme you describe, but it can’t weigh a week of tolerable loss against an hour of intolerable loss, or know that your donation history needs to reach back years while your session logs don’t need backing up at all, because that weighing depends on what your users trust you to keep and what it would cost them if it vanished. Get this wrong and you find out at the worst possible moment, staring at a backup that doesn’t go back far enough or only contains the broken version, discovering the gap exactly when it’s too late to fix. Knowing what you’re really protecting, and from what, is the whole point of backing up at all.

Before you ship this job

Here’s what good delegation looks like, and the line it can’t cross.

The sample prompt. Something real you might send:

I’m building GiveTrack, an app that helps small nonprofits track their donors and donations. My main user is someone like Marcus, who runs a two-person nonprofit and relies on this data for tax receipts and annual audits, so the donation records have to be accurate and available going back years. I’ve already decided what I need, and I want you to build it: back up the donor and donation tables every six hours, keep those backups for at least two years, and store them somewhere completely separate from the live database so one failure can’t destroy both. Session logs and temporary data don’t need backing up. Make the backup job alert me loudly if it ever fails instead of failing silently. Most importantly, also build me a restore path: a clear, tested way to restore from a backup into a separate safe environment, and a way to restore a single deleted record without rolling back everything. Write down the restore steps so they exist before I ever need them. Don’t decide the schedule or retention for me; I’ve given you those; just build the mechanism to match.

Use this and you get a backup system shaped around what you actually can’t lose. Copy it as-is and you’re protecting GiveTrack’s data instead of yours, guarding against Marcus’s disaster with Marcus’s retention and Marcus’s idea of what’s precious. Your app holds different things and faces a different worst day, and the mechanism only protects you if the decisions underneath it are yours.

The part you can’t hand off is what you’re protecting and against what: which data is precious, how far back it has to reach, how much loss you can survive, and which specific disaster (a dead server, a slow corruption, an accidental delete) you’re actually guarding against. That set of decisions is the job, and it’s the thing the prompt above is built around but could never have produced on its own.

How to check AI did its part: don’t trust a backup you’ve never restored from. Take your backup system and actually run the restore, into a safe test environment, and confirm the recovered data is complete, correct, and reaches as far back as you decided it should. Then try the harder case: delete a single record and see whether you can bring back just that one without rolling everything back. If the restore works and the data is all there, you have a real safety net. If the restore is confusing, incomplete, or you discover the backups don’t actually go back as far as you thought, you have files, not protection, and better to learn that now than during the emergency. A backup you’ve never restored from is a guess, not a guarantee.

What you get for doing it this way

Go back to that nightly dump and the quiet confidence of having checked the box. The difference between accepting a generic backup and building one around what you can’t lose is the difference between a safety net you hope is there and one you’ve actually tested holds your weight. When you decide what you’re protecting and let AI build the mechanism to match, you get backups that reach back as far as your real obligations do, that guard against the disaster that’s actually likely, and that you’ve proven you can restore from before you ever have to do it in a panic.

AI can build you a backup system that runs like clockwork. What that system needs to protect, and which disaster it needs to survive, was always going to be your call, because only you know what your users trust you to keep and what it would cost them to lose it. That’s the job: let AI wire up the safety net, then decide for yourself what it has to be strong enough to catch.