Protecting data in the cloud takes more than copying files on a schedule. Companies running workloads on AWS, Azure, or GCP need a real backup and disaster recovery strategy, with clear recovery time targets and regular restore testing. This guide covers the current fundamentals, from the 3-2-1-1-0 rule to LGPD requirements for Brazilian operations.
What the 3-2-1 rule is (and why it became 3-2-1-1-0)
The 3-2-1 rule has been around for years: keep 3 copies of your data, on 2 different types of media, with 1 copy offsite. It is a solid starting point, but the threat landscape has changed.
Today, the security and resilience community treats the 3-2-1-1-0 model as the practical baseline. It adds two elements to the original rule:
- One immutable or air-gapped copy, which cannot be altered or deleted even by an attacker with administrative access.
- Zero errors in restore testing, meaning confirmed proof that the backup actually works when it is needed.
This evolution exists because backups that stay permanently connected to the production network can be hit by the same attack that compromises the original systems. An immutable copy breaks that chain.
RTO and RPO: setting targets by criticality
Two metrics guide any continuity strategy:
- RPO (Recovery Point Objective): how much data loss the business can tolerate. An RPO of 4 hours means the last valid backup cannot be older than 4 hours.
- RTO (Recovery Time Objective): how long a system can stay down before it must be back online.
A common mistake is setting these targets based on whatever backup tool is easiest to configure, rather than on actual business impact. Google Cloud's Architecture Center recommends the opposite order: first assess the impact of each system going down (financial, operational, reputational), and only then choose a recovery pattern (cold, warm, or hot) based on budget and criticality.
In practice, an e-commerce system generating direct revenue may need an RTO measured in minutes, while an internal reporting system might tolerate a full day of downtime. Setting these targets per system avoids overspending where it is not needed and underspending where it matters most.
Restore testing: the most overlooked step
Having a backup is not the same as being able to restore it. Many companies discover gaps in their backups at the exact moment they need them most.
NIST SP 800-53 Rev. 5, in its Contingency Planning control family, is explicit about this. Control CP-9(1) requires periodic testing of backup reliability and integrity, and CP-9(2) requires restoring samples of backup data as part of contingency testing. ISO/IEC 27001:2022, in Annex A control 8.13 (Information Backup), follows the same logic: the backup policy must be tested regularly, with verification before the backup process itself, and coverage must extend to cloud data that is not directly managed in-house.
A solid restore testing routine includes:
- Restoring data samples in an isolated environment, without touching production.
- Validating the integrity of restored files, not just confirming the backup exists.
- Documenting the actual restore time and comparing it against the defined RTO.
- Repeating the test after any significant infrastructure change.
Ransomware and immutable backups: the lesson from the ISAC case
A January 2025 case illustrates why a synced backup is not the same as a secure backup. A health institute in Brasília, ISAC, suffered an attack attributed to the LockBit 4.0 group, which encrypted the organization's virtual disks and also overwrote the backups that were synced with the production environment, replacing them with empty files. The incident exposed data belonging to roughly 500,000 patients, and Brazil's data protection authority, ANPD, opened a sanctioning process in July 2026 citing the absence of adequate technical measures. It is worth noting that the process is still under review, and the case should be read as an illustration of the risk rather than a final, settled conclusion.
The practical lesson is clear: if a backup stays permanently connected and synced to the production environment, it can be hit by the same attack. That is exactly the gap the extra "1" in 3-2-1-1-0 closes, through an immutable or physically isolated copy.
Cloud providers are already responding to this risk. In 2025, AWS Backup expanded its ransomware resilience features, including logically isolated vaults that are immutable by default, customer-managed encryption keys, multi-party approval for sensitive access, integration with Amazon GuardDuty to scan backups for malware, and item-level restore capabilities.
LGPD, ANPD, and incident notification
Brazil's LGPD does not use the word "backup" in its text, but Article 46 requires technical and administrative measures capable of protecting personal data against loss, destruction, and unavailability. That places backup and recovery strategy squarely within the law's scope.
One point technical teams often overlook: data unavailability can itself qualify as a reportable security incident. ANPD Resolution CD/ANPD No. 15/2024 establishes that, when an incident involves relevant risk, such as sensitive data, children's data, financial information, authentication credentials, or large-scale processing, the data controller must notify ANPD and the affected individuals within 3 business days of becoming aware of the incident.
This means a disaster recovery plan should not stop at the technical side of restoration. It also needs to define who triggers the legal team, how the incident gets documented, and how notification to individuals and to ANPD happens within that window.
Backup and DR across AWS, Azure, and GCP
Each major cloud provider offers native paths to backup and recovery, with slightly different approaches:
- AWS: the AWS Well-Architected Framework defines four disaster recovery strategies in increasing order of cost and complexity: Backup and Restore, Pilot Light, Warm Standby, and Multi-Site Active/Active. The right choice depends on the RTO and RPO defined for each workload.
- Azure: the Well-Architected Framework's Reliability pillar recommends geo-zone-redundant storage (GZRS) for cross-region recovery, synchronous replication across zones for critical data, and asynchronous replication across regions for lower-priority data, paired with tested recovery runbooks.
- GCP: Google Cloud's Architecture Center reinforces the same core principle covered above: define RTO and RPO first based on business impact, then choose between cold, warm, or hot recovery patterns.
In hybrid or multicloud environments, keeping a copy on premises or with a secondary provider, in addition to the primary cloud, also helps lower RTO and supports LGPD compliance, since it reduces dependency on a single point of failure.
Final checklist
To align your backup strategy with current standards and frameworks, review whether:
- Your backup policy follows the 3-2-1-1-0 model, with an immutable or isolated copy separated from the production network.
- RTO and RPO are defined per system, based on business impact rather than available tooling.
- Restore tests happen periodically, using real samples, with documented results, aligned with ISO/IEC 27001:2022 control 8.13 and NIST SP 800-53's CP-9 controls.
- Backup coverage includes cloud data, even data not directly managed in-house.
- A defined workflow exists for notifying ANPD and affected individuals within the 3 business day window set by Resolution CD/ANPD No. 15/2024.
- CIS Critical Security Controls v8's Control 11, on data recovery, is reflected in your process, with automated backups and isolated copies.
Backup and disaster recovery is not a one-time project; it is an ongoing process of setting targets, testing, and adjusting. Cloud Minds Trusted works with companies to build this strategy, from immutable backup architecture in the cloud to alignment with LGPD, ISO 27001, and NIST. If your team wants to review its resilience posture, talk to Cloud Minds Trusted.