Backups are one of those things organizations assume they have handled... right up until the moment they actually need them.
When systems fail, ransomware hits, or a cloud outage takes down infrastructure, backups quickly become the difference between a manageable disruption and a catastrophic loss of data. But having backups isn’t the same as having a resilient backup strategy. In many environments, backups exist in theory but fall apart under real-world failure conditions.
A resilient backup strategy is designed with the assumption that things will go wrong: infrastructure will fail, attackers will try to destroy backups, and sometimes entire regions or services will become unavailable. Here's a short checklist of a few principles we believe are essential to a good backup strategy.
Follow the 1-2-3 rule
One of the most widely accepted foundations for backup design is the 3-2-1 rule. The idea is simple but powerful: maintain three copies of your data, store those copies on at least two different types of media, and keep at least one copy offsite. The goal is to prevent a single point of failure from wiping out both your primary systems and your backups. If production data is stored locally, for example, the backups should not live solely on the same infrastructure.
Geo-distribution
Modern cloud environments add another layer to this concept: geographic redundancy. Backups stored in the same data center—or even the same region—as your production systems can disappear during large-scale outages. That’s why many organizations replicate backups across regions or even across accounts. Cloud platforms such as AWS provide mechanisms for automatically copying backups from one region to another, ensuring that a failure in one location doesn’t eliminate recovery options.
For some organizations, especially those operating in regulated industries, jurisdictional separation also becomes important. Storing backups in multiple regions or even multiple countries can help protect against large-scale disasters, legal disruptions, or regulatory requirements affecting data availability.
Logical & Physical Separation
Another key principle is separation. Backups should not exist inside the same trust boundary as the systems they protect. If an attacker compromises production infrastructure, they should not automatically gain access to the backups as well. This often means isolating backup systems on separate networks, using different credentials, and even maintaining distinct encryption keys. Logical and physical separation ensures that a single breach or configuration error cannot cascade across the entire environment.
Restore Drills
Even when organizations maintain multiple copies of data, another problem frequently appears: no one has actually verified that those backups can be restored. A backup that cannot be restored is effectively useless. Periodic recovery testing is the only way to confirm that recovery procedures work in practice. Some organizations take this further by conducting “blind” restoration exercises where a different team attempts the recovery without relying on the original configuration knowledge. The goal is to prove that systems can truly be rebuilt under real disaster conditions.
WORM (Write-once Storage for Ransomware Defense)
Ransomware has also changed how backups are designed. Many modern attacks specifically target backup systems first, attempting to delete or encrypt them before triggering the main payload. To defend against this, many organizations now rely on immutable storage. Immutable backups cannot be modified or deleted during a defined retention window, even by administrators. This “write-once” approach prevents attackers from silently destroying recovery points during an intrusion.
Encryption, Access Controls & Monitoring
Security controls around backups themselves are just as important as the backup process. Backup data should be encrypted both in transit and at rest, access to backup systems should be tightly restricted, and all operations should be logged and monitored. These safeguards ensure that backups remain protected from both external attackers and internal mistakes.
Retention, Lifecycle & Cost Management
Retention policies also play a major role in long-term backup design. Storing every backup indefinitely can quickly become expensive, especially as data volumes grow. Organizations typically rely on lifecycle policies that move older backups into cheaper archival storage tiers while maintaining recent backups in faster-access environments. Carefully designed retention policies allow companies to balance cost with recovery needs.
Automated Backup Policies, Tagging & Compliance
Automation is another critical element. Manual backup processes are prone to error, and it’s easy for new systems to be deployed without being added to existing backup routines. Many organizations now use automated policies, tagging systems, and infrastructure-as-code to ensure that new workloads are automatically enrolled in backup schedules. Automation reduces the risk that a critical system is accidentally left unprotected.
Disaster Recovery Beyond Just Backup
It’s also important to remember that backups are only one part of a larger disaster recovery strategy. Restoring data is not enough if the infrastructure required to run that data is unavailable. Effective disaster recovery planning also includes failover systems, standby environments, defined recovery time objectives (RTO), recovery point objectives (RPO), and plans for restoring network connectivity and application dependencies.
Are you confident your backups would actually work during a crisis? If you’re unsure InfoPathways can help assess your environment and design a backup strategy built for resilience. Contact us to learn more.
