Coding agents now have shell access to real machines. They run migrations, clean directories, reset branches and remove files that look like clutter, and most of the time that's exactly what you asked for. The failure mode is new though, and it's why AI agent backup has become a category of its own: a copy the agent can reach is a copy the agent can destroy, usually while doing something it was told to do.
This isn't a hypothetical risk invented to sell storage. Anyone running agents against a live checkout has watched one delete something it shouldn't have. This page covers the AI agent backup pattern that actually holds, and is equally clear about what it doesn't protect against.
Why Your Existing Backup Isn't an AI Agent Backup
The traditional threat model assumes hardware failure, human error or ransomware. Agents sit awkwardly across all three, because they act with your credentials, at machine speed, with plausible justification.
A mounted network drive is visible to anything running as your user. So is a synced folder, a mapped drive, or an object-store bucket whose keys sit in an environment file the agent can read. If the agent decides a directory is stale build output, or that a repository needs resetting, or that disk pressure needs relieving, everything it can see is in scope. Sync then propagates the deletion to the copy you were relying on, which is precisely what sync is designed to do.
So the distinction that makes an AI agent backup different isn't cloud versus local. It's whether the copy is reachable from the environment the agent runs in.
The AI Agent Backup Pattern: Push, Never Sync
This is the part people get wrong, and it deserves its own heading.
Sync is bidirectional by nature. Delete locally and the remote follows, which is the behavior you want for working files and the behavior that destroys an archive. Plenty of setups described as backup are really sync, and they protect against a dead disk while offering nothing against deletion. National guidance on ransomware resilience has made the same point for years — CISA's advice is that a copy must be isolated from the system it protects, and an agent with shell access is simply a fast new way of failing that test.
A working AI agent backup uploads new material and never mirrors removals. Timestamped or dated destinations mean each run adds rather than replaces. Storage is cheap enough that thirty daily copies of a database dump cost less than the hour you'd spend explaining why you couldn't restore one.
Credential Separation Is the Whole Trick
The mechanism is unexciting, which in backups is a virtue. You want a push-only path with credentials the working environment never holds.
Drive supports app passwords scoped to a device, created in the dashboard and revocable one at a time. The pattern that works is a dedicated backup credential living only on the machine or scheduled job doing the pushing — never in the project directory, never in a shared environment file, never in anything the agent has been pointed at. The agent operates freely on the working copy and simply has no path to the destination.
If the pushing job runs on the same machine as the agent, keep that credential outside the project tree. If it runs elsewhere, on a small always-on box or a scheduled runner, the separation is cleaner still because no filesystem is shared at all. Either way the AI agent backup survives not because permissions forbid deletion, but because there's no credential to present.
What an AI Agent Backup Protects Against, and What It Doesn't
Being precise here matters more than sounding reassuring.
It protects against an agent deleting or overwriting files in the working environment, a script clearing a directory, an accidental repository reset, and ordinary human error of the rm-in-the-wrong-place kind. It also covers sync faithfully propagating a deletion you never intended.
It does not protect against someone holding your dashboard login and second factor, since they can revoke app passwords and empty the trash like anyone else. It doesn't stop you deliberately deleting the archive. And it's no substitute for version control on source code, which solves a different problem and solves it better.
An AI agent backup is one layer. It isn't a security program, and any page claiming otherwise is overselling.
The Short List Worth Pushing
The list is shorter than people expect, because most of a working directory is reproducible.
- Database dumps. The thing that genuinely can't be regenerated. Nightly, dated, kept as long as your tier allows.
- Environment and configuration files. Small, rarely backed up, painful to reconstruct — and the files most likely to be tidied away by something trying to help.
- Uploaded user content. Not in version control, not regenerable, overlooked until it's gone.
- Generated artefacts you care about. Reports and exports produced by a process that has since changed.
Source code usually doesn't belong here, because a remote git repository already is the backup. Including it does no harm, but it isn't what this layer is for.
The Shape of a Nightly Job
The implementation is short enough that its brevity is the point — there's nothing here to maintain, which is why it keeps working.
A scheduled task runs once a night. It dumps the database to a temporary file, names the file with the date, uploads it to a dated path on the drive, and deletes the local temporary copy. Configuration files and uploaded content go the same way. The job holds its own credential, reads nothing from the project directory, and has no delete capability in its logic at all.
Two details separate an AI agent backup that works from one that quietly doesn't. First, the destination path must include the date, so each run creates rather than replaces — a job uploading to the same filename every night gives you exactly one backup, of last night, which is no protection against a problem you notice on Thursday. Second, the job should fail loudly. A backup that has been silently failing for six weeks is worse than no backup, because you believed you had one.
Testing the Restore
A backup nobody has restored is a hypothesis, not a backup, and this is where most setups are weakest.
Once a quarter, take a backup file and actually restore it somewhere disposable. You're checking three things: that the file downloads intact, that it's complete rather than truncated by a job that failed halfway, and that you remember the procedure. The third one matters more than people admit — the moment you need a restore is never the moment to work out how it's done.
Restoring also verifies something specific to an AI agent backup: that the credential still works and hasn't been revoked or rotated without the job being updated. A push-only credential fails silently in one direction, so the upload side can break while everything appears normal.
How Long to Keep Things
Retention is a storage question rather than a technical one, and the answer is usually longer than people first choose.
The failure this protects against isn't always noticed immediately. An agent removing a directory is obvious within hours; an agent subtly corrupting data, or deleting something used only monthly, might go unnoticed for weeks. Thirty daily copies gives you a month of history, which covers most of that. At current rates a month of dumps is a trivial amount of storage for anything short of a very large database.
A common pattern is keeping every daily copy for a month, then one per month for a year, which bounds the growth while preserving the ability to go back further. Whatever you choose, prune deliberately with a separate job rather than letting the backup job delete anything — the moment your uploader can also delete, you've reintroduced the risk you built the whole arrangement to avoid.
Where to Put It
Drive attaches to the same account as your mail, which keeps the number of services and invoices down, and the add-on starts at 250 GB for $3.20 a month on a slider that runs to 100 TB. For AI agent backup purposes the useful property isn't the headline rate but the absence of egress charges — restoring is the moment you need the data most, and it shouldn't generate a bill.
Storage can be pooled across the account or carved out per mailbox, so a backup destination stays separate from anything else consuming space. Uploads go over WebDAV or the API, and the mounting detail is in the WebDAV guide. Folders can also be shared with another account so a colleague can restore without holding your credentials, which is covered in how share links work.
None of this is exotic. A dated folder, a credential the working environment doesn't have, and a job that only ever adds. The reason it's worth writing down is that agents made an old piece of advice load-bearing again: the copy that saves you is the one nothing in your working environment can authenticate to.
