Server Backup and Disaster Recovery: Methods, 3-2-1 Rule, Testing

Server backup and recovery means keeping regular copies of the data on a server in separate places, and bringing the system back to working order within a defined time after a failure, attack or mistake. A good plan gives written answers to three questions: how much data loss can you tolerate, how quickly must the system come back, and when was that recovery last tried? If you have no answer to the third question, you do not have a plan, you have an assumption.

What is the difference between backup and disaster recovery?

A backup is a copy of the data. Disaster recovery is the process of using that copy to bring the service back up: which server the backup is restored to, whether the database or the application comes first, how the domain is pointed to the new address, and who makes the call.

Here is a situation we often see: a nightly database backup runs, but the server configuration, SSL certificates, environment variables, scheduled jobs and user-uploaded files are left out. The data survives, yet the site stays down for days. Writing a recovery plan is the most practical way to bring these gaps into the scope of your backups.

RPO and RTO: the two measures of a plan

Microsoft's Azure Well-Architected Framework defines these two targets as follows: RPO (Recovery Point Objective) is the maximum acceptable data loss, measured in time; RTO (Recovery Time Objective) is the maximum acceptable time to get the business running again after a disaster.

A concrete example: if the database of an online store that only takes nightly backups gets corrupted in the afternoon, that day's orders are lost. This business's actual RPO is 24 hours. If that is not acceptable, backup frequency is increased, or the database's transaction logs are archived continuously to allow point-in-time recovery.

RTO, on the other hand, is a business decision, not a technical one. Half a day may be acceptable for a corporate brochure site, while even a few hours of downtime is a serious loss for a store taking orders or a dealer portal connected to an ERP. Write targets separately for each system; giving them all the same target either wastes budget or leaves the critical system unprotected.

Which backup method should you use when?

Full, incremental and differential backups

• Full backup: a copy of everything. The simplest to restore, but it needs the most space and time.
• Incremental backup: captures only what has changed since the previous backup. Fast and space-efficient; to restore, you need the last full backup and every incremental backup after it, as a chain.
• Differential backup: captures everything that has changed since the last full backup. To restore, the last full backup and the latest differential backup are enough.

A common pattern is a full backup once a week with daily incremental backups in between. Modern tools such as restic and Borg split data into chunks and do not store repeated chunks again, so every backup restores like a full backup but takes up about as much space as an incremental one.

Does a snapshot count as a backup?

Disk snapshots from cloud providers are very useful for quick rollbacks. But they usually sit with the same provider, in the same account. If the account is compromised, or suspended because of a payment problem, the snapshots become inaccessible too. Use snapshots as your first line of defense, not as your only backup.

A separate backup for the database

Copying the files of a running database directly can produce an inconsistent backup. Use mysqldump or similar tools for MySQL and MariaDB, and pg_dump or continuous archiving for PostgreSQL. Make sure the file backup and the database backup belong to the same point in time; otherwise you end up with products that have an image but no record, or a record but a missing image.

The 3-2-1 rule and offline copies against ransomware

The 3-2-1 rule says: keep three copies of your data, on two different types of media, with one copy stored in another physical location. Two disks in the same data center can be lost together in a single event such as a fire, a flood or a power failure.

In recent years, another layer has been added to this rule. The US Cybersecurity and Infrastructure Security Agency (CISA) recommends in its ransomware guide keeping offline, encrypted backups of critical data and regularly testing them in a disaster scenario. The reason is clear: many ransomware strains search for the backups they can reach and delete or encrypt them. In practice, this means:

• The server should access the backup target with write permission only; the account on the server should not be able to delete.
• Use immutable (object-locked) storage where possible.
• At least one copy should not have a permanent network connection to the live environment.
• Encrypt backups and do not store the encryption key in the same place as the backup.

In the same guide, CISA also recommends using more than one cloud for cloud backups, in case all accounts with a single provider are affected at once.

How do you write a disaster recovery plan?

1. List and prioritize systems. Website, database, email, CRM/ERP connections, payment integration. Write an RPO and RTO for each.
2. Map dependencies. The application will not start without the database. Set a clear order, such as database first, then application, then DNS.
3. Write the restore steps at command level. Which backup is where, which key opens it, which server it is restored to? The document should be clear enough for a technical person who has never seen the system to follow.
4. Assign roles. Who declares the disaster, who informs customers, who talks to the hosting provider?
5. Keep the plan outside the system. A recovery document, access details and scripts that live inside the crashed server are useless. Microsoft also recommends that these documents stay accessible during an outage, with an offline or printed copy for the worst case.
6. Plan the return to the primary environment too. Moving back to the original environment after failing over to a backup server is a separate process; write its steps as well.

How often should you test recovery?

A backup that has not been tested is a backup you do not know will work. We recommend at least two types of test:

• Regular restore test: for example, once a month, restore a randomly chosen backup to a separate test environment. Check whether the site opens and whether recent orders are there, and note how long it took. That time is your real RTO.
• Tabletop exercise: a few times a year, the team walks through the plan step by step around a scenario (the server was encrypted by ransomware, the data center is unreachable). A missing password or an outdated step usually shows up here.

Microsoft's framework also recommends treating the plan as a living document and ideally reviewing it with the relevant teams every six months. Any architecture change, such as a new server, a new integration or a change of hosting, is also a signal to update the plan.

Automation prevents forgetting, but it does not prevent silent failure. You should get an alert when a backup job fails, and also when the backup size shrinks unexpectedly. An empty backup file can look like a successful job in the logs.

Shared hosting, VPS and cloud: who is responsible?

On shared hosting, the provider's backup is often there to protect the provider's own infrastructure; the retention period and restore conditions are written in the service agreement. Do not settle for relying on that backup; keep your own external copy as well. On a VPS or cloud server, backup is largely your responsibility or that of the team you work with: the provider protects the hardware, not your data. Our comparison of VPS, VDS and shared hosting covers these hosting types in more detail.

Backups that contain personal data are personal data too. Encrypting backups, restricting access and defining how long they are kept are also points to watch under data protection law; in Turkey, this falls under the data security obligation of KVKK, the Personal Data Protection Law.

In short: checklist

• Are RPO and RTO written down for each system?
• Are the database, files and server configuration included in the backup?
• Is at least one copy in another location and impossible to delete from the server?
• Are backups encrypted, with the key stored elsewhere?
• When was the last restore test, and how long did it take?
• Is the recovery document accessible outside the server?

If you want to review together where your infrastructure falls short on this list, take a look at our server and infrastructure service or contact us directly.