Back Up Your PC: A Step-by-Step Plan That Works on Windows, macOS and Linux

A backup is a copy of your data on different storage, made at known times, that you can put back when something goes wrong. Notice what that definition leaves out: it does not say “installed”, it does not say “running”, and it does not say “finished last night”. Those are the three words that fail people in practice. Drives die without warning, ransomware encrypts every copy it can reach from an infected machine, and accidental deletion is by far the most common loss event a home user ever has — usually on a file they edited ten minutes earlier. A plan that only guarantees copies exist, without guaranteeing they are current, reachable and restorable, has solved none of those three problems.

This tutorial is the action half of the site’s backup coverage. The Backup & restore pillar guide explains the concepts — file history versus system images, what each layer covers, and how the pieces fit together. Here you execute: in five phases you will plan (what to back up, where copies live, how often), set up the native tools on whichever operating systems you actually run, protect the copies with encryption and ransomware defenses, verify and recover by testing restores and walking through failure scenarios in advance, and finally work through it with an interactive planner and a master checklist that compresses everything into tickable items. The expected end state is not “I have backups” but “I restored a file from my backup last month and know exactly what to do if the drive fails tomorrow”.

How to use the page: sections 1–5 apply to every operating system, so read them once no matter what you run. Sections 7–9 are platform-specific — jump to your OS and skim the others only if you maintain more than one machine. The interactive backup planner (section 15) assembles a written plan from your own selections, and the master checklist (section 16) tracks progress across all five phases. Below is the full editorial architecture of the series this tutorial anchors: thirty topics in five categories, each mapped to where it lives.

Two honest notes about that table. First, the “planned article” entries are editorial placeholders: the individual pages do not exist yet, so this tutorial deliberately covers each topic at working depth rather than linking to pages that would 404. Second, a few topics overlap with the planned collection on the Backup & restore pillar page (for example backup frequency and ransomware protection appear in both roadmaps). When those articles are written they will take distinct angles from each other — the pillar collection goes deep on one method or failure pattern at a time, while this series is organised around the end-to-end plan a home user actually executes.

The most common backup mistake is not a technical one: people back up either everything (so the drive fills with re-downloadable junk and the things that matter get squeezed out) or nothing concrete (a vague intention to “back up my files” that never becomes a folder list). The decision criterion is irreplaceability, not size. Ask of each category of data: if this disappeared tonight, what would it cost to recreate — in money, hours, or things that cannot be recreated at all? Documents you wrote, photos of people and places, tax and medical records, code you have not pushed anywhere, and configuration that took days to get right all fail that test. Game installs, application installers, OS images and browser caches pass it easily — they can be fetched again, so they do not belong in the backup budget.

The second trap is invisible data. Most of what makes a PC yours does not live in Documents. On Windows, that includes your browser profiles (saved passwords, history, extensions) under %LOCALAPPDATA%, per-application settings scattered through %APPDATA%, and license keys or project files hidden inside app folders. On macOS, the equivalents sit in ~/Library/Application Support, your Keychain, and app containers; on Linux, in the dotfiles and hidden directories of your home folder (~/.config, ~/.ssh, shell configuration). Add the places where data quietly accumulates: photos received through messaging apps (which live in the app’s media folder, not your Pictures library), work files that actually live in a sync client’s folder, and anything stored on a second internal drive you forgot about. A twenty-minute inventory walk — open each location, note what is there and where it lives — beats an hour of guessing later.

Classify what you find into three buckets and let the buckets drive the plan: irreplaceable (back up frequently and keep an off-site copy), important but recreatable with effort (back up on a normal schedule), and rebuildable (exclude it, or back it up only if storage is cheap). Write the result down — a folder list per machine is enough — because the backup configuration in phase 2 is just that list translated into tool settings. The planner in section 15 does this classification interactively if you prefer ticking boxes to writing a document.

These two terms get used interchangeably in conversation, and the difference is exactly where home recoveries go wrong. A file-level backup copies your data — documents, photos, projects, and usually application settings — as individual files that you can pick back up one at a time. A full-system image is a block-for-block snapshot of an entire disk: operating system, applications, drivers, settings and all your files, captured together so the machine can be returned to one exact state. Neither is a version of the other — copying every file on C: to an external drive does not produce a bootable system, because the boot loader, partition layout and system-state data that make a disk bootable are not “files” you can copy by hand. And a system image is not a substitute for daily file versions: restoring last month’s image to recover one deleted document also rolls back a month of everything else.

The practical combination for a home machine is both, at different cadences: continuous or daily file-level history for your data (the layer you will actually use most), plus a periodic system image or the equivalent full-volume backup (the layer that saves you when the OS itself is gone). On macOS the line blurs deliberately: Time Machine’s first run copies your entire startup volume, and subsequent runs keep hourly versions — so one tool gives you both file-level recovery and a path to whole-Mac restoration from Recovery mode. On Windows the two layers are separate tools (File History for files, the image tool or a third-party imager for the system), which is why section 7 sets up both. On Linux there is no single built-in answer; section 9 builds the equivalent from rsync, tar and, where your distribution supports it, snapshot filesystems.

One more distinction that saves people from false comfort: a snapshot is not a backup. Windows’ restore points, macOS local snapshots and Linux btrfs/zfs snapshots live on the same disk as the data they protect — excellent for undoing an accidental change within days, useless if the disk itself fails or ransomware reaches it. And bootable recovery media is a separate artefact: an image without the USB stick that can boot and restore it is a file you cannot use. Section 7 (Windows) and section 8 (macOS) cover creating that media; treat it as part of the backup, not an extra.

The first non-negotiable is physical separation: a backup on the same disk as its original protects against nothing that takes the disk — and drive failure, theft and fire all take the whole machine at once. A second internal drive in the same case is therefore not a backup destination in any meaningful sense; it is a second copy that shares every risk of the first. Everything else in this section is trade-offs between speed, cost, privacy and exposure, which is why the table below lists them side by side instead of declaring a winner.

The 3-2-1 rule turns those trade-offs into a checklist you can verify: keep three copies of anything irreplaceable (the original plus two backups), on two different types of storage media, with one copy off-site. Each number exists to defeat a specific failure mode. Three copies means one bad copy — corrupted, incomplete, or encrypted by ransomware — never becomes the last one. Two media types means one failure class (a flash-memory controller dying, a spinning-platter drive wearing out, a provider outage) cannot take all of them. One off-site copy means the events that destroy an entire location — fire, flood, theft — leave something standing. The rule is a floor, not a ceiling: it tells you when a plan is broken (any number at zero), not when it is optimal.

Apply that shape to your own numbers: size the local backup for everything you would want back (the original data plus room for versions — roughly two to three times the data size is a comfortable starting point), and size the off-site copy for the irreplaceable subset, because cloud capacity costs money per gigabyte. If budget forces a compromise, keep the order of importance: physical separation first (an external drive beats a second internal disk every time), then an off-site copy of the truly irreplaceable data (even 100 GB of cloud for photos and documents is a different risk profile than none). And remember the exposure column in the table above: an always-connected local drive is exactly what ransomware reaches next, which is why section 11 adds the offline or versioned layer on top rather than treating this section as finished.

“How often should I back up?” only has one honest answer: as often as the loss you can accept allows. In industry terms that is a recovery point objective — how far back in time you are willing to go if the worst happens — but at home it reduces to a single question per category of data: how fast does this change, and would losing a day (a week, a month) of changes hurt? A spreadsheet you edit every afternoon loses real work with every hour that passes; a photo archive added to on weekends loses almost nothing between weekly runs. Matching the schedule to the change rate is what makes a plan sustainable: hourly backups of data that changes monthly waste space and attention, while monthly backups of daily work guarantee a painful week in the worst case.

Retention — how long to keep older versions — answers a different question: how far back must you be able to go? Two failure modes set the floor. The first is corruption discovered late: the document that looks fine until you open it three weeks later, or the photo batch that turns out to be half-corrupt. The second is ransomware detected late: if the infection ran for days before anyone noticed, your usable restore point is the last version from before it started — which only exists if you keep versions beyond a day or two. A sensible home default: hourly snapshots with daily versions kept for at least a month and weekly versions kept for several months (this is close to what File History and Time Machine offer out of the box), plus the last two or three monthly system images. Longer retention costs only disk space; shorter retention quietly shortens your real recovery window.

Finally, understand what “automatic” actually promises, because it is weaker than it sounds. A scheduled backup only runs when its preconditions hold: the external drive is connected and powered, the PC is on (and for a laptop, usually not asleep), the network or cloud service is reachable, and there is space left on the destination. A “daily” schedule on a desktop that is off at night and whose backup drive is only plugged in on weekends is, in practice, a weekend schedule. That is not a reason to give up on automation — it is a reason to verify (section 12 checks that runs actually happened) and to place the always-connected copy where the machine really is available. The planner in section 15 applies these schedules to the data you selected.

Start with what your operating system already ships. Native tools integrate with the OS scheduler, need no extra software to keep updated, and their restore paths are documented for exactly the version you are running. Third-party backup applications are legitimate — some households standardise on one across platforms, and a few features (cross-platform restore, advanced deduplication) exist only in third-party products — but every added tool is another thing to update, another set of credentials, and another vendor whose behaviour you must trust with your only copies. For a first working plan, native tools plus one cloud service for the off-site copy cover everything; add a third-party imager later if (and only if) you hit a concrete limitation.

Read that table with one caveat about maturity. Windows’ built-in imaging is a legacy feature: it has survived into Windows 10 and 11, but Microsoft has been de-emphasising old Control Panel surfaces across builds, so its exact availability can shift — check what your specific build offers before relying on it, and test the restore path once (section 12) rather than assuming it will be there when you need it. Time Machine is the most integrated of the three: one tool, fully automatic, covering files and whole-system recovery in the same backup. On Linux the absence of a single GUI answer is normal, not a red flag — a short rsync script with a cron entry is the standard home setup on every major distribution, and it gives you more control over exclusions, logging and verification than most graphical tools do.

If your household runs more than one operating system, apply one policy (the destination set, the frequency, the retention from phase 1) per machine rather than inventing a different scheme for each. The tools differ — File History, Time Machine and rsync will not behave identically even pointed at the same drive — but the plan should: every machine keeps its local versioned copy and contributes to the shared off-site copy of irreplaceable data. That consistency is what makes the disaster recovery plan in section 14 a single document instead of three separate ones.

On Windows the file layer and the system layer are separate tools, so this section sets up both. File History handles your data with hourly snapshots and version retention; the legacy system-image applet (plus recovery media) covers the case where the operating system itself stops working. Work through the steps in order — the verification step at the end is what turns the setup from “configured” into “proven”.

1. Prepare the external drive. Connect it and, if it is new or holds data you can re-create, format it for Windows (NTFS or exFAT via right-click > Format in File Explorer). Formatting erases everything on the drive — copy anything you need off it first. Size rule of thumb: at least two to three times the amount of data you will back up, because version history accumulates.
2. Open File History. Open the Start menu, search for File History and open the “Restore your files with File History” applet. Click Add a drive and select your external drive, then make sure Back up automatically is on. The first run copies everything in scope; leave the PC on until it finishes.
3. Check the scope. In the same applet, review which folders are included: your libraries (Desktop, Documents, Music, Pictures, Videos), contacts and favourites are covered by default. Use Add a folder for anything important that lives elsewhere (a Projects folder, work files) and Exclude folders for rebuildable bulk (game installs, installer caches).
4. Set retention. Choose how long to keep versions — the default is one month of daily history. If you can afford the space, extend it: longer retention means a later restore point if corruption or ransomware is discovered late (section 5 explains why).
5. Create a system image and recovery media. Open Control Panel > System and Security > Backup and Restore (Windows 7) — the name is legacy, the tool is current — and choose Create a system image, pointing it at your external drive. Separately, open the Create a recovery drive wizard (search for “recovery drive”) to make a bootable USB with the tools that can restore that image. The wizard erases the USB stick you select.
6. Verify it actually ran. The read-only PowerShell check below lists the snapshot folders File History has written to your backup drive. You should see timestamped folders, with new ones appearing after each run while the drive is connected.

# Read-only: lists the snapshot folders File History has written.
# Replace E: with the letter of your backup drive.
Get-ChildItem 'E:\WindowsFileHistory' -Directory -Recurse -Depth 1 |
  Where-Object { $_.Name -match '^\d{4}-\d{2}-\d{2}' } |
  Sort-Object LastWriteTime -Descending |
  Select-Object -First 5 FullName, LastWriteTime

Before major Windows updates, repeat steps 5’s image creation (or at minimum confirm File History has run that day) — an update that fails halfway is exactly the scenario the image layer exists for, and section 13 covers what to do when it happens. The same two-layer pattern — files continuously, system periodically — is what you will replicate on macOS and Linux in the next two sections.

Time Machine is the closest thing any of the three operating systems has to a complete answer: one tool, fully automatic, covering both file-level recovery and whole-Mac restoration from the same backup. The setup takes minutes; the first run takes hours (it copies your entire startup volume), so start it when you can leave the Mac plugged in and idle.

1. Prepare the drive. Connect an external drive with headroom of at least two to three times the size of the data on your Mac. When Time Machine asks whether to use this disk, it will offer to erase and format it for macOS (APFS is the modern default). Erase removes everything currently on that drive — confirm nothing you need lives there first.
2. Enable Time Machine. On Ventura and later: System Settings > General > Time Machine > Add Backup Disk, then select the drive. On Monterey and earlier: System Preferences > Time Machine > Select Backup Disk. Authorise the backup of your startup volume when prompted.
3. Let the first run finish. The initial backup is a full copy of the startup volume (system files are excluded, so it is smaller than the disk’s total capacity). Subsequent runs are incremental — hourly snapshots of what changed, with daily and weekly versions retained automatically. From then on the only requirement is that the drive is connected while you work.
4. Set exclusions. In Time Machine’s Options, add folders that are large and rebuildable: virtual machine images you can recreate, build output, download caches. Exclude deliberately — a few well-chosen exclusions keep the drive from filling up with data that was never worth backing up (section 2).
5. Restore individual files. Click the Time Machine icon in the menu bar and choose Enter Time Machine, then navigate to the file and pick the version you want — or, while a backup is running, use Finder’s right-click > “Restore [date] Version” on the current file. Restores go to the original location by default; if a newer version exists there, macOS will not silently overwrite it without asking.
6. Know the whole-Mac restore path now, not later. Boot into macOS Recovery — Apple silicon: hold the power button until “Loading boot options” appears, then choose Options; Intel Macs: restart and hold Cmd+R — and note where Restore from Time Machine Backup sits in the menu. Running it replaces the current contents of your startup volume with the backup, so you only do this when the system itself is unrecoverable (section 13 covers that decision).

Backing up a Mac without Time Machine: if you prefer not to use it (or your storage situation makes its whole-volume approach impractical), the workable alternatives are manual or scripted copies of your home directory and chosen folders to an external drive — macOS ships with rsync, so the Linux pattern from section 9 works here too — plus a cloud service for the irreplaceable subset. Two honest limitations: none of the file-copy approaches recreates a bootable system the way Time Machine’s Recovery restore does (a bootable clone requires dedicated cloning tools, and not every method produces one), and you lose the automatic hourly versioning unless you build it yourself. If your Mac is your main machine, that trade usually argues for keeping Time Machine on despite its footprint.

Limited storage? Three levers in order of preference: exclude aggressively (step 4) so the backup drive holds what matters at full version depth; move genuinely cold archives to cheaper storage and back up only the active subset; and use a cloud service for the irreplaceable core if local capacity is the binding constraint. What not to do is shrink retention everywhere to make space — that shortens your recovery window on exactly the data you cannot afford to lose.

On Linux there is no File History or Time Machine — the standard home setup is a short script built from tools every distribution ships: rsync for efficient, repeatable file copies, tar for configuration snapshots, and cron for scheduling. That is a feature, not a gap: you see exactly what runs, when it runs, and where the log says it succeeded. The sequence below is written to be run in order on any mainstream desktop distribution (Debian/Ubuntu, Fedora, Arch-based); adjust paths to match your system.

1. Prepare and mount the external drive. Connect it and note where it mounts (often automatically under /media/$USER/…, or mount it yourself at a stable path like /mnt/backup). Filesystem matters: ext4 preserves permissions, ownership and timestamps faithfully; exFAT (the cross-platform default) does not store Unix permissions, so a home-directory backup to exFAT will restore files with lost permission metadata. If this drive is Linux-only, format it ext4.
2. Dry-run the copy first. The command below previews exactly what rsync would do without writing anything. Read the output — you are looking for your real data in the list and the junk (caches, build trees) out of it.

# Preview only: -n means "dry run". Adjust the destination path to
# where your drive actually mounts.
rsync -avn --exclude='.cache' --exclude='Downloads' "$HOME/" /mnt/backup/home/

3. Run it for real. Same command without the n. From now on this is your daily backup: rsync copies only what changed, so repeat runs are fast and cheap. Keep the exclusions you validated in the dry run — add more as you spot rebuildable bulk (VM images, container volumes, project build output).
4. Snapshot your configuration. Your home directory holds your data, but a reinstall is not complete without the system settings. This tarball captures /etc — network config, service settings, user accounts — with a date in the name so you can keep several:

# One dated archive of /etc. Run as your normal user with sudo only
# if a file under /etc is not world-readable on your distribution.
sudo tar -czf "/mnt/backup/etc-$(date +%F).tar.gz" /etc

5. Schedule it with cron. Open your crontab with crontab -e and add the line below. Two cron facts that bite beginners: cron runs with a minimal environment, so use absolute paths for commands; and nothing emails you on failure by default, so the log redirect is not optional — it is how section 12’s verification works.

# crontab -e  (user crontab)
10 3 * * * /usr/bin/rsync -a --exclude=.cache --exclude=Downloads "$HOME/" /mnt/backup/home/ >> "$HOME/backup.log" 2>&1

6. Know your restore options before you need them. File-level restore is just copying back: rsync -a /mnt/backup/home/Documents/ ~/Documents/ (or a plain copy of individual files). Configuration comes back from the dated tarball. For a full system, the options are a block-level disk image with dd (exact, but demands an equal-or-larger target disk and a consistent source — ideally taken from a live system or a powered-off disk), or snapshots if your distribution uses btrfs or zfs with periodic snapshotting enabled. Each has real limitations — dd images are hardware-fragile across different machines, and snapshot availability depends entirely on which filesystem you installed — so choose deliberately rather than discovering the gap during an incident.

An unencrypted backup drive is a data leak waiting to happen — and the scenarios are mundane, not cinematic. The external drive left in a car or a suitcase that goes missing; the old backup disk sold second-hand because you ran out of storage; the cloud account reached by a stolen laptop’s cached credentials. If your backups hold tax records, medical documents, photos of identifiable people or business data, anyone who physically possesses the media can read all of it unless encryption stands in the way. Encryption at rest changes the threat model from “whoever gets the drive gets my life” to “whoever gets the drive and the key gets my life” — which is why the second half of this section is about the key, not the cipher.

The built-in options map cleanly onto the three operating systems. Windows: BitLocker can encrypt an external drive (right-click the drive in File Explorer > Turn on BitLocker) on Pro and Enterprise editions; Windows Home does not offer full-disk BitLocker for data volumes, so file-level encryption or a third-party encrypted volume is the route there. System-volume device encryption is automatic on many modern consumer PCs — check Settings > Privacy & security > Device encryption and make sure you know where its recovery key is stored. macOS: FileVault encrypts the startup volume (System Settings > Privacy & Security > FileVault); for an external backup drive, create an encrypted APFS volume or use an encrypted disk image so the Time Machine or manual copies land on ciphertext. Linux: LUKS full-disk encryption is normally configured at install time (or with cryptsetup on a spare disk), and for archive-style backups, GPG symmetric encryption gives you a portable encrypted file that any machine with the password can open.

# Encrypt a tar stream of Documents into an .gpg archive.
# You will be asked for (and to repeat) a passphrase - it is not shown.
tar -czf - "$HOME/Documents" | gpg --batch --yes --symmetric \
  --cipher-algo AES256 -o "/mnt/backup/Documents-$(date +%F).tar.gz.gpg"

# Decrypt and list the contents to verify readability:
gpg --decrypt "/mnt/backup/Documents-$(date +%F).tar.gz.gpg" | tar -tz | head

Now the part that decides whether encryption protects you or imprisons you: key management is the whole game. A recovery key or passphrase that you lose makes the data permanently unreadable — no provider, no tool and no support line can recover it, because well-designed encryption means there is nothing left to recover from. So: store BitLocker/FileVault/LUKS keys and backup passphrases somewhere separate from the encrypted media (a password manager entry plus a written copy in a safe or fire-safe beats a sticky note on the drive); never write keys into backup scripts, logs or the plan document itself; and test decryption deliberately at least once per year, because a passphrase you have not typed in two years is a passphrase you may no longer remember correctly. The checklist in section 16 has a standing item for this.

Ransomware changes what a backup must survive. The attack pattern is consistent: malware gets onto your machine (phishing, a malicious download, an exploited update), then encrypts every file it can reach with the credentials that machine holds — which includes network shares and any external drive that is mounted at the moment of infection. An always-connected backup drive is not safe during an active infection; it is simply the next folder in the list. This is why “I have a backup” can still end in total loss: both copies were reachable from the same compromised account, so both got encrypted. The defenses below are layered on top of phase 2 — they do not replace your daily backups, they make sure at least one copy survives the specific failure mode of a live infection.

The first and most effective layer is a copy the infected machine cannot reach. That means either physically disconnected (an offline drive you rotate in weekly or monthly — when it is unplugged, it is definitionally out of reach) or off-site with version history (a cloud backup service that retains older versions lets you restore the state from before the infection started, even if the newest copy is encrypted). The second layer is versioning on the copies that are reachable: File History’s hourly versions, Time Machine’s snapshots and cloud version history all give you a timeline to step back along when you discover the encryption days late rather than minutes late. Where your storage or provider supports immutability (write-once retention windows), use it — a copy that cannot be modified for 30 days cannot be encrypted by anything inside that window. The third layer is credential hygiene: run daily work under a standard (non-administrator) account so malware starts with limited reach, and do not reuse your main cloud password as the credential stored on the PC for backup sync — separate credentials mean an infected machine cannot simply log into the off-site copy. Finally, keep the recovery media and the written plan from section 14 offline: a bootable restore stick and a runbook in a drawer are not reachable by any process running on your desktop.

When an infection is discovered, the order of actions matters more than the speed of them. Disconnect the machine from the network immediately (network cable out, Wi-Fi off) so the malware cannot reach the NAS or cloud sync before you think; do not reboot in a panic and do not run disk-cleaning tools, which can destroy both evidence and recoverable state. Then identify your last clean point in time from the version history of one of your copies — check file dates around when things started behaving wrong. And make the restore decision deliberately: if the machine itself is still infected, restoring files onto it re-exposes them to the same malware, so the correct sequence is a clean operating system first (reinstall or restore from a pre-infection image), then your files from the verified-clean copy. Paying a ransom is not a recovery strategy this tutorial will discuss — it does not guarantee decryption, it guarantees payment, and a working offline copy makes the question moot.

This is the section that separates a plan from a hope, and it costs about fifteen minutes per month. Backup tools fail in unglamorous ways: the external drive was unplugged before the scheduled run, the cloud quota filled up silently, a firmware update changed a drive letter, a permission on one folder stopped matching. None of these produce an alarm — they produce a backup that simply does not exist on the day you need it. The only evidence that a backup works is data read back from it, which is why verification here means two distinct things: confirming the runs actually happened, and performing real restores.

The restore test itself follows one rule: never restore over the original during a test. Restore to a temporary folder (or, for whole-system tests, to spare hardware) so a bad backup cannot destroy the good data while you are checking it. On Windows, use File History’s “Restore personal files” view and restore into a scratch directory; on macOS, browse the snapshot in Time Machine and restore to a different location; on Linux, a checksum comparison is the fastest honest test because it proves content identity without touching either copy:

# Both hashes must be identical. Adjust the paths to your real file
# and its backup location. (macOS: use "shasum -a 256" instead.)
sha256sum "$HOME/Documents/report.pdf" \
          "/mnt/backup/home/Documents/report.pdf"

Set a cadence and keep a paper trail: a ten-minute monthly check of run status plus a deeper quarterly test (older-version restore, boot the recovery media, decrypt one file), and an immediate verification after any change that touches the setup — new drive letter, OS update, moved house, replaced machine. Write the date and result of each test in the plan document from section 14. That dated record is not bureaucracy: it is your documented recovery time, and it is what lets you answer “when did we last prove this works?” with a date instead of a shrug.

Recovery decisions made in a panic follow a predictable pattern: the wrong tool reaches for the most dramatic fix, destructive operations run before the backup is confirmed good, and the remaining copies get endangered by well-meant fumbling. The antidote is deciding the first action now, while calm, for each scenario you are likely to meet. The table below is that decision set — note its consistent shape: identify what failed, protect the copies you still have, then restore from a verified-clean point.

Two cross-cutting rules cover most of the table’s rows. First, confirm the backup before any destructive restore: restoring an entire disk from a bad image is worse than the original failure, because you now have to recover from both. A five-minute check that the image or version you are about to use exists and is recent (section 12’s criteria) prevents the worst version of every scenario above. Second, replace hardware with equal-or-better specs and matching interfaces — an NVMe system disk comes back as NVMe, a SATA drive as SATA — because image restores are most fragile across hardware changes, and a matching replacement keeps the recovery path short.

A disaster recovery plan (DRP) is the written runbook for the worst day: it converts “what would I do?” into steps that can be followed while you are stressed, tired and possibly working from a phone. Its contents are short but specific, and every item must be a physical thing with a location, not a concept: (1) the inventory — what matters on each machine and where its backups live, from section 2; (2) emergency credentials — BitLocker/FileVault/LUKS recovery keys, cloud backup account details, your Microsoft/Apple/Linux account recovery options, stored offline in a safe or fire-safe and listed in the plan by location only, never by value; (3) recovery media — where the bootable USB(s) live and which machine each one belongs to; (4) hardware notes — machine model, disk interface and size, so a replacement can be bought in a store rather than researched at 2 a.m.; and (5) the scenario table from section 13, printed or saved offline, because the internet is exactly what may not be available.

The second half of a DRP is the part most plans skip: drills. A plan that has never been executed is fiction — the USB is in a drawer that has since been reorganised, the key location refers to a safe that moved house, the recovery menu looks nothing like the memory of it. Schedule a thirty-minute quarterly drill with a fixed shape: restore one real file from the backup and open it; boot the recovery media once a year; check the off-site copy’s newest date; re-read the plan end to end. Update the document after every change that touches it — new drive, new account, new machine in the household, move. A DRP is a living document with a maintenance schedule, for the same reason the backups themselves have one: both rot silently.

Finally, design the plan for the reader who will actually use it under pressure, which may not be you. If a family member inherits the job of recovering your machine after a theft or a hospital visit, they need the plan to work without your commentary: absolute locations for every artefact, no step that assumes knowledge of why, and the scenario table in plain language. Test this honestly with the section 12 criterion — hand it to someone else and watch them find everything it references. The end state of phase 4 is not a document but a property: anyone who reads this plan can recover this household’s data without calling anyone. That property, verified quarterly, is what the rest of this tutorial was building toward.

The planner below assembles a written proposal from your own selections: which operating system you run, what data you need to protect, where copies will live, and how often. It is a decision aid that runs entirely in your browser — it does not perform backups, scan drives or touch any account, and nothing you select leaves this page. Treat its output as a first draft of the plan document from section 14, then refine it by hand.

Everything in this tutorial compressed into fifteen tickable items, grouped by phase. Tick them as you complete each one on each machine — the progress is saved in this browser only, and nothing about your setup is sent anywhere. The checklist is deliberately redundant with the sections: that is the point. On the day a drive fails, you want a list you can execute without re-reading sixteen sections.

The distance between a working backup and a failed one is rarely the technology — File History, Time Machine and rsync are all mature tools. It is the unglamorous discipline around them: copies on different physical devices, at least one of them out of reach of an infected machine; schedules that match how fast your data actually changes; encryption whose key you can find; and, above all, a restore performed recently enough to trust. Do the setup pass once, then let the monthly ten-minute check and the quarterly drill carry the load — they are cheap precisely because the hard decisions were made in phase 1, while everything was still calm. When one of this tutorial’s companion articles is published, it will take one row of the series roadmap in section 1 and go deep on it; until then, the sections above are the working version of each.

References

• Use Time Machine to back up your Mac — Apple Support · the official reference for configuring Time Machine, managing backup disks and restoring from a Time Machine backup.
• Manage File History — Microsoft Learn · Microsoft’s documentation for File History behaviour, configuration and policy on Windows 10/11.
• rsync project site · the canonical documentation and man pages for the file-transfer tool used in section 9, including the full flag reference behind every command shown here.
• crontab(5) — Linux man-pages · the schedule format used in section 9’s cron entry, including environment and path behaviour.