How I back up everything automatically, and where AI actually fits
# How I back up everything automatically, and where AI actually fits
People ask me about the AI tools. They ask about the video pipeline. Nobody has ever asked about my backups, and yet the backups are the one part of my setup I would genuinely grieve over losing. They run every night, I rarely think about them, and that is the entire point. This post walks through how the system is built, why it is shaped the way it is, and the narrow role AI plays in keeping it honest. There is a right place for AI in a backup system and a wrong place, and the wrong place is one drive failure away from a very bad week.
Why this is the job everyone skips
I understand why backups get skipped. They do nothing visible. They make no demo more impressive and no workflow faster. They sit quietly in the background until the day they are the only thing standing between you and total loss. The cost of skipping them stays invisible right up until it becomes catastrophic, which is a terrible property for a risk to have, because it means the lesson usually arrives too late to be useful.
I have watched this happen to other people. Someone loses a drive holding years of photos. A small business finds it cannot invoice anyone because the accounting files lived on one dead disk. There is no drama to it. The loss is quiet and total, and afterward there is nothing to be done. Hardware is replaceable. The data on it is often not. So before any of the clever parts, the goal here is a real system, with schedules and tested restores, instead of a vague intention to copy some files sometime.
Three copies, two kinds of media, one offsite
The frame I build around is called 3-2-1. Keep three copies of your data. Put them on two different kinds of storage. Keep one copy somewhere other than your home or office.
Each number covers a different failure. Three copies means two drives would have to die at the same moment for you to lose anything, which is unlikely. Two kinds of media means a failure mode specific to one storage type cannot take out everything at once. One offsite copy covers the physical events, a flood or a theft or a fire, where everything in the building goes together.
None of this is new. The idea is old and dull and it works, and I feel no need to dress it up. Once the frame is in your head, building the actual system is mostly filling in the boxes.
What my three copies look like
Copy one is my working data, the files on my main machine that I actually touch every day. Copy two is a local backup drive, a separate physical disk sitting next to the machine. Copy three is an encrypted backup pushed to cloud storage automatically.
The two backup copies serve different recovery speeds. The local drive gets me working again fast if my main disk dies, because there is no download to wait for. The remote copy gets me back at all if something happens to the whole location, or if both local disks somehow fail together.
One qualifier matters more than the rest of this section. All three have to be copies I can actually restore from. A copy that cannot be restored is a file that looks like a copy until the day you need it, at which point it turns out to be nothing.
Encryption, and the key that comes with it
The remote copy is encrypted before it leaves my machine. The service storing it cannot read what is inside, no matter what happens on their end. The key lives with me and nowhere else.
That design has a sharp edge. If I lose the key, the backup is useless to me too. So the key is backed up separately, in more than one place, and I treat it like a password whose loss would ruin my year. I have seen people set up encrypted backups, misplace the key, and discover that their backup is perfectly intact and completely unreadable. If you encrypt, backing up the key is part of the job, and skipping that step quietly converts your safest copy into noise.
Schedules instead of memory
Everything runs on a schedule. The local backup runs nightly. The remote backup runs nightly at an offset time so the two jobs are never fighting for the same resources. I do not open anything, remember anything, or tick any box. The jobs run whether I am at the machine or travelling or sick or simply distracted by something shinier.
A backup that depends on me remembering it is a backup that works most of the time. Most of the time sounds close to all of the time and is nothing like it. The gap between the two is exactly where data loss lives, so the schedule is the system. My memory is just a bonus.
Boring software does the copying
The actual data movement is handled by tools with no intelligence in them at all. rclone handles the remote sync. A plain local backup tool copies files to the second drive. Both have been doing this one job for years.
These tools never improvise. They make no judgment calls about which folder seems important. They copy what I told them to copy, to where I told them to put it, and produce the same result every single run. That predictability is the entire feature, and it sets up the most important distinction in this whole post.
Where AI earns its place
I want to be honest about where a little AI genuinely helps here, because it does, just in narrower ways than the marketing suggests.
The first is build speed. When I was first writing the rclone flags and the scheduled task definitions, I had a model draft the configs from a plain description of what I wanted. I read every line and adjusted plenty, and I still finished in an afternoon instead of a day spent spelunking through documentation. The model helped me write the tooling faster. It did not replace the tooling.
The second is log summaries. Backup tools produce long logs after each run, dense with lines that mean a lot to a careful reader and very little at a tired glance. A small step in my setup feeds the relevant output to a model and asks for plain language: did everything complete, did any files fail to transfer, how much data moved, anything unusual. I get a few readable sentences back. The full log stays on disk, and the summary sits on top of it, so a problem that would have hidden inside hundreds of lines now surfaces in ten seconds.
The third is failure alerts. When a backup fails or overruns, the alert I receive has already been passed through a model, so instead of a raw error code I read something like: the nightly remote backup did not complete, the last clean run was two days ago, the error looks like a network timeout, this is the step that failed. I can read that mid task and immediately know whether to drop what I am doing. Plain language matters most when the goal is acting on information quickly.
The line AI never crosses
Here is the part I feel strongest about. AI must never be the thing doing the copying.
A language model predicts plausible next steps from patterns. That is a remarkable capability, and it is the wrong property for the process that decides whether your data exists tomorrow. Backup software has to be deterministic. It has to behave identically on its thousandth run, with no off days, no ambiguous prompt, no moment of creative interpretation about whether a folder looks worth keeping. I have seen setups where an agent decides what to back up, or where a model writes and executes the backup commands at runtime. That is a reliability disaster on a timer.
The mental model I use: AI lives at the edges. It helps me build the system, read the system's output, and act on the system's alerts. The core, the actual movement of bytes, belongs to software with no opinions and no ability to improvise. Let the model into the core and you have injected unpredictability into the one layer that must be predictable above everything else.
Test your restores
One rule sits above all the others, and it is the one I watch people skip most. A backup you have never restored from is a set of files you hope are restorable, and hope is doing a lot of work in that sentence.
I run test restores on a schedule. I pull a meaningful sample of files back out and verify they are what they should be. This has caught real problems twice. Once, a backup that looked healthy had a permissions issue, and the restored files came back unreadable. Another time, the encryption key I had squirrelled away turned out to be an older version that would never have decrypted the current backup. Either one would have been catastrophic on the day I actually needed a restore. Instead I found them on a quiet Tuesday with time to fix them. The restore test is part of the backup system, on the same footing as the backups themselves.
The invisible payoff
Nobody will follow you because your backup system is solid. It will never appear in a demo, and setting it up properly costs real hours of configuring tools, protecting keys, and proving out restores. Then nothing will happen, for years, and you will never see what it saved you from. That is the deal. The payoff stays invisible until the one day it is the only thing that matters, and on that day the dullness of the tools will bother you not at all.
The most reliable part of my setup is the part nobody ever asks about. I remind myself of that every time I am tempted to spend the evening on something flashier.
Check out more breakdowns like this at [xavierfok.com](/).
Get new guides and videos first — join the Telegram channel.