The Backup That Had Not Run for Three Weeks

On the day I renamed the folder where a lot of my work lived, I was looking at one saved copy of the system. It was dated April 2 and labeled initial. The copy was supposed to be made every Sunday at 4 a.m. Instead, it was the only one.

That was when I realized a weekly backup had not been running for three weeks.

A backup is simply a spare copy of important work, kept somewhere else so a mistake, broken computer, or lost file does not become a disaster. I had thought this one was being made automatically. The schedule still existed. The old setup was still sitting there. Everything looked settled from a distance.

Earlier that day, I had been doing what I expected to be boring cleanup. One large work folder had been split into five smaller ones, each with a clearer job. One held the routines and instructions. Another held private notes and drafts. Another held material meant for the public. A fourth held original source material that should not be edited. The old setup was frozen in place, like a box of receipts you keep because you may need to understand how something used to work.

I started by changing 43 files that still pointed to the old folder address. That part went fine. But it did not solve the problem I thought I was solving. I assumed that once the addresses inside the folder were fixed, the surrounding routine would be fine too. It was not. The day I thought I was spending on a rename became an audit of things that had been quietly left behind.

The first clue was six cron entries. A cron is just a list of small jobs a computer has been told to do at certain times. There were also seven programs set to start automatically when the computer turned on, two leftover helper programs, and one retired database program. Some still referred to the old folder. Others belonged to older projects that had simply outlived anyone paying attention to them.

The backup was the part that made my stomach drop. It had not been sending a loud warning. It had been trying to run and writing an error into a log nobody read. From the outside, it still looked scheduled. From the inside, it had stopped doing the one thing it existed to do.

A second routine had been collecting no useful information every 30 minutes for weeks. It depended on another program that had not been restarted after the computer rebooted. Again, there was no dramatic failure. There was only a small message, repeated over and over, in a place nobody was checking.

That is the uncomfortable part. A thing can be broken without looking broken. A calendar reminder can still be on the calendar. A store’s security camera can still have a green light. A scheduled payment can still appear in an app. None of those signs prove the job itself happened.

The cost here was a day I expected to spend moving folders, plus the risk that important work had not been protected for three weeks. There was also the ordinary, expensive cost of false comfort. I did not have to panic because something obviously failed. I had to notice that something I trusted had never actually been checked.

Once the old pieces were cleared out, I made a small checker to look through the project folders and list what was still active, what was paused, and what had been deliberately put away. On its first pass, it found 23 projects: 10 active, 2 for clients, 7 dormant, and 4 frozen. More important, it called out any project that was missing from the list instead of silently skipping it.

That last detail matters. A forgotten thing does not become safer because it is absent from the report. Putting it in a separate “needs a decision” pile forces an honest choice. Keep it, restart it, archive it, or remove the pieces that are still running. Two half-finished projects turned up with old startup instructions still pointing at them. They were not part of the folder move. They were separate reminders that unfinished work can keep taking up space long after attention has moved on.

You do not need a wall of computer commands to recognize this pattern. You may have a paper filing system, a shared drive, a payroll reminder, a spare key, a sprinkler timer, or a business phone line. The question is the same: when did someone last check that it actually did the job, rather than checking that it still looked like it was set up?

On Monday, pick one thing you count on happening automatically and ask for the last successful proof, with a date. Not the schedule. Not the settings page. The proof. If nobody can show it to you, you have found the next thing worth checking.

dxdev LESSON · paste into your AI coding agent
LESSON: A schedule existing is not evidence a job ran; only a dated proof of the last success is
SOURCE: dxdev.com/blog/2026-04-23_backup-that-had-not-run-for-three
WHAT HAPPENED: While renaming a work folder and updating 43 file paths that pointed into it, a stale backup copy dated three weeks earlier turned out to be the only one that existed, even though the backup was scheduled weekly. It had been trying to run and failing quietly into a log nobody monitored, because it depended on a path that had been orphaned. The same afternoon surfaced six stale cron entries, seven autostart programs, two leftover helper processes, one retired database program, and a second monitoring routine that had collected nothing for weeks because a dependency never restarted after a reboot. The fix was a small checker script that classified every project folder as active, dormant, or frozen, and explicitly flagged anything it could not classify instead of silently skipping it.
THE RULE: A schedule existing, or a setup still looking configured, is not evidence a job actually ran; the only real evidence is a dated proof of its last successful execution, and a failure that writes quietly to an unread log is functionally the same as having no safeguard at all.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Any scheduled job (backup, cron, monitor) whose health is judged by 'it is on the schedule' rather than a dated record of its last successful run.
      2. Any job whose failure path writes to a log with nobody alerted on it, instead of raising a visible, noticed failure.
      3. Any inventory or audit process that silently skips items it cannot classify, rather than surfacing them as needing an explicit decision.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.