Cloud backup and recovery: building a cyber-resilience strategy

SECTION 1

Why cloud backup has become a cyber-resilience issue

Cloud backup means keeping copies of your data and applications on a remote infrastructure, so they remain available even when the original system fails. It was one of the very first use cases for the cloud, but its role has changed profoundly: in 2026, backup is no longer a simple insurance policy against disk failure, it is a central building block of enterprise cyber resilience, on a par with intrusion detection or identity management.

The reason is simple: attackers understood this before many defenders did. The majority of ransomware campaigns now explicitly target backup repositories, deleting snapshots, encrypting repositories, revoking access, in order to leave the victim no alternative to paying. A backup strategy designed to withstand hardware failure, but not an active adversary holding compromised administrator accounts, no longer protects much of anything.

The question put to technology leaders has therefore changed in nature: it is no longer "do you back up your data?" but "can you prove that you can restore it, within a defined window, after a major incident?". This shift in focus, from the copy to proven recovery, structures every current best practice and everything that follows in this article.

SECTION 2

Cloud backup: definition, how it works, and BaaS models

A cloud backup is a copy of files, databases, or complete systems kept on a remote infrastructure, away from the production site. Because it is physically and logically separated from the original environment, it withstands local incidents, hardware failure, disaster, human error, that doom a backup stored in the same place as the data it protects.

Frequency is calibrated to how fast the data changes: hourly snapshots, or even continuous replication, for a transactional database; daily backups for documents and configurations; weekly copies for cold archiving. Automated retention policies delete expired copies, keeping storage costs under control without manual intervention.

The type of copy matters as much as the frequency: a full backup offers the simplest restore, an incremental backup transfers only the blocks changed since the last copy, and application-consistent snapshots guarantee that databases are captured in a usable state at the exact moment of the copy.

### From homegrown scripts to managed BaaS platforms

The era of the nightly copy script to a bucket is over. The hyperscalers offer managed services, AWS Backup, Azure Backup, Google Cloud Backup and DR, that centralize policies, encryption, retention, and monitoring for all the resources in an account. Alongside them, specialized platforms such as Veeam, Rubrik, or Cohesity cover hybrid and multi-cloud environments, and add anomaly-detection and orchestrated-recovery capabilities. The Backup as a Service (BaaS) model bills by usage, protected volume, retention period, bandwidth, and removes any investment in dedicated backup infrastructure.

SECTION 3

RPO, RTO, and the 3-2-1-1-0 rule: sizing your backup strategy

Two indicators structure any serious strategy. The RPO (Recovery Point Objective) defines the maximum acceptable data loss: a one-hour RPO requires at least hourly backups. The RTO (Recovery Time Objective) sets the maximum tolerated downtime before service is restored. Both objectives are negotiated with the business, because the business is who knows what an hour of lost data or a day of downtime really costs.

### Classifying data by business criticality

Applying the same objectives to the entire information system is the first anti-pattern to avoid: it is either prohibitively expensive or dangerously insufficient. Good practice is to classify data into a few criticality levels, critical transactional, operational, regulatory archiving, then assign each class its own RPO, RTO, and budget. This classification then guides the choice of frequencies, storage classes, and recovery mechanisms. In most organizations, less than 20% of the data justifies a sub-hour RPO: concentrating the investment on that perimeter frees up budget to make everything else reliable.

The reference rule has evolved too: the classic 3-2-1 (three copies of the data, on two different media, with one copy off-site) has been extended into 3-2-1-1-0, one additional immutable or offline copy, and zero errors found during recovery tests. Those last two digits make all the difference against today's threats: without an unalterable copy and without regular verification, the first three copies can be encrypted or corrupted at the same time as production.

SECTION 4

Immutability and air gap: shielding backups from ransomware

A backup that is writable from the production network is a target, not a protection. Attackers who obtain administrative privileges systematically try to neutralize the backups before triggering the encryption of production data: it is this scenario, no longer disk failure, that modern architectures are sized for. Figures published by security vendors are unambiguous: in more than two thirds of recent attacks, backup repositories were targeted before the production systems.

### Object lock and WORM storage: making the copy unalterable

Immutability answers this threat directly. The locking features of object storage, S3 Object Lock at AWS, immutable storage at Azure and Google Cloud, enforce a WORM regime (write once, read many) that forbids any modification or deletion for a defined period, even by an administrator whose account has been compromised. This unalterable copy has become the survival standard against ransomware, and a common prerequisite of cyber insurers.

A logical air gap completes the setup: a cloud account dedicated to backups, separate credentials and directory, one-way replication flows. Systematic encryption, in transit and at rest, with keys managed separately from the data, and multi-factor authentication on backup consoles close the remaining doors. Finally, recent platforms embed AI-assisted anomaly detection that spots an unusual encryption rate in new backups: often the earliest signal of an attack in progress.

@cite:securite-cloud-defis-et-solutions

SECTION 5

Recovery: test, automate, and prove your ability to restore

Recovery is the only moment of truth in a backup strategy, and it is precisely where organizations fail. Studies of ransomware victims converge: a majority recover only part of their data despite having backups, and the gap between the estimated recovery time and the time actually observed is often measured in days. A backup that has never been restored is a hypothesis, not a guarantee.

### Automating recovery tests

The countermeasure is well known: test, regularly and automatically. Modern platforms can restore each backup into an isolated environment, boot the system, verify its application-level integrity, the database responds, the application serves requests, then tear the environment down, with no human intervention. This continuous testing turns the "zero errors" of the 3-2-1-1-0 rule into a measurable, auditable metric rather than wishful thinking, and feeds dashboards that executives and auditors can consult. Full-scale recovery exercises, game days, complement these technical tests by also training the teams, the escalation procedures, and crisis communication.

For major incidents, the clean-room practice has become standard: restore into a pristine, isolated environment, analyze the copies there to identify the clean restore point, prior to the intrusion, which often precedes the encryption by several weeks, then rebuild in stages, reintegrating validated services. Blindly restoring the most recent backup too often amounts to reinstalling the attacker's backdoor.

@cite:gestion-de-la-reponse-a-incident

SECTION 6

DORA and NIS2 compliance, and keeping backup costs under control

The European regulator has accepted that the major incident will eventually happen. The DORA regulation, applicable to the financial sector since January 2025, and the NIS2 directive, rolled out across critical sectors, require the entities concerned to prove, not merely assert, their ability to restore operations within a defined window, with tests to back it up.

### What these texts change in practice

Concretely, this means documented recovery objectives per critical service, backups logically and physically isolated from the main information system, periodic recovery tests with auditable results, and rapid notification of significant incidents. For many organizations, compliance has thus become the main budgetary driver of backup modernization, a lever to use rather than a constraint to endure.

### Optimizing costs: tiering, lifecycle policies, and egress fees

Resilience does not require runaway costs. Lifecycle policies automatically move older copies to cold storage classes that are markedly cheaper; deduplication and compression reduce the volumes transferred and stored; and egress fees must be factored in from the design stage, because a massive restore from archive storage can cost more than several years of retention. The right trade-off is made per data class, never globally.

@cite:ia-et-resilience-it

SECTION 7

The Adservio approach: proven recovery, not a promise

At Adservio, we hold that a backup is only worth as much as its tested recovery. Too many organizations schedule regular copies without ever verifying their ability to rebuild a system on the day of an incident: it is precisely this test, repeated and automated, that we place at the heart of the approach.

Our support starts with mapping the genuinely critical data and its recovery objectives, continues with implementing a 3-2-1-1-0 architecture with immutable copies, a logical air gap, and automated recovery tests, and concludes with a skills transfer to internal teams. The goal: making recovery capability a measurable, lasting property of your information system, rather than a line in a disaster recovery plan that is never exercised. This approach draws on our cloud, SRE, and observability expertise, and fits all-cloud environments as well as hybrid architectures.

FAQ

Frequently asked questions