Backup on Work You Can Explain

Post-Crisis Review and System Hardening

Wed, 19 Aug 2026 00:00:00 -0500

After a technical crisis, do not settle for “it works again.” Record what happened, identify the protection that was missing or unclear, and test one small improvement while the evidence is still available.

A postmortem is not a confession and it is not a search for someone to blame. It is a short record that helps you make the next failure less damaging and easier to explain.

Capture the incident before memory edits it

Write the first version from your working log, file history, messages, and recovery evidence. Use five sections:

Recover a Student Mac from a Broken Setup

Thu, 30 Jul 2026 00:00:00 -0500

Test recovery before a failure, but do not erase, reinstall, or reset a working student Mac for practice. Run a non-destructive rehearsal that verifies account and FileVault responsibility, restores one disposable test artifact, clones one project to a new directory, checks the reproducible setup record, identifies device management, and records the correct macOS Recovery path.

If no setup artifact exists yet, first create the small, secret-free macOS setup record. A recovery rehearsal cannot verify documentation that exists only in memory.

Recover Linux from a Broken Setup

Thu, 30 Jul 2026 00:00:00 -0500

Prepare recovery before Linux stops booting, but do not break or reinstall a working computer for practice. Rehearse the evidence and access paths: identify the failure layer, verify backups by restoring a test file, verify recovery media and documentation, clone a project into a new location, and test the setup repository in a disposable environment.

Before treating a backup as recovery evidence, use your backup is only real if you can restore it to test one file restore and record what the test proves.

Prefer Reversible Changes

Fri, 24 Jul 2026 00:00:00 -0500

A technical change is safer when you can explain the starting state, predict the intended result, and return to the starting state if the evidence does not match your prediction.

Prefer reversible changes. Inspect first, protect important work, change one thing, verify the result, and keep a clear rollback path. This method does not make every action harmless, but it limits uncertainty and makes mistakes easier to diagnose.

Reversibility is a property of the procedure

A change is not reversible merely because an Undo button exists. A reversible procedure answers six questions:

Sync, Git, and Backup Solve Different Problems

Fri, 24 Jul 2026 00:00:00 -0500

Sync, Git, and backup can all create additional copies of data, but they solve different problems. Sync keeps selected files available across locations. Git records deliberate versions of a project. Backup preserves recoverable copies for loss or damage. A reliable student system assigns each layer a specific job.

Why one extra copy is not enough

Suppose a student keeps a programming project in a synchronized folder. The folder appears on a laptop and in a cloud service. This helps when the student moves between devices. It does not answer every recovery question:

The Semester-End Technical Review

Fri, 24 Jul 2026 00:00:00 -0500

End the semester with a bounded technical review. Archive course work without losing context, restore-test important files, remove unjustified tool obligations, update setup documentation, preserve verified repetition, and select portfolio evidence carefully.

Do not begin by deleting. First identify retention rules, final submissions, source material, recovery needs, and private content.

1. Inventory each course

For every course, record:

Course:
Term:
Instructor:
Required retention:
Final submitted artifacts:
Editable source:
Data and code:
Feedback:
Environment or tool requirements:
Private or restricted material:

Confirm institutional and course rules. Some work may need to remain private, and some licensed materials may not belong in a personal archive.

Your Backup Is Only Real If You Can Restore It

Fri, 24 Jul 2026 00:00:00 -0500

A backup should answer a practical question: can you recover the needed data when the original is unavailable? The smallest useful proof is a restoration test. Restore one harmless file to a different location, open it, compare it with the source, and record what happened.

A successful backup job is not yet a successful recovery

A status message can show that a backup process ran. It does not prove that: