Cloud backup: the 3-2-1 rule, RPO/RTO and a copy that ransom

WebDisk Blog · category: Security · reading time: ~9 minutes

In short:- File synchronization is not a backup – it replicates damage as well. A backup copy has to be independent of the original and resistant to a single unfortunate click.- The 3-2-1 rule (three copies, two different media, one off-site) still applies; the cloud closes its hardest link – the copy outside the company.- A backup you have never test-restored is a hypothesis, not a safeguard. A restore test deserves to be planned just as seriously as the backup itself.

Data loss rarely announces its arrival in advance. A disk dies without warning, someone overwrites the only copy of a contract, and ransomware encrypts everything it can reach – including network shares. For a company this means downtime, financial losses, often also loss of reputation, and sometimes legal consequences as well. That is why backup is no longer optional – it is a foundation of IT security. On one condition: that it is done thoughtfully, and not "because we have to have something".

In this article we put that foundation in order: how backup differs from synchronization, what the 3-2-1 rule really says, how to translate the acronyms RPO and RTO into decisions the business can understand, why modern ransomware aims at backup copies first – and why a restore test is an obligation, not a good practice "for someday". We are writing for a mixed audience: both a one-person business and an IT team drawing up a contingency plan will benefit.

Synchronization is not a backup (and neither is RAID)

The most common illusion of security sounds like this: "I have everything in OneDrive/Dropbox, so I have a backup". You do not. Synchronization does exactly what its name promises: it keeps the same state everywhere. When a file is deleted, overwritten or encrypted by ransomware on one device, the change will dutifully flow to all the others. The versioning built into such services can sometimes rescue a single document, but it is not a plan for restoring a company – it does not cover systems, databases or configuration, and it has no defined procedure for returning to operation.

The same goes for RAID and local snapshots: they protect against the failure of a single disk, but not against human error, hardware theft, a fire in the server room, or an attack that reaches the entire infrastructure at once.

A backup is something different: a separate, versioned copy of the data in another location, performed automatically on a schedule, with a defined retention period and – most importantly – with a restore procedure that someone has rehearsed.

The 3-2-1 rule: three copies, two media, one off-site

The classic rule of backup planning fits into three digits: keep three copies of your data (the production one plus two backups), on two different kinds of media or systems, of which one is outside the location where the company operates. The logic is simple: each link protects against a different scenario. The second copy saves you when the first one fails; a different medium – when there is a flaw common to an entire technology; the off-site copy – in an event that destroys the whole location: a fire, flooding, theft, an attack that spreads across the local network.

It is precisely that last link that has historically been the hardest – it required carrying tapes or disks to a second location. Cloud backup closes it naturally: copies go automatically to a remote data center, without physical media and logistics, and the space grows along with your needs. For companies that care where their data physically sits, an additional argument is a cloud operating in Poland – the copy is outside the company, but still in a familiar jurisdiction.

To be fair, one thing has to be added: the cloud is one of the links of the 3-2-1 rule, not a replacement for it. A copy held only in a single cloud is still one copy.

RPO and RTO in plain language: how much you can lose and how long you can be down

Two acronyms that bring order to every conversation about backup:

RPO (Recovery Point Objective) – how much data you can lose, counting backwards from the failure. In practice RPO is the answer to the question: "how old can the last copy be and still be something we can live with?". A backup once a day means an RPO of 24 hours – in the worst case a whole working day is lost.
RTO (Recovery Time Objective) – how long the company can wait for the restore before the downtime starts to really hurt. This is the time from the decision "we are restoring" to the system working again.

Both values are set per system, not once for the whole company. A document archive will tolerate an RPO counted in days; the order database of an online store – rather in hours or minutes. Only once you have those numbers does the choice of technology begin: the frequency of copies, incremental copies (which record only the changes since the previous copy – thanks to which a frequent backup does not mean transferring everything from scratch), restore priorities.

And one thing that marketing materials rarely mention: the more ambitious the RPO and RTO, the higher the cost – of more frequent copies, more space, a faster connection. And a real RTO cannot simply be declared: a restore takes as long as the data volume and the bandwidth allow. That is why RTO is measured in tests, and not written into a presentation.

Ransomware looks for backup copies first

A modern ransomware attack rarely begins with encryption. An attacker who has gained access to the infrastructure first takes a look around – and methodically tracks down the backups. They delete them, encrypt them or quietly corrupt them, because they know that a company with a working backup will not pay the ransom. Only then do they encrypt production.

The conclusion from thousands of such incidents: a backup copy that can be deleted with the same permissions that were used to write it is not a safeguard against ransomware. What is needed is an immutable copy – written in WORM mode (write once, read many) – a lock that, for a defined period, no standard request can lift: not an attacker with a hijacked administrator account, not a fallible script, not even us on a bad day. In the world of S3 storage this is implemented by the object lock mechanism – we described it in detail in the article on S3 Object Lock (WORM).

For now it is enough to remember the principle: the backup repository should be immutable for the whole retention period, and access to it – separated from the accounts used day to day to administer production. In WebDisk Backup, copies go to our S3 object storage.

Why is object storage a good target for backup?

Since the copy is to sit outside the company, it has to physically go somewhere. Increasingly that place is object storage – an object store with an S3 interface, the standard API that practically every backup tool speaks today. It has characteristics that suit backup exceptionally well: space is bought as the need arises, without investing up front in a disk array, while versioning and object lock provide protection against overwriting and deletion.

We wrote about it at greater length in the article on Object Storage in WebDisk; the store is built on Ceph, an open data storage platform, and is available through standard S3 tools (s3cmd, aws CLI, boto3). The same store that serves applications is also a natural target for backup copies.

From a single file to disaster recovery

Cloud backup is not limited to documents. File-level copies protect selected directories on Windows, Linux and macOS systems and make it possible to recover a single file. Block-level copies cover the entire operating system together with its configuration, applications and databases – and they are the ones that open the way to disaster recovery, that is, a contingency plan for bringing IT systems back into operation.

Disaster recovery is more of a philosophy than a technology. It assumes that a failure will certainly happen – the question is not "whether?" but "when?" – so it establishes in advance which services will be started again, in what order and where. Here, cloud backup is more than just a place to keep copies: an environment restored from a block-level copy can be started as a virtual machine in the WebDisk cloud – the restored servers communicate over the same internal addresses as before the failure. A company can operate in the cloud before it rebuilds its own infrastructure. Technically, this is in fact a close cousin of migrating an environment to the cloud – except that it is carried out under pressure, which is all the more reason to rehearse it beforehand.

A restore test is an obligation, not an option

A backup that nobody has ever restored may turn out to be useless at exactly the moment when it is needed most – and by then it is too late for corrections. A green "copy completed" status says only that something was written; it does not say that you can come back from it. A minimal, repeatable test looks like this:

Choose a scenario – a single file, a database, an entire server. Test them all in turn, not only the easiest one.
Restore into an isolated environment, never into production – the test must not itself cause a failure.
Measure the time from the start to a working service. This is your real RTO – compare it with your assumptions.
Check consistency: the system starts, the database opens, the application logs users in. "The files were copied" is not enough.
Document the procedure step by step and repeat the test periodically (for example every quarter) and after every significant change to the infrastructure.

One more thing is worth adding to that list: monitoring of the backup itself. A copy that has quietly stopped running is the most insidious failure mode – everything looks fine until the day when something has to be recovered.

What does cloud backup not solve?

The physics of your connection. The first full copy and a full restore of a large environment take as long as the internet allows. Incremental copies and deduplication (storing repeated blocks only once) make day-to-day operation easier, but the contingency plan has to account for how long a full restore takes – hence the value of restoring directly in the cloud, close to the data.
A backup is not an archive. A backup serves to restore the current state; an archive – to store data for many years in line with legal requirements. They have different retention periods and different costs; confusing them leads either to gaps or to overpaying.
Immutability protects integrity, not confidentiality. A WORM copy will survive an attack, but an attacker with access can read the data. Confidentiality is the job of encryption – in transit and at rest; in WebDisk Backup copies are encrypted already at the source and remain encrypted in the store.
The cloud does not release you from the 3-2-1 rule. A copy in the cloud is one link of the chain – critical data should still have more than one backup copy.
Technology will not replace procedures. The schedule, retention, monitoring that backups actually complete and a rehearsed restore are just as important as the store itself – they are what distinguishes a backup from a pile of files.

Frequently asked questions

Is OneDrive or Dropbox enough as a company backup? No. Synchronization replicates the current state – including deletions and the effects of ransomware. Versioning in such services rescues individual files, but it will not restore a server, a database or a configuration, and it gives no guarantees about the time to return to operation.

What is the 3-2-1 backup rule? Keep three copies of your data (the production one plus two backups), on two different kinds of media or systems, of which one is outside the company's location. Each link protects against a different scenario – from the failure of a single device to an event that destroys the whole location. Cloud backup closes the last, historically hardest link: the copy outside the company.

What do RPO and RTO mean? RPO (Recovery Point Objective) tells you how much data you can lose, counting backwards from the failure – a backup once a day means an RPO of 24 hours. RTO (Recovery Time Objective) is the time from the decision "we are restoring" to the system working again. Both values are set separately for each system, and the real RTO is learned in restore tests, not in declarations.

How often should backups be made? As often as the RPO of a given system requires: if losing four hours of work is acceptable, a backup every four hours is enough; if it is not – you need more frequent incremental copies. Start from the business question "how much can we lose?", not from what the tool can do.

Can ransomware encrypt a cloud backup as well? It can try – and if the backup repository is an ordinary share accessible with full permissions from the attacked network, it sometimes succeeds. That is why the backup repository should be immutable (WORM) for the retention period and separated from everyday administrative accounts. We describe the details of the S3 object lock mechanism (Object Lock) in a separate article on the blog.

How much does cloud backup cost? Services of this kind work on a subscription model – you pay monthly for the protected devices and the space purchased, without investing in your own tape libraries or disk arrays. Current WebDisk Backup plans and prices can be found on the service page.

Where should I start if today I have no backup at all? With an inventory: what is really critical? Set the RPO and RTO for the two or three most important systems, run an automatic backup for them to a location outside the company – and in the first month carry out a restore test. One tested backup is worth more than five untested ones.

Summary

Cloud backup is not a single product but a strategy: the 3-2-1 rule sets the architecture, RPO and RTO translate it into the language of business, an immutable repository defends the copies against ransomware, and a regular restore test turns hope into a verified procedure. In this strategy the cloud closes the hardest gaps – the copy outside the company and the place where the environment can be started again after a failure.

That is exactly how we built WebDisk Backup: file-level copies of Windows, Linux and macOS systems, block-level copies of servers and virtual machines and backup of Kubernetes environments, based on solutions from Veeam, incremental and deduplicated, encrypted at the source, stored in our Object Storage – with the option of restoring an entire environment as virtual machines in the WebDisk cloud. Would you like to talk through a backup plan or a restore test in your organization? Write to us.

Cloud backup: the 3-2-1 rule, RPO/RTO and a copy that ransomware cannot delete