In the Room
Testing a backup before you need it
A backup is only as good as its last restore. How to test recovery, tell sync from versioning, catalogue a Mac, and rank tools by criteria, not names.
Pieces in this section
-
Who gets paid when a record plays
Composition against sound recording, performing rights organisations against SoundExchange, and the statutory licence that covers streaming but not podcasts.
14 minute read4 notes
-
The wiring of a room that talks back
Console buses, the telephone hybrid, mix-minus, the profanity delay, and what happened when the wiring became a network.
13 minute read3 notes
-
Loudness, and the ceiling nobody can raise
K-weighting, gating, integrated loudness, true peak, and the ten unit gap between what broadcast asks for and what streaming platforms normalise to.
14 minute read4 notes
-
Microphones, and the six inches that decide everything
Dynamic against condenser, polar patterns, proximity effect, the inverse square law, and why the room usually matters more than the microphone.
12 minute read3 notes
A backup is only proven when a file has been taken out of it and opened. Copying data to a second disk, a cloud folder or a tape proves that a copy exists, not that the copy is readable, complete or restorable. The test is a restore, performed on purpose, on a date written down in advance, with the result recorded next to the backup job.
The distinction matters because most home and small-office setups confuse three different mechanisms that all look like safety. Synchronisation keeps two locations identical at the same moment. Version history keeps earlier states of a file inside one system. A backup is a separate copy, held apart from the working machine, from which the working machine can be rebuilt. Only the third survives a deleted folder, a corrupted drive or a ransomware event that reaches the live account. A practical German-language magazine on documented digital workflows, Werkstatt Digital, treats these as separate chapters rather than one topic, which is the correct order: the mechanisms fail differently, so they are tested differently.
How do you test that a backup can be restored?
Pick a small, known set of files, ideally fewer than twenty, and write down their names, sizes and checksums before the test. Then restore them to a machine that is not the original: a spare laptop, a virtual machine, a clean user account. Restoring to the same disk that produced the backup hides path errors, permission errors and missing dependencies.
Open every restored file, not just the first one. A word-processing document opens; a photo library may open but show grey placeholders where previews should be; a mail archive may import without its attachments. Record what failed. A restore test that finds nothing wrong is usually a test that was too small.
Repeat the exercise on a schedule tied to the backup itself. A monthly restore of a handful of files, plus one full rebuild per year, catches the slow failures: a drive that has been quietly writing unreadable blocks for months, a cloud client that stopped uploading after a password change, an external disk that has been unplugged since spring. The rebuild is the only test that answers the real question, which is whether a working machine can be produced from the copy alone.
Keep the test result as a dated note. A backup log without restore dates is a claim, not a record.
What is the difference between synchronisation and an earlier version?
Synchronisation is a state, not a history. Two folders are made equal, and the equality is maintained continuously. If a file is deleted on one side, the deletion travels. If a file is overwritten with an empty document, the empty document travels. Sync is excellent for moving work between a desktop and a laptop, and it is not a backup.
Version history is a partial answer. Many sync services and operating systems keep earlier copies of a file for a limited window, often thirty days, sometimes a year, occasionally indefinitely for a fee. That window is the whole question. A file corrupted in January and noticed in April is outside a thirty-day window and inside a one-year window. The version store also usually lives inside the same account as the live file, so an account-level problem can take both.
A backup differs in three ways: it is held apart, it is dated, and it is restorable without the original system. The dated part is what allows a restore to a point before an event rather than to the most recent state. Anyone maintaining files for a small collective should be able to say, without checking, how far back the versions go, where the separate copy lives, and when it was last read.
Which criteria should come before product names when choosing a tool?
Criteria first, names second. Four properties cover most of the decision. Export: can the data leave the tool in a format another program can read, without a paid conversion step? Restore: can a single item and a whole account be brought back, and how long does that take? Protection: what happens to the data in transit and at rest, who holds the keys, and what does the provider state in writing? Maintenance: how often does the tool change, who fixes it, and what happens to the files if the vendor stops?
Write the criteria down before comparing anything. A short table with four columns and a row per candidate forces the comparison onto properties rather than reputation. Documentation and manufacturer statements belong in the table as claims, clearly marked as claims, separate from anything that was tested. A reproducible test, run twice on the same day with the same files, is worth more than a review written from memory.
This ordering also protects against switching costs. A tool chosen for its export path is easier to leave than one chosen for its interface.
Cataloguing files on a Mac
A Mac makes cataloguing easy to postpone, because Spotlight finds almost anything by content. The problem appears at restore time: search indexes are rebuilt, not restored, and a rebuilt index over a disorganised folder tree returns the same disorder.
Three habits carry most of the weight. First, a naming convention with a date in front, written as year-month-day, so that alphabetical order matches chronological order. Second, a shallow folder tree, three levels at most, with the fourth level expressed in the filename. Third, a plain-text index file per project, listing what the folder contains and what is missing, stored inside the folder so that it travels with the data.
Tags are useful and portable only inside the Apple ecosystem. A folder structure survives a move to another operating system, a network drive or an archive. For anything intended to last more than a few years, the structure is the safer carrier.
Ground rules for a browser, a second factor and a second brain
Three settings repay an hour of attention. In a browser, decide deliberately what runs by default: which extensions are allowed, which sites are exceptions, and what is cleared when the window closes. An exception list that nobody has read in a year is a list of forgotten permissions.
For a second factor, prepare for the loss of the phone before it happens. Print or store the recovery codes somewhere that is not the phone, register a second device where the service allows it, and check that the account can still be entered if the authenticator app is gone. A second factor that depends on one device is a single point of failure with better marketing.
For a second brain, meaning a personal notes system, the entry cost should be low and the exit path should be open. Plain text files in folders, with links between them, satisfy both. A test folder is the right place to learn the tools: a few notes, a few links, a version history, and a deliberate deletion to see what recovery looks like. The same folder answers the earlier question, because a notes system that cannot be restored is a diary, not a record.
The test is the documentation
A workflow is documented when someone else, or the same person a year later, can repeat it from the written steps and get the same result. That standard is modest and rarely met. It requires a date, a list of files, a result, and a note about what broke. Everything else, the drives, the subscriptions, the apps, is hardware and habit around that record.
A restore test answers whether the data comes back, not whether the machine around it still works. The same discipline applies to a site: measure first, then change. A small structure can log load times, check internal links and city pages, and verify a consultant's claims against raw figures, as set out in reading the numbers first. Both habits share one rule: evidence before repair, whether the subject is a drive or a page.