Disaster Recovery & Backup Solutions

The 3-2-1 backup rule is the most widely accepted principle for backup resilience: keep 3 copies of data, on 2 different storage media types, with 1 copy offsite. The logic behind each number: 3 copies ensures that two simultaneous failures are required to lose all data; 2 media types protects against media-specific failure modes (a fire that destroys both an on-premise server and a NAS in the same building cannot reach cloud storage); 1 offsite copy ensures geographic separation - a natural disaster, fire, or flood at the primary site cannot destroy all copies. Practical 3-2-1 implementation for a cloud-hosted application: primary database on RDS (copy 1), automated RDS snapshots in the same AWS region (copy 2, different media - S3), cross-region snapshot replication to a secondary AWS region (copy 3, geographically offsite). For on-premise applications: production server (copy 1), local NAS backup (copy 2), daily replication to cloud storage (copy 3, offsite). An enhanced version for ransomware resistance adds a fourth requirement: 1 copy immutable (cannot be modified or deleted, even by a compromised admin).

Traditional network-connected backup is vulnerable to ransomware that traverses the network to encrypt backup targets alongside primary data. Protection requires three measures. First, immutable backup: AWS S3 Object Lock with Compliance mode creates backups that cannot be deleted or overwritten for a defined period - even by the root account - making them immune to ransomware encryption. Azure Blob immutability policies provide the same protection. Second, air-gap via account separation: backup data stored in a separate AWS account or Azure subscription with no IAM trust relationship to the production environment - compromising production credentials cannot access the backup account. Third, sufficient retention: ransomware may be dormant for weeks before activation. A 90-day backup retention ensures recovery from a clean pre-infection state even when infection was dormant. Additional protection: immutable CloudTrail logs detecting unusual deletion attempts or large-scale encryption events, and CloudWatch alarms triggering when abnormal patterns of file modification or deletion are detected.

A DR drill is a planned, structured test of the disaster recovery runbook - executing the actual recovery procedure in a test environment, measuring the time each step takes, identifying gaps and errors, and updating the runbook based on findings. DR drills are essential because DR runbooks without execution contain errors that only surface under test: a step references a configuration that has changed since the runbook was written, a tool version is different, a network dependency was not documented. For most Indian organisations, an annual DR drill is the minimum requirement - sufficient for regulatory compliance (RBI IT Risk Framework, ISO 27001) and for catching the most significant runbook drift. High-criticality systems (core banking, payment processing, healthcare patient management) should be drilled quarterly. A DR drill should simulate the exact failure scenario the runbook covers: for a database corruption scenario, the drill starts from the point where the DBA reports the database is corrupted, and ends when the service is restored from backup and traffic is confirmed flowing correctly. Measured RTO from the drill should be compared against the RTO target - gaps require either runbook improvement or DR architecture upgrade.

Backup is the process of copying data to a secondary location so it can be restored after data loss. Disaster recovery is the broader capability of restoring business operations after a major disruptive event - backup is a component of DR but DR includes more: the recovery procedure (documented steps for restoring systems, not just restoring data), the recovery infrastructure (DR site, failover servers, network configuration), the people and process (who executes recovery, how decisions are made, who declares an incident), and DR testing. A company with excellent backups can still fail at disaster recovery if: the recovery procedure is undocumented and the team improvises under pressure; the restored database comes up but the application cannot connect because the configuration references the old hostname; the recovered system lacks the SSL certificates that were only on the primary server; or the firewall rules at the DR site block the traffic the application requires. Disaster recovery planning addresses all dependencies, not just data.

Backup retention policy depends on three factors: compliance requirements, recovery scenarios, and storage cost. Compliance minimums: RBI mandates minimum 7-year retention for certain banking records; DISHA requires 7-year retention for patient data; IT Act requires preservation of electronic records for specified periods per transaction type. Recovery scenarios: ransomware protection requires 90-day retention minimum (to recover from pre-infection state); accidental deletion recovery typically requires 30 days; operational recovery (restoring from the most recent clean backup) requires 7-30 days. A common enterprise retention policy: daily backups retained 30 days, weekly backups retained 90 days, monthly backups retained 12 months, annual backups retained 7 years. Storage cost optimisation: daily backups for 30 days at full storage cost; older backups transitioned to S3 Glacier Instant Retrieval (40% cheaper), then Glacier Deep Archive (80% cheaper) for long-term archival. Retention policy should be documented, enforced via automated lifecycle policies (not manual deletion), and reviewed annually for compliance requirement changes.

Disaster Recovery as a Service (DRaaS) is a cloud-based service model where a third party provides and manages the DR infrastructure and replication, offering DR capability without requiring the customer to build and operate secondary DR infrastructure. DRaaS providers include VMware Cloud Disaster Recovery, Zerto (now part of HPE), and Veeam Cloud Connect partners. AWS and Azure provide DRaaS-like capabilities through AWS Elastic Disaster Recovery (formerly CloudEndure) and Azure Site Recovery. The customer installs a replication agent on on-premise servers; the agent continuously replicates to the DRaaS platform; on failover, the DRaaS spins up equivalent compute from the replicated image. DRaaS is appropriate for organisations with on-premise primary infrastructure that need cloud DR capability without building cloud infrastructure expertise. The primary advantage is simplicity - the DR site is managed by the DRaaS provider. The trade-off is cost (DRaaS is typically priced per protected server per month) and control (the organisation relies on the provider's infrastructure and SLA).

RTO/RPO assessment and DR strategy design, cloud backup (AWS/Azure/GCP), on-premise DR, hybrid DR architecture, database backup and PITR, backup automation and monitoring, DR testing and drills, ransomware protection, and business continuity planning.

Yes. Evolution Infosystem designs ransomware-resistant backup using AWS S3 Object Lock (immutable backups), air-gapped backup accounts with no IAM trust to production, and 90-day retention for pre-infection recovery.

Yes. Evolution Infosystem executes annual and quarterly DR drills - testing the recovery runbook in a simulated failure scenario, measuring actual RTO vs target, and delivering a board-level DR drill report.

Yes. Evolution Infosystem designs backup and DR architecture meeting RBI IT Risk Framework requirements - documented RTO/RPO, 7-year immutable transaction record retention, and annual DR drill with board report.

< 15 minutes for Tier 1 applications with warm standby DR architecture. < 30 minutes for hybrid on-premise to cloud failover. Hours for Backup and Restore strategy (appropriate for Tier 3/4 applications).