---
title: "Moving a Repository Turned Up a Backup That Had Not Run in Three Weeks"
canonical: https://dxdev.com/blog/2026-04-23_three-weeks-and-a-check-mark/
datePublished: 2026-04-23
---
# Three Weeks and a Check Mark

The backup repository held exactly one snapshot, tagged as the initial one and three weeks old, while the scheduled job meant to refresh it sat on the timer list looking perfectly healthy. The listing said the copy existed, but only opening the repository showed that the newest thing in it predated everything I had changed since.

I had been moving a repository, which is just a folder where a project keeps its working files. I expected the job to be ordinary cleanup: move the files, update the old address, and make sure the project still worked. It was supposed to be a tidy bit of maintenance.

Then I found the backup. Or rather, I found the most recent copy of it. It was much older than the schedule called for. The entry that was meant to make the backup still existed. It even looked as if it was set up correctly. But the thing it was supposed to produce, a recent copy that could be used to recover work, was not there.

That difference matters more than it sounds. A checked box can tell you that a task is listed. It cannot tell you that the task did the useful thing.

The first thing I tried was the simple version of the move. I treated it like a search problem. Find every file that mentioned the old location, change those references, and move on. The written plan I was working from said the same thing: patch the files inside the folder, dump the database, rename. That did not work because not everything connected to a project lives inside the project folder. The plan never mentioned the service files outside it, and I only found them when I checked the machine instead of the plan. Some of it lives outside, where it was set up little by little and then became easy to forget.

That wrong first pass cost time. What should have been a straightforward cleanup became a longer walk through the parts of the system that sat around the project: timed jobs, service settings, old pieces of software, deployment settings, and other old references. The important part is that old software and old instructions can keep pointing to a place you thought you had left behind.

I started making a list before changing anything. What was scheduled to run? What was turned on? What was still connected to the old location? What was supposed to come out the other end? There were retired bits of software with no clear purpose. There were scheduled jobs that still pointed at the old place. Some had not failed in a way anyone would notice because they had not yet been asked to start again.

That last part is easy to miss. Something can be marked active and still be waiting for the moment it breaks. A light switch can be in the on position even when the bulb has burned out. Until someone needs the light, the switch can look reassuring.

The backup was the most serious example, but it was not alone. A second timed job kept being called on schedule while something it needed was unavailable. Instead of producing the expected result, it made repeated errors in a log that nobody was being alerted to or checking regularly. The system was doing the motion of the job without delivering the result of the job.

The scary word here is a scheduler. It simply means a clock that tells a task when to run. A clock can ring on time and still fail to get the laundry washed. What mattered was not whether the clock rang. What mattered was whether there was a clean basket at the end.

I had assumed that a recent recovery copy existed. That assumption was the real problem. The plan listed the backup job as something to carry over with its paths updated, on the grounds that backups always matter, and I had not looked at what it produced. When I finally did, the backup repository held one snapshot, dated three weeks earlier and tagged as the initial one. A backup is not useful because it was planned. It is useful when it is recent, complete, and can actually help after something goes wrong. Without checking the copy itself, I was trusting a promise made by a setting.

The move turned out to be useful for a reason I had not expected. Changing the ground underneath a project forced me to look at everything standing on that ground. I had to trace the old location through every connection I could find. That is slower than changing a few lines of text, but it is also a rare chance to notice the things that have been quietly aging in a corner.

I did not solve this by trusting a prettier status page. The better question was simple: what would success look like if I had to use it today? For the backup, that meant a recent copy and a controlled restore test. A restore test means using a copy in a safe setting to see whether it can actually bring work back. For the other timed work, it meant checking for the thing each job was meant to produce, not just checking whether it had been invoked.

The list also needed owners and a response plan. Someone needs to know what to check, how often to check it, and what to do when the result is missing. It also needs to be handled carefully. An inventory is useful, but it is not a reason to copy passwords or identity files into an unprotected document.

I began the move thinking I was relocating a folder. Instead, I found a small pile of old promises: jobs that were still listed, services that were still enabled, and a backup that had not been doing its one important job for three weeks.

The backup repository held exactly one snapshot, tagged as the initial one and dated three weeks back, while the job that was supposed to refresh it kept its place on the schedule and looked perfectly healthy the whole time. That single snapshot is the whole lesson of this move: the listing said the copy existed, and only opening the repository showed that the newest thing in it was older than everything I had changed since. Until I ran a restore from that copy in a safe place and saw my own recent work come back, the honest status of that backup was not "active." It was "unproven."