3-2-1 Backups, Versioning, Checksums and Integrity Verification.

Having tracks on two drives gives you two ways to lose them at once, rather than a backup plan. Failure rarely warns you: a dropped drive, misconfigured synchronisation uploading an empty version or encryption demanding a ransom. When it does warn you, it is already too late to start planning. What separates recovery in an afternoon from months lost is a simple, tested structure with clear names.

This guide organises that structure into four pieces working together: 3-2-1 Backups for sufficiently diverse copies, Versioning to avoid overwriting earlier work, Checksums and Integrity Verification to know stored material remains intact, and Archive vs Backup so one folder does not perform two incompatible jobs.

3-2-1 Backups: Three Copies, Two Media, One Off-Site

The rule fits in one line: three copies of every important file, two different types of medium and one off-site copy. Its strength is that each link covers a failure the others do not.

• Three copies means the working original plus two up-to-date replicas. A copy existing only while the laptop is on does not count.
• Two media means physical diversity: the computer’s internal drive and an external SSD, plus a third copy on a NAS or in the cloud. If a controller or cable fails, a second drive of the same model will not save you.
• One off-site copy covers what insurance cannot return: theft, fire and flooding. It can be a drive stored in another home and updated monthly, or an encrypted cloud service.

Add three details not stated in the rule. First, make the copy automatic: memory is the worst scheduler. Second, keep the synchronisation window short: hourly synchronisation limits what you can lose; weekly synchronisation accepts losing a week. Third, keep one copy disconnected or write-protected, because the most destructive threat, an attacker encrypting files, also wipes connected copies.

Versioning: Save Changes without Deleting What Came Before

Versioning solves a different problem from copying: the drive has not failed, and the file is still there, but it is no longer the one you wanted. An overwritten bounce, a playlist exported over the previous one or a database reindexed with a wrongly pointed folder. An identical copy detects none of these: the problem is replicated.

How to do it without heavy infrastructure:

1. Name exports with a date and version number: sesion_2026-10-01_v3.wav. Never final, never final2, never nuevo_final.
2. Use operating-system or tool history for working folders: save automatic versions on an external or network drive and restore the previous version from the file browser when needed.
3. Do not overwrite during delivery. Archive the file sent to a client, label or distributor separately, frozen.
4. Separate history from current material. A read-only historial/ directory prevents synchronisation from pulling it into the active folder.

Versioning’s limit is space, so write down a retention policy, for example the last thirty days of active projects and everything delivered. Without a policy, history grows until someone empties it entirely.

Checksums: The Fingerprint Proving a File Arrived Intact

A Checksum is a number calculated from a file’s contents: change one byte, and the number changes. Storing it with the file lets you prove months later that the copy remains exactly what you exported.

In practice:

• Generate hashes when saving the copy. A list with each file’s path and SHA-256 occupies kilobytes and lives in the same folder.
• Recalculate when restoring. After copying a drive back or downloading from the cloud, compare hashes: this is the only way to know the transfer corrupted nothing.
• Use it when exchanging material. If you send stems and the recipient calculates the same hash, there is no argument about who broke what.
• Archive the list with the project. A lost hash provides no protection: keep it in the same digital envelope as the files.

This is the same logic as a manufacturer’s signature verification warning that a download has changed; here, your file carries its fingerprint.

Integrity Verification: Test the Copy before You Need It

Integrity Verification checks that the copy is readable, complete and consistent with the source, rather than merely present. It requires a different discipline from creating backups: you have to look inside.

What to check and how often:

• Automatic backup-manager checks. Backup software and NAS systems can verify data and indexes; if bad sectors or inconsistencies are found, the task changes to restore-only mode and alerts you. Schedule the check rather than running it manually.
• A real test restoration. Choose a random project, restore it elsewhere and open it: the DAW should load samples, stems should play and the database should retain cues and beatgrids. A folder you cannot open is not backed up.
• Reconciliation with the source. Compare file count, total size and the latest copy’s date with the original. Differences rarely explain themselves.
• Media monitoring. Drives warn with errors before dying: read status reports and replace drives with increasing reallocated sectors.

The technical reference for backup integrity checks emphasises two stages, data and index structure, and resolving a detected fault before continuing to write. In a studio, that makes verification part of monthly maintenance alongside contact cleaning and folder reviews.

Archive vs Backup: Two Words with Different Meanings

A Backup exists to go back: recent, rotated, always updated copies designed to restore what was lost. An Archive exists to preserve completed pieces unchanged five years later, with different retention, checking frequency and destination.

Confusing them creates two typical failures. First: using only archival storage and discovering that the sole copy of the current project is three weeks old. Second: rotating an archive as though it were a backup and deleting the release’s only master recording along with old versions.

Recommended allocation for a catalogue:

• Current projects and library: working drive, NAS and cloud, with automatic copying hourly or daily.
• Delivered masters, stems and documentation: external drive and read-only cloud storage; add them when work closes and never overwrite them.
• DJ software database: lives alongside the library with its own plan, and is exported after every preparation session.

If your backup plan includes libraries managed in DJ software, full folder and database allocation is already covered in the guide to library backups with the 3-2-1 rule. Published material and remasters are covered in record catalogue management.

A Plan That Fits into Your Week

• Monday: define the inventory, the folders you cannot lose, and the retention policy. Without an inventory, every plan has too much or too little.
• Tuesday: set up the first automatic copy to the NAS or external drive, and the second to encrypted cloud storage.
• Wednesday: generate the copy’s hash list and save the last verification date in a notes file.
• Thursday: configure version history for working folders and date-name loose material at the root.
• Friday: test-restore a project and the database; note how long it took, because that is your real recovery time.
• Month-end: review drive reports, run scheduled automatic verification and rotate the offline copy.

The result is a system whose recovery time you know and whose last test has a date, rather than a perfect system.

Next Step

Knowing copies exist and work raises the next question: where should they live? SSD, HDD, NAS, Cloud and Ransomware: Choosing Where Your Files Live.