DR Is Not Optional#
ERP systems are business-critical. When your ERP is unavailable, your business may be unable to process orders, manage inventory, or generate invoices. Disaster recovery (DR) planning is not optional—it's a business necessity.
The uncomfortable truth: Most organisations have DR plans that have never been tested. When disaster strikes, these plans often fail. The time to discover your DR plan doesn't work is not during an actual disaster.
---
Recovery Objectives#
RTO (Recovery Time Objective)#
How quickly must the system be restored?
Typical ERP RTOs: - Mission-critical: 1-4 hours - Important: 4-24 hours - Standard: 24-72 hours
RPO (Recovery Point Objective)#
How much data can be lost?
Typical ERP RPOs: - Mission-critical: 0-1 hour - Important: 1-24 hours - Standard: 24-48 hours
The Cost of Recovery#
Faster recovery costs more: - Lower RTO requires standby infrastructure - Lower RPO requires more frequent backups - Both require ongoing investment
Balance recovery speed against business impact and cost.
---
DR Architecture Patterns#
Active-Passive#
How it works: - Primary site handles all traffic - Secondary site stands ready - Failover when primary fails
Considerations: - Simpler to implement - Lower cost than active-active - Failover time includes startup
Active-Active#
How it works: - Multiple sites handle traffic simultaneously - Load distributed across sites - Automatic failover
Considerations: - More complex - Higher cost - Instant failover - Requires data synchronisation
Pilot Light#
How it works: - Minimal infrastructure running at DR site - Core services (database) always running - Scale up on failover
Considerations: - Lower cost than active-passive - Faster than cold standby - Requires scaling automation
Warm Standby#
How it works: - Scaled-down version of production at DR site - Continuously receiving data - Scale up on failover
Considerations: - Balance of cost and speed - Requires resource scaling - Data synchronisation maintained
---
Backup Strategies#
What to Backup#
Database: - Full backups (daily) - Incremental backups (hourly) - Transaction log backups (frequent) - Point-in-time recovery capability
Application: - Configuration files - Custom code - Integration settings - Security configurations
User Data: - Document attachments - Report templates - User preferences
Where to Store Backups#
3-2-1 Rule: - 3 copies of data - 2 different storage types - 1 offsite location
ANZ considerations: - Australian data centre for offsite - Verify NZ options if required - Consider regulatory requirements
Backup Testing#
Untested backups are not backups.
Regular backup testing: - Monthly: Verify backup integrity - Quarterly: Test restore process - Annually: Full DR exercise
---
Failover and Failback#
Failover Process#
- Detection: Confirm primary failure
- Decision: Authorise failover
- Communication: Notify stakeholders
- Activation: Bring DR site online
- Validation: Verify system functionality
- Traffic routing: Direct users to DR site
Failback Process#
- Primary restoration: Repair/rebuild primary
- Data synchronisation: Sync data from DR to primary
- Validation: Verify primary functionality
- Communication: Notify stakeholders
- Traffic routing: Direct users back to primary
- DR reset: Return DR site to standby
---
ANZ-Specific Considerations#
Geographic Factors#
Distance: - Australian data centres for primary - NZ or secondary Australian region for DR - Network latency for replication
Natural disasters: - Earthquake risk (NZ) - Bushfire risk (AU) - Flood risk (both) - Geographic separation important
Business Hours#
Peak periods: - End of financial year - Month-end processing - Payroll windows
DR planning should account for: - Higher impact during peak periods - Different RTO/RPO during critical windows
Regulatory#
Financial services: - APRA (AU) requirements - RBNZ (NZ) guidance
Healthcare: - Patient data protection - Service continuity requirements
---
DR Testing Regime#
Testing Types#
Tabletop exercise: - Walk through DR plan - Identify gaps - Low cost, high value
Component test: - Test individual DR components - Backup restore - Network failover
Partial failover: - Failover non-production - Validate process - Limited risk
Full failover: - Complete failover to DR - Production traffic on DR - Highest confidence, highest risk
Testing Frequency#
| Test Type | Frequency |
|---|---|
| Tabletop | Quarterly |
| Component | Monthly |
| Partial | Semi-annually |
| Full | Annually |
---
Monday Morning Action Plan#
- Document Your Current DR Plan: What would you do if your ERP failed today?
- Define RTO/RPO: How quickly must you recover? How much data can you lose?
- Test Your Backups: When did you last verify a backup restore works?
- Identify DR Gaps: What aspects of recovery are undefined or untested?
- Schedule DR Testing: Put regular DR exercises on the calendar.
---
Conclusion: DR Planning Is Business Continuity#
Disaster recovery planning is not an IT exercise—it's business continuity planning. When your ERP is unavailable, your business suffers. The investment in DR planning and testing pays off when (not if) disaster strikes.