A practical 3-2-1 backup strategy for small workshops

A backup is useful only if it survives the event that destroys the original and can be restored when the business needs it. The 3-2-1 rule is a simple way to design that resilience without requiring enterprise infrastructure.

What 3-2-1 means

The traditional rule says to keep at least three copies of important data, on two different types of storage, with one copy stored off-site. The original working data counts as one copy. A local backup provides fast recovery. An off-site or otherwise isolated copy protects against events that affect the whole premises or storage system.

The wording is less important than the failure independence. Two files on the same physical disk are not two meaningful backup copies. Two folders inside the same NAS pool may also fail together. The goal is to avoid a single hardware fault, mistaken deletion, malware incident or building-level event destroying every copy.

Identify what the workshop cannot easily recreate

Start with business data rather than devices. Customer records, repair history, status notes, invoices, configuration, custom templates and unique photos may be irreplaceable. Application installers can usually be downloaded again; years of repair records cannot.

For DBRepairs, the database is the most obvious asset, but configuration and company branding may matter too. If other services run on the same server, list their databases, compose files, secrets and persistent datasets separately.

Copy one: the live system

The live SQLite database on a desktop or PostgreSQL dataset on a server is the production copy. It should sit on reliable storage with normal filesystem protections, but RAID or mirrored disks do not turn it into a backup. RAID improves availability after some hardware failures; it does not protect against accidental deletion or application-level corruption.

Copy two: fast local recovery

A local backup should be easy to restore. For a desktop application that might be a scheduled copy to another physical drive. For PostgreSQL it may be a daily logical dump written to a separate backup dataset. Keeping several generations is important because the newest backup could already contain an unnoticed problem.

Retention should match how quickly mistakes are discovered. A practical small-business scheme might keep daily backups for two weeks, weekly backups for several months and selected monthly archives longer. The exact numbers depend on storage capacity and legal or operational requirements.

Copy three: off-site or isolated

The third copy should not depend on the same machine, room and credentials as the live system. Options include an encrypted cloud backup, a removable drive stored elsewhere, replication to another location, or a second server that cannot be casually modified by the production account.

Isolation matters because ransomware and compromised administrator credentials can encrypt or delete network-accessible backups. An immutable or offline copy provides a stronger recovery point than another continuously mounted writable share.

Application-aware backups

Copying files blindly is not always enough. Databases may have in-flight transactions or additional write-ahead-log files. Use the application’s backup function or the database engine’s supported tools whenever possible. DBRepairs desktop can create a consistent SQLite backup, while the server edition uses PostgreSQL dump tooling.

Portable .dbrepairs archives serve a different purpose: moving application data between SQLite and PostgreSQL editions. Native database backups remain the best choice for disaster recovery on the same engine.

Restore testing is part of the backup

A green “backup completed” message proves only that a job wrote a file. It does not prove the file contains the expected data, can be read, or can be restored into a working application. Periodically perform a test restore into a safe temporary environment.

Record the restore steps while they are fresh. During a real outage, a short runbook with filenames, commands, credentials location and validation checks saves time and reduces stress.

What to verify after restore

• The application starts without schema or migration errors.
• Recent customers and repairs are present.
• Status history and configuration are intact.
• Attachments or logos expected outside the database are also available.
• A new record can be created and saved.
• A fresh backup can be produced from the restored system.

Protect the backup credentials

Off-site backups are sensitive because they may contain customer information. Encrypt them in transit and at rest, restrict access to the minimum required accounts, and avoid storing backup credentials in public repositories or unprotected scripts.

A small workshop does not need a complicated enterprise platform to have good backups. It needs multiple independent copies, sensible retention, one isolated location and a habit of testing restores. The discipline is more important than the brand of storage device.