You have backups, but can you actually restore them?

The 3-2-1 backup strategy is a simple rule that recommends keeping at least three copies of your data, on at least two different types of media, with at least one of them in a different physical location. It has been accepted as a basic rule of information security for years, because it prevents a single event (disk failure, fire, theft, ransomware, accidental deletion) from destroying every copy at once. When we talk to companies, we often hear "we have backups." But dig a little deeper and it turns out the backup sits on the same server, was last taken months ago, or has never been test-restored. In this post we explain the 3-2-1 rule and the details that make it actually work.

What does the 3-2-1 rule mean in practice?

A backup on the second disk of the same server helps against disk failure but not against the server being compromised. An external drive in the office is unprotected against fire and theft. The rule exists to spread out these single points of risk.

Ransomware updated the rule: the immutable copy

Ransomware (malicious software that encrypts files and demands payment to unlock them) now targets not only live data but also any backups it can reach. If the backup server is connected to from the live system with write access, an attacker can use that same access to delete the backups.

That is why the rule has been extended in recent years and is often referred to as 3-2-1-1-0:

• The extra 1: At least one copy should be immutable (it can't be deleted or overwritten for a set period) or completely disconnected from the network.
• The 0: Zero errors in restore tests; in other words, it should be regularly verified that the backup actually restores.

In practice this means setting things up so the backup can't be deleted with the live system's permissions: the backup side "pulls" the data rather than the live system "pushing" it, or a retention lock is used at the storage layer.

How often, and how far back?

A backup plan starts with two questions:

1. How much data loss can you tolerate? For an e-commerce site taking orders, losing one day is a serious problem; for a brochure site updated monthly, it isn't. This determines backup frequency.
2. How long can you afford to be down? If the portal is down for a day, dealers can't place orders. This determines how fast the restore method needs to be.

In a typical corporate setup, the database is backed up daily (more often on busy systems), files incrementally every day, and a full backup weekly. Retention depth matters too: ransomware or corrupted data is sometimes noticed weeks later. A plan that keeps only the last seven days is useless for a problem that started three weeks ago.

A backup that hasn't been test-restored isn't a backup

This is the problem we see most often. Backup jobs report "successful" every night, but the first time someone tries to restore, it turns out the file is incomplete, the encryption key is lost or the database version is incompatible.

Our recommendation:

• Every three months, fully restore a randomly chosen backup to a separate environment.
• Measure how long the restore takes and write it down.
• Keep backup encryption keys in a separate, secure place, not alongside the backups.
• Document the test result with a short record.

Backups and KVKK

Backups are a KVKK (Türkiye's Personal Data Protection Law) matter in two ways. First, the data security obligation includes taking measures against data loss and corruption; regular, tested backups are part of those measures. Second, backups contain personal data too:

• Backups should be stored encrypted; a stolen backup file has the same consequences as a stolen database.
• Access to backups should be restricted.
• The periods in your retention and destruction policy should also be considered for backups; a deleted record living on in backups for years needs its own assessment.
• If the backup is in a storage service abroad, the transfer rules apply; see cross-border data transfer.

Checklist

• The systems to back up are listed (website, database, email, file server, ERP)
• Acceptable data loss and downtime are defined for each
• At least one copy is in a different location
• At least one copy is immutable or disconnected from the network
• Backups are encrypted and keys are kept elsewhere
• Restore tests are scheduled and results are recorded
• There is a named person who is alerted when a backup fails

How we do it at Globya

For the websites and applications under our hosting and maintenance service, we keep backups in a different location, encrypted and set up so the live system can't delete them. Backup jobs are monitored and periodic restore tests are carried out. We can also plan backups together for systems on your own infrastructure, such as an ERP or accounting server; these requirements under our KVKK compliance approach are never left out of our projects and carry no extra charge.

Frequently asked questions