What Disaster Recovery (DR) means in practice
Disaster recovery is the technology component of business continuity. Continuity planning asks how the organisation keeps operating; disaster recovery asks how the systems come back. The two are frequently conflated, with the result that a technically successful restore lands in an organisation that has no process for the period before it completes.
A credible DR capability has four parts. A documented plan naming who declares a disaster, who executes, and in what order systems are recovered. A dependency-ordered recovery sequence, because restoring an application before identity, DNS and network connectivity achieves nothing. Protected copies of data that an attacker with domain administrator rights cannot delete — immutable, offline or in a separate security boundary. And a testing regime that proves the whole thing under time pressure.
Ransomware changed the design assumptions. Historical DR planned for single-site loss, with the surviving site intact. A ransomware event compromises the environment itself, including backup servers and often the backup catalogue, and may have been present for weeks before detonation. That drives requirements for immutability, credential separation between production and backup, and retention long enough to recover from before the intrusion began rather than after.
Cloud does not remove the obligation. Azure provides regional resilience, availability zones, geo-redundant storage and Azure Site Recovery, but the customer still chooses and configures them, and shared responsibility places recovery of customer data with the customer. A single-region deployment with locally redundant storage is a design decision, not a default someone else is managing.
The habit that separates organisations that recover from those that do not is exercising. An annual test that restores a real workload, times it, and produces a list of what went wrong is worth more than any amount of documentation, and is the evidence insurers and regulated clients now ask to see.
What is RTO and RPO in disaster recovery?
RTO (Recovery Time Objective) is how long you can afford to be offline — the maximum acceptable downtime after a failure. RPO (Recovery Point Objective) is how much data you can afford to lose — measured in time, not volume. If your RPO is 4 hours, you must take a backup at least every 4 hours so that a failure never costs you more than 4 hours of data. RTO and RPO together define the requirements your disaster recovery solution must meet. A lower RTO requires more expensive infrastructure (hot standby, active-active replication). A lower RPO requires more frequent backups or continuous replication.
Cloud disaster recovery for Australian businesses
Azure Backup and Azure Site Recovery are Microsoft's cloud-based disaster recovery tools for Australian businesses. Azure Backup provides scheduled backups of VMs, databases, and files to Microsoft's Australian datacentres (Sydney and Melbourne). Azure Site Recovery replicates on-premises or Azure VMs to a secondary Azure region, enabling failover within minutes. For Microsoft 365, native retention features protect against accidental deletion but not ransomware or admin error — a third-party Microsoft 365 backup solution is required for genuine point-in-time recovery. Mycelium 365 designs and manages disaster recovery solutions for Australian businesses — contact us to discuss your RTO and RPO requirements.
How we help with this
Related terms
- Microsoft 365 BackupMicrosoft 365 backup means taking independent, restorable copies of Exchange Online, SharePoint, OneDrive and Teams data.
- RTO and RPORecovery time objective is the maximum acceptable time a service can be unavailable after a disruption.
- APRA CPS 230CPS 230 is the APRA prudential standard on operational risk management.
- APRA CPS 234CPS 234 is the APRA prudential standard on information security.
Ready to simplify and secure your technology?
Book a free, no-obligation Discovery Call to talk through your Microsoft 365, Azure, security, or support needs — no sales pitch, just a straight conversation.
We respond to every enquiry within 4 business hours. Monday to Friday, 7am–7pm AEST.
