The previous chapter focused on securing your application. You also need to protect your data by creating backups. Every computer is susceptible to failure—hardware wears out over time and can break down unexpectedly.
A good chef remembers their recipes, but not all of them. A cookbook needs to be kept in a safe place so that, in case of an accident, none of the recipes are lost.
Your kitchen’s insurance policy: Why backups are essential
In everyday computer use, the average user doesn’t take precautions against failure. The risk of a disk failure is low, but not zero hard drives (HDDs) can last for years. However, when a failure does occur, you can lose everything: photos, videos, documents, passwords, programs, and more.
The only real safeguard in this situation is having a backup. You can attempt to recover data from a failed drive, and there’s a chance of retrieving accidentally deleted files, but there’s no guarantee you’ll recover everything.
Backups are especially critical in business applications, where losing even a single transaction record can be costly. A restaurant that loses its invoices will run into trouble with the tax authorities. That’s why it’s essential to back up your documents or create database snapshots.
A lesson from Pixar: When one person saves the team
In 1998, Pixar nearly lost the film Toy Story 2. During routine server cleanup, one of the employees accidentally deleted the directory containing the film and its assets. A single mistake could have cost them two years of work and the movie might never have made it to theaters. To make matters worse, no one had verified the backups; it turned out they hadn’t been working for a month and couldn’t be used. The situation was simply disastrous.
The situation was saved by a remote employee who had a local copy on her computer. It’s a clear reminder that a backup is useless if you don’t verify that it can actually be restored.
The backups had been created, but no one verified their integrity, which could have rendered a huge amount of work useless. It’s crucial to check that backups are valid and that the data can actually be restored.
The 3-2-1 rule: Three safes for one critical recipe
When building software, your most valuable assets are your source code and user data. To avoid disaster, you should follow the 3-2-1 rule in your digital kitchen:
- 3 copies of your data: the original, a copy, and a backup
- 2 different storage media: a disk and a USB drive
- 1 copy stored offsite: for example in a remote location
This approach almost guarantees data safety: if a disk fails, you have a copy close at hand; if local copies are lost, you can restore your data from a remote backup; and using different types of storage means that a failure of one won’t affect the others.
Types of backups: Full, differential, or incremental?
The simplest way to create a backup is to copy your data 1:1. It works, but it quickly takes up a lot of space. What if your data keeps growing every day? It doesn’t make sense to copy 100 GB daily if only a small amount has changed. That’s why there are three main types of backups.
Full backup
This is the simplest type of backup, but it takes up the most space. The data is saved as-is in a snapshot. Each full backup is a complete, directly restorable copy of the data. It’s like a chef writing down all their recipes at the end of each day nothing is lost, but shelf space quickly runs out.
Differential backup
As you can see, a better approach is needed for data that changes over time. One option is a differential backup, which stores all changes made since the last full backup. If a 100 GB full backup is created on Monday, only 2 GB of changes are saved on Tuesday and 4 GB on Wednesday. The Wednesday backup will also include Tuesday’s changes, since everything is compared against the last full backup.
Incremental backup
With differential backups, data ends up being duplicated across backups. As the name suggests, an incremental backup stores only the changes since the last backup. What’s the difference? You save 2 GB of data on Tuesday, and another 2 GB on Wednesday.
What’s the catch? If you lose the Tuesday backup, all subsequent backups become useless. Incremental backups are the fastest and use the least space, but they depend on every single backup in the chain.
The art of recovery: Does your backup recipe actually work?
Returning to the Toy Story 2 story, it’s worth noting that, in theory, everything had been done correctly—backups were created, and after the failure an attempt was made to use them. Even though the procedures were followed, the backup ultimately turned out to be useless. The second most important aspect of data protection had been overlooked: verifying the backups.
What’s the point of copying data if you can’t restore it? What happens if one of the incremental backups is corrupted? An administrator must verify that backups are valid. If a chef can’t read their own notes, what was the point of writing them? And if the chef is gone, no one else will be able to read them either.
You might notice that checking every single backup can be inefficient-and that’s true. If the data has been saved, there’s no need to verify it constantly. Backups should be tested after significant changes, for example in the system architecture. If you change the database-check the backup. If the directory structure changes-check the backup. It’s also a good idea to test backups periodically, such as monthly or quarterly, rather than every day. You need to strike the right balance and use common sense.
RPO and RTO: How quickly do you need to get back to serving dishes?
In professional systems and large organizations, a backup strategy is put in place. This includes planning storage for backups, setting data priorities, and defining the number and types of backups. Two key metrics are used for this: RPO (Recovery Point Objective) and RTO (Recovery Time Objective). They are used to automate the backup process.
How much data can you afford to lose over time? Recovery Point Objective
It defines how much data an organization can afford to lose. How many orders from a given day can your application lose? It all depends on the scale and importance of the data—in one system, losing 30 minutes of data may be a serious financial hit, while in another, losing a week’s worth might be acceptable. You need to decide how often backups should be created and which data should be included. You can also prioritize: for example, back up the database daily, while user photos might be backed up once a month.
How long can the system be unavailable? Recovery Time Objective
This metric answers the question: how quickly can you reopen the kitchen after a fire? In the context of backups, RTO defines the time from a failure to the system being fully operational again—in other words, how long recovery takes. You need to design your backups so that recovery stays within the target time. If your RTO is set to two hours, it means the kitchen must be cleaned up and ready within those two hours. Your backup strategy should ensure that restoring data doesn’t take too long.
Automate or perish: DevOps in the service of reliability
Every developer is lazy by nature-that’s why programming languages were invented. Creating backups is a time-consuming process; a full backup can take hours. That’s why it’s essential to automate backups so they run without human intervention. Just make sure to automate the process only after you’re confident it works correctly. Creating useless backups only wastes disk space.
RPO and RTO help determine when and what should be backed up. They should guide your automation strategy, but they’re not the whole picture. You also need to decide how many backup versions to retain, set up monitoring to ensure backups are valid, and define a backup schedule. A kitchen usually doesn’t serve customers at night, so it’s best to archive invoices, receipts, and recipes during that time, when there’s little chance the data will change.
The cloud: a pantry built to withstand disasters
One of the best places to store data is the cloud, primarily because it offers high availability. Professional services practically guarantee that your data won’t be lost, even in the event of a server failure. It’s a convenient solution where your role is simply to create a backup and upload it to a remote server.
It’s worth using incremental backups to reduce the amount of data stored and transferred.
Such services offer a serverless model-you only pay for the resources you actually use.
Servers use RAID arrays to protect data against hardware failures. Each type of array serves a different purpose, but it’s important to note that they operate at the hardware level. For example, in a RAID 1 setup, two disks mirror each other, so any data written to the system is automatically duplicated. If one disk fails, the array automatically rebuilds the data onto a replacement drive.
Store your code in a distributed version control system (e.g., Git). In a distributed setup, every developer has a full copy of the codebase, while the main server serves as the reference point. If the server is lost, the repository can be restored from any developer’s local copy.
Summary
Backups are critically important in any organization.
Data stored on computers is vulnerable to many threats: hardware failures, malware, and human error. There are many backup strategies available, so it’s worth understanding them and choosing the one that fits best.
Remember: data loss is one of the worst-case scenarios in IT.
Materials
Self-study materials that are related to this topic:
- The importance of website backups and security monitoring
- Data loss stories
- What is a backup?
- Types of backups
- Backup and recovery best practices
- AWS S3 backup guide
- Testing backups
- Docker volume backup tutorial: Nextcloud example
- S3 backup and restore using AWS Backup
- Backup: complete guide to data protection and recovery
- Data backup strategies for beginners
