Blog

A backup that has never been restored is still an assumption. Files can copy successfully and remain useless because encryption keys are missing, permissions were lost, the backup is incomplete, or recovery takes longer than the system can tolerate. The real goal is recovery; backups are only one part of getting there.

Start with recovery requirements, not storage space

Different data has different value and urgency. A developer’s source repository, a Linux server configuration, customer records, and a disposable build directory should not all follow the same backup policy. Classify data before choosing tools or schedules.

Two targets make those choices practical:

• Recovery Point Objective (RPO): the maximum acceptable amount of data loss, measured in time. An RPO of four hours means a restore may lose up to four hours of recent changes.
• Recovery Time Objective (RTO): the maximum acceptable time to restore service or data after an incident.

A personal coding project may tolerate a 24-hour RPO and a few hours of recovery work. A small application database that changes throughout the day may need more frequent backups and a documented restore procedure. RPO and RTO replace vague goals such as “back up everything regularly” with a plan that can be tested.

Identify what must be recoverable

Create an inventory of the data and dependencies required to use it. For an application, that often means source code, databases, environment configuration, uploaded files, infrastructure definitions, certificates, and encryption key material. A database dump without the matching application configuration may restore successfully yet still be unusable in practice.

Do not mistake synchronization for backup. A cloud-sync folder can spread accidental deletion, corruption, or ransomware-encrypted files to every connected device. Version history may help, but it does not replace independent backups kept for a defined period.

Use the 3-2-1 principle as a baseline

The 3-2-1 rule calls for at least three copies of important data, stored on two different types of media, with one copy kept off-site. This reduces the chance that theft, hardware failure, a power event, or a local disaster destroys every copy.

For valuable or business-critical data, add an offline or immutable copy. An offline backup is disconnected when no backup task is running. An immutable backup is retained for a defined period and cannot be altered or deleted through ordinary account access. Both measures are useful against ransomware, which often tries to find and destroy accessible backups.

Immutability is not a guarantee by itself. A retention setting may offer little protection if an attacker controls the backup administrator account or the provider configuration is incorrect. Separate backup credentials, multi-factor authentication, restricted administrative access, and alerts for retention-policy changes make the setup harder to compromise.

Choose backup types deliberately

Backup methods involve trade-offs between storage use, backup speed, and restore complexity.

• Full backups copy all selected data. They are simple to restore but can require significant time and storage.
• Incremental backups save changes since the last backup of any type. They use space efficiently, but restoration may require a full backup plus several incremental sets.
• Differential backups save changes since the most recent full backup. They grow over time but usually need fewer restore steps than incremental backups.
• Snapshots capture a point-in-time view of a disk, volume, or virtual machine. They are useful for short-term rollback, but snapshots on the same storage system do not protect against total device failure.

A practical pattern for a small system is a periodic full backup, frequent incremental backups, and a separate off-site copy. The right schedule depends on the RPO, how quickly data changes, available bandwidth, and the cost of retaining older versions.

Protect backup data without making it unrecoverable

Backups often contain the most sensitive material an organization or individual has: private documents, database exports, access tokens, and configuration secrets. Encrypt backup data while it travels over networks and while it is stored on disks or remote services.

Encryption creates a critical dependency: key recovery. Keep recovery keys and passphrases separate from the backup itself in a secure, access-controlled location. For organizational keys, maintain at least two authorized people or recovery mechanisms so one unavailable employee cannot permanently block restoration. Never keep the only decryption key in the same directory, account, or device as the encrypted backup.

Apply least privilege to backup access. A service that writes backups does not necessarily need the ability to delete historical copies. Production administrators should not automatically use the same credentials that manage backup retention. Logs and alerts for failed jobs, unusual deletion activity, and authentication changes can reveal trouble before an emergency occurs.

Design backups around applications, not just files

Copying a live database file at an arbitrary moment can create an inconsistent backup. Transactions may be partly written, caches may not have been flushed, and related files may no longer match. Use database-aware backup tools or supported snapshot mechanisms that preserve consistency. Where systems use transaction logs, retain the logs needed for point-in-time recovery when the RPO calls for it.

Version control is useful for developers, but it is incomplete. A remote Git repository preserves committed source history, yet it may not include uncommitted work, build artifacts, database contents, issue-tracker data, package registries, or deployment secrets. Repository replication is one layer of a broader recovery plan.

Document the restore order

Recovery has dependencies. A short runbook should state what to restore first, where credentials are held, who can approve access, and how each component will be checked. For example:

1. Provision or repair the approved target system.
2. Restore the database to the required recovery point.
3. Restore application files and configuration using reviewed secrets.
4. Apply required permissions and service settings.
5. Start services in dependency order.
6. Validate records, application functions, logs, and monitoring before reopening access.

Keep the runbook away from the system it describes. An encrypted document in a separate controlled location, with a protected offline copy for critical environments, is far more useful than instructions stored only on a failed server.

Test restores on a schedule

Automated backup reports prove only that a job ran. They do not show whether the right files were selected, whether an archive can be decrypted, or whether the recovered system actually works. Schedule tests that reflect the importance of the data.

A lightweight test can restore a random file to an isolated folder and compare its checksum with the original. A more meaningful application test restores a database and application into an authorized staging environment, then checks user login, critical queries, background jobs, and data consistency. Keep restore tests isolated so they cannot overwrite production data or accidentally send messages to real users.

Record the actual restore time, errors encountered, backup version used, and missing dependencies. Those records turn an assumed RTO into evidence. They also expose growth trends: a plan that restored in 30 minutes last year may take several hours after the dataset grows.

Common gaps that weaken otherwise good plans

• One backup destination: one external drive or cloud account is still a single point of failure.
• No retention policy: keeping only the newest copy leaves no clean version after delayed discovery of corruption.
• Unmonitored failures: full disks, expired credentials, and network errors can silently stop protection.
• Ignored SaaS data: collaboration platforms may offer recycling bins, but their retention periods and recovery scope may not meet your needs.
• Missing device backups: laptops often contain local keys, notes, and active work that never reached central storage.

Set retention tiers based on how failures are likely to be discovered: frequent short-term versions for accidental changes, periodic longer-term copies for delayed corruption, and any legally required archives managed under an approved policy. Review storage cost, access controls, and deletion rules together rather than treating retention as a capacity setting alone.

As a first exercise, choose one noncritical project folder and back it up to a separate encrypted location. Delete a copy from a test directory, then restore it under a new path. Check file contents, timestamps, permissions where relevant, and the time required. That small test reveals the details a backup dashboard cannot show.