The recent release of OpenAI’s GPT-5.6 has sparked considerable
discussion: in the pre-release
materials and system card, the company officially acknowledges that
the Sol model, in agent-based programming scenarios, may occasionally
take destructive actions due to overzealous goal pursuit or excessively
broad permission interpretation. A team member
also confirmed that a small number of reports of accidental file
deletions were indeed received and investigated. Many developers have
also complained on social media: while the AI was refactoring projects
or modifying configuration files in the background, it mistakenly
deleted users’ root directories $HOME or entire project
codebases.
In the era when only humans wrote code by hand, accidental deletions usually involved just one or two files, and we could immediately realize when we slipped up. But now that AI agents like Cursor, Claude Code, and Codex have gained the ability to directly modify local files, the destructive potential operates on an entirely different scale: an agent can alter hundreds of files in the background within seconds. By the time you notice something is wrong hours later, the damage has already been silently propagated and buried.
Most people’s first instinct is that they urgently need to set up a backup. Yet most developers without an operations background either feel completely lost when facing backup, or mistakenly treat sync folders as backups.
The truth is, in the AI era, AI is both the instigator that amplifies the risk of accidental deletion and the super-assistant that makes building a backup system unprecedentedly simple. As long as you clarify a few fundamental concepts and master the language of result certainty, you can build a reliable backup system that even AI cannot destroy — in the time it takes to drink a cup of coffee.
Before setting anything up, we need to correct two of the most common misconceptions and clarify a few fundamental concepts.
rsync) or Sync Folders Are Not Real BackupsMany people are accustomed to using rsync --delete
commands or cloud sync tools to periodically mirror files from their
computer to another machine or the cloud. It seems reassuring: the
directory structure on the other side is identical to what you have
here, ready to use at any time.
But this hides a fatal blind spot: a mirror preserves the current state, not the history.
If an AI agent accidentally deletes an important folder this afternoon and you don’t notice it at the time, the scheduled mirror task will faithfully run later that evening — and it will silently erase the corresponding folder on the target side to keep both sides consistent. The mirror didn’t malfunction at all; it actually worked too well — well enough to faithfully replicate your current mistake onto your backup device.
A mirror only gives you another copy of today; it cannot give you yesterday that you can return to. A backup designed to protect against accidental deletion must have versioning capability.
Since we need to preserve history, if we made a full copy of hundreds of gigabytes of data every single day, the hard drive would fill up quickly. This is where incremental backup comes in.
The principle of incremental backup is: make a full backup the first time, and thereafter only record the data chunks that are new or modified. Borg Backup is one of the best tools in this category, with exceptional deduplication and compression capabilities: even if you back up every day, as long as most files haven’t changed, the additional storage footprint is minimal, and the speed is astonishingly fast. More importantly, each historical archive in Borg, when mounted, presents itself as a complete point-in-time snapshot — you can flip back to any moment from yesterday, last week, or even last month, and retrieve the accidentally deleted files in their entirety.
The worst thing you can do with backup is rely on manual effort.
Manual effort cannot form a discipline; the day you forget to click is
the day disaster strikes. Backup must be automated: - On Linux / macOS,
this is typically done using cron, the scheduled task
manager; - On Windows, the equivalent is Task Scheduler.
At the same time, the automated system must be failure-sensitive: if the disk runs full, the network drops, or insufficient permissions cause a backup failure, the system must never fail silently. It must leave explicit error logs and alert you.
If you’ve never set up a backup before, the simplest starting point is not to learn command-line tools, but to buy an external hard drive.
The advantage of an external hard drive is its physical intuitiveness: it doesn’t consume space on your main drive, it runs automatically when plugged into your computer, and when necessary, you can unplug it for offline isolation.
crontab expressions or Windows Task Scheduler. This would
deter 99% of ordinary users.The AI will automatically look up paths, check the environment, write
automation scripts, and configure cron or Task Scheduler
for you.
Once you’ve mastered basic backup, you can further upgrade based on your use case:
Relying solely on an external hard drive still carries the risk of both the computer and the drive being in the same room when an accident happens (or of forgetting to plug in the drive).
If you have a machine on your LAN that stays on 24/7 (such as an old computer, NAS storage, or a small server), the best approach is to use it as a backup node: - Network recommendation: It’s best for the backup host to use a wired network card; gigabit or 10-gigabit LAN speeds are far faster than Wi-Fi; - AI implementation: Let the AI generate SSH keys for you and configure encrypted Borg backup from your local machine to the LAN server. You don’t even need to log into the SSH terminal yourself — the AI will handle authentication and communication between the two machines automatically.
If the objects you’re backing up include running applications or databases (such as PostgreSQL, MongoDB, etc.), under no circumstances should you directly copy the database’s data directory! Because the database has ongoing writes at any moment during operation, a direct copy will result in inconsistent data blocks — the restored database will simply fail to start.
The correct approach: First, have the AI write
pre-processing logic that invokes database consistency export tools
(such as pg_dump or mongodump) to generate
export files, then include these exported dump artifacts in Borg’s
incremental backup. This ensures data consistency while leveraging Borg
for historical version archiving.
There is an iron law in the backup world: a backup that hasn’t been tested for restore is roughly equivalent to having no backup at all.
Many people set up Borg, hook up cron, and assume
everything is fine — only to discover, when disaster actually strikes,
that the key is lost, the path was written wrong, or the extracted files
are corrupted.
This is where the core concept we emphasized in our earlier blog post From Process Certainty to Result Certainty comes into play: in the AI era, don’t micromanage every step of the agent’s process (process certainty). Instead, define executable success criteria and require it to provide verifiable evidence (result certainty).
When you ask AI to set up a backup for you, if you merely command it to “run Borg commands and set up a crontab,” you are micromanaging the process. The truly reliable approach is to require the AI to complete a real restore test after the backup is done:
After each backup completes, the system must automatically extract a real, non-sensitive file (such as a project configuration file or document) from the newly created backup, restore it to a new location outside the source directory, and automatically compare both the content and the SHA-256 hash. Only when the extracted file opens intact and matches perfectly can the backup be declared successful.
This is result certainty: you don’t look at whether the log reported errors, or whether the script returned a zero exit code — you look at whether the real file was successfully brought back.
You can copy the following prompt verbatim and paste it to your AI agent (such as Claude Code, Cursor, Codex, etc.), and let it automatically build a backup system with result-certainty verification for you:
First, perform a read-only inventory of this machine's important data, operating system, existing backups, and available independent storage. Then build an encrypted backup system that runs automatically, retains historical versions, and supports verified recovery. Do not just give a tutorial; implement within safety boundaries and report results with evidence.
Completion must simultaneously satisfy:
- The backup target is on an independent physical disk or LAN/off-machine server separate from the source data; the repository must not be re-included as a backup source;
- Important directories and exclusions have been inventoried; if running databases are included, first export them in an application-consistent manner (e.g., pg_dump/mongodump), then back up the exported artifacts;
- Backups run automatically via the platform-supported mechanism (cron on Linux/macOS, Task Scheduler on Windows); failures leave visible logs; repeated runs do not corrupt data;
- The first run does not execute prune, compact, deletion of old files, or cleanup of recovery directories; any destructive maintenance must first display a real preview and wait for my confirmation;
- Before the first archive, select real, non-sensitive files from each recovery domain, record their paths, sizes, and SHA-256 hashes; after archiving, restore the samples to a new directory outside the source directory and repository, compare each one, and retain the recovery directory for my inspection;
- The final report must list PASS, BLOCKED, and NOT RUN separately, along with the repository location, archive identifier, log paths, recovery directory, and comparison results. As long as the restore comparison has not passed, do not declare overall completion.
Without my explicit confirmation, do not read secret values, request broad administrator privileges, modify existing scheduled tasks, or perform any destructive actions. If the current platform is Windows, first verify the selected tool's stable support for Windows file and scheduling mechanisms; if unsuitable, stop implementation and explain safer native alternatives. If independent storage, credentials, or business judgments that only I can provide are missing, clearly report the blockage; do not use unverified temporary solutions to impersonate completion.The proliferation of AI agents has elevated the risk of accidental file deletion from an occasional slip of the hand to a constant hidden threat — yet at the same time, it has lowered the once cumbersome and complex operational barrier to ground level.
We no longer need to memorize crontab syntax or grind
through Borg’s command-line parameters. We only need to grasp a few
clear fundamental concepts (incremental versioned history, not
mirroring), choose the right medium (from an external hard drive to a
LAN server), and constrain the AI with result certainty — first prove
that the data can be brought back intact, and only then grant it broader
permissions.
Delegate the tedious execution to AI. Keep the definition of the endpoint and the verification to yourself. That is the most reassuring path to safety in the AI era.