Naming & folders · How we test and maintain this guide
A backup needs a recoverable version
A completed download is one local copy. A second folder on the same disk is another location, but it still depends on that disk. A synchronised folder may propagate changes and deletions according to the service's settings. Decide what failure you are trying to recover from before assuming that an icon or a second path solves it.
For a music project, the recoverable set often includes source exports, CSV and JSON records, working edits, a source-to-delivery map and relevant permission evidence. Not all of those files should be shared with the same people. Keep the recovery plan separate from a public delivery folder that intentionally contains only the final tracks.
A modest test we can actually report
| Local experiment | Observed result |
|---|---|
| Tagged self-generated MP3 | 2,401,323 bytes |
| Copy restored to a different local filename | 2,401,323 bytes |
| SHA-256 comparison | Exact match |
| Complete decode and duration | Readable; 120 seconds |
| External cloud service | Not exercised |
We copied a tagged test file and independently read and decoded the restored copy. Its complete-file hash matched the tagged source. This verifies a local copy-and-read operation for that file. It does not establish protection against disk failure, recovery of a whole library or the behaviour of any remote storage provider.
The limited claim is deliberate. A restore test should describe where the restored bytes came from, which files were checked and what remained outside the test. If you later test a cloud version, record that actual source and the recovery date rather than reusing a local-copy result as proof.
Restore into a clean checking folder
- Identify the version you intend to protect and retain its manifest or an independent inventory.
- Place a copy in the backup destination you control. Wait for that destination's own completion status where relevant.
- Retrieve a representative file from the backup into a new checking folder, without overwriting the active working copy.
- Compare file size and SHA-256 with the matching protected version. Do not compare a later tagged edit with an older source hash.
- Open the restored file and verify the intended recording, duration and playback. For archives, extract and check the included records as well.
Include more than the easiest file when a collection contains different formats, long filenames or non-Latin characters. A successful restore of one small MP3 cannot prove every WAV, ZIP or project file is recoverable. Choose a sample that represents the differences that matter, and keep a list of what you actually checked.
If an archive is your protected unit, verify the archive can be opened and compare selected audio entries against the CSV inside it. An intact CSV by itself is not a backup of the songs. Likewise, an extracted audio folder without source records can be playable while leaving you unable to identify takes or reconstruct selection decisions later.
Keep version changes understandable
After metadata edits or conversion, record a new working version. In the filing experiment, tags changed the complete-file hash even though decoded audio stayed the same. A restore of the older file might therefore be technically successful while still missing the newer tags. Recovery needs the right version, not merely some file with the right title.
Before retiring old backups, verify that the replacement contains the files and records you need. Avoid cleaning both active and backup locations in the same unreviewed operation. If your storage service offers version history or recovery controls, read its current documentation and test the specific recovery path you plan to rely on; this guide does not assert a universal retention period.
For cloud sharing, review access to music, source URLs and rights documents separately. A backup need not be a public link. A permission record may contain personal contact details that do not belong in a listener's download. Keep sensitive supporting material in a restricted location and include only appropriate references in a general project inventory.
A short restore log can be enough: date, protected version, source location, files checked, comparison result and any unresolved problem. The useful outcome is evidence that you can retrieve and use the required files, with a clear limit on what the test covered.