Verifying a Backup Actually Ran: Reading Job Logs Without Assuming Silence Means Success

Chapter 1 left a ticket open: a user wants a deleted folder restored "from last night's backup." Before touching anything else, this chapter covers the one step that has to happen first — actually confirming that backup exists, ran when it was supposed to, and completed successfully. Skipping this step and simply assuming last night's backup is fine is exactly the gap Chapter 1 warned about.

Silence Is Not Proof of Success

The most dangerous assumption in backup verification is "no one complained, so it must be working." Many of the worst backup failures are completely silent: a scheduled job that stopped triggering weeks ago produces no error at all, because it simply never runs — not because it fails loudly and gets noticed. An absence of complaints is exactly what an unnoticed failure looks like from the outside, right up until someone actually needs the backup.

This is the same "evidence over guesswork" discipline `log1` built this whole subject around — verify by actually reading the record, not by assuming the record must say what you expect.

What to Actually Check

• The job's own log for the specific date needed — not "it's generally been fine," the actual completion status for the exact night in question
• The timestamp of the most recent successful run — compared against the schedule it's supposed to follow, not just "recently"
• A basic size sanity check — a backup that "completed" but is a fraction of the expected size is a red flag for a job that started failing partway through
• Whether failure notifications are actually configured and reaching someone — a common, easily overlooked gap

Common Silent-Failure Causes

• An expired or revoked credential the backup job authenticates with
• A full destination disk that silently truncates writes instead of erroring clearly
• A changed file path or drive letter that's quietly no longer included in the backup scope
• A scheduled task silently disabled or broken after an OS or software update
• An expired license or subscription for the backup software itself

Resolving Chapter 1's Ticket

Checking the fileserver backup job's own log for the specific night in question turns up exactly the code block above: the job hasn't actually completed successfully in three weeks. Failure notifications were configured and had been firing the entire time — but to an email inbox that was decommissioned during a recent email system migration, so every failure alert had been silently accumulating, unread, in a mailbox nobody was checking.

Hands-On Exercises