Every Australian business believes it has backup until the day it needs to restore something. That is when the difference between having copies of data and having a recovery capability becomes painfully clear — and it is also when cyber insurers, auditors, and customers start asking questions that a recycle bin cannot answer.
This guide explains what cloud backup and disaster recovery actually involve for an Australian business of 10–300 users, how Azure Backup and Microsoft 365 backup fit together, and how recovery objectives should drive the whole design. Mycelium 365 delivers both layers as a managed service — see our Azure Backup service for the managed implementation.
Cloud backup vs disaster recovery — what's the difference?
Backup is creating restorable copies of data. Disaster recovery (DR) is the broader plan for restoring business operations after disruption — restoring data from backup is one step in a DR plan, not the whole plan. A DR plan also covers recovering systems, re-establishing connectivity, deciding who works from where, and communicating with staff and customers while all of that is happening.
An untested backup is not disaster recovery. A backup that completes every night but has never been restored is an assumption, and assumptions fail at the worst possible moment — during a ransomware event, a failed server, or an accidental mass deletion discovered three weeks later.
Most Australian businesses have backup in some form; far fewer have a tested disaster recovery plan with documented recovery time objectives (RTOs) and recovery point objectives (RPOs). That gap is exactly where incidents become existential events. Mycelium 365 provides both: managed cloud backup via Azure Backup, and tested disaster recovery procedures as part of the managed service — so the copies exist, the plan exists, and both are verified on a schedule.
Azure Backup — cloud backup for Australian businesses
Azure Backup is Microsoft's cloud backup platform — it stores encrypted, geo-redundant copies of data in Microsoft's Australian datacentres (Sydney primary, Melbourne secondary). Data sovereignty is therefore satisfied by default for Australian workloads, and encryption is applied in transit and at rest.
What Azure Backup covers:
Azure virtual machines — full VM backup with application-consistent snapshots, so databases and line-of-business applications restore cleanly rather than crash-consistently.
Azure SQL databases — automated daily backups with 7–35 day retention, extendable for long-term retention requirements.
Azure File Shares — point-in-time snapshots that allow individual files or entire shares to be rolled back.
On-premises Windows Servers — via the Azure Backup agent, extending the same policy-driven protection to physical or on-prem virtual infrastructure during a migration period.
Microsoft 365 data — Exchange Online, SharePoint, OneDrive, and Teams, covered in the next section.
Azure Backup pricing is consumption-based — Australian businesses typically pay $5–15/month per VM and $2–5/month per 100GB of protected storage. That makes cloud backup one of the few IT costs that scales almost perfectly with the size of the environment being protected. Mycelium 365 manages Azure Backup configuration, monitoring, and monthly restore testing, and the consumption cost is reported transparently alongside the management fee.
Microsoft 365 backup — protecting Exchange, SharePoint, OneDrive, and Teams
Microsoft 365 does not include backup. Microsoft's shared responsibility model is explicit on this point: Microsoft is responsible for the availability of the service; the customer is responsible for the data in it. If data is deleted — by a user, by a rogue administrator, or by ransomware encrypting a synchronised SharePoint library — Microsoft's position is that restoring it is the customer's problem.
Native retention features (recycle bins, litigation hold, version history) are not backup. They cannot restore an entire mailbox or site collection to a specific point in time, they are not independent of the tenant they protect, and they cannot recover from ransomware that corrupts data across the entire tenant. A recycle bin with a 93-day window is not a recovery capability for a deletion discovered on day 100.
Mycelium 365 manages Microsoft 365 backup for Exchange Online, SharePoint, OneDrive for Business, and Teams — daily backups with point-in-time restore capability and monthly restore testing. See Microsoft 365 Backup Services for full details on coverage, retention, and pricing.
Recovery time objectives and recovery point objectives — what they mean for Australian businesses
Two numbers define whether a backup and recovery capability is adequate:
RTO (recovery time objective) — how quickly a system must be restored. For example: email within 4 hours, file access within 2 hours, ERP within 8 hours. A system with a 4-hour RTO backed up by a process that takes two days to restore is not protected; it is documented.
RPO (recovery point objective) — how much data loss is acceptable. For example: no more than 24 hours of email, no more than 4 hours of financial transactions. RPO determines backup frequency — a 4-hour RPO cannot be met by a nightly backup.
Every Australian business has implicit RTOs and RPOs — the question is whether they are documented and tested. When they are not documented, they are discovered during an incident, which is the most expensive possible time to learn them. Mycelium 365 documents explicit RTOs and RPOs for each critical system, configures Azure Backup and Microsoft 365 retention to meet them, and tests recovery against those objectives quarterly. The results are reported to leadership, so the recovery position is a known quantity rather than a hope.
IT disaster recovery for Australian businesses — what a real DR plan includes
A real disaster recovery plan covers six things:
System inventory — which systems exist, what data they hold, and what depends on what. Email depends on identity; the ERP may depend on a database server; file access depends on networking. Recovery in the wrong order wastes the recovery window.
RTO and RPO per system — the objectives from the previous section, assigned to each inventoried system.
Recovery procedures — step-by-step instructions: who does what, in what order, with what credentials. A procedure that lives in one person's head fails the moment that person is on leave.
Communication plan — who to notify, in what order, via what channel, including what to do when the primary communication platform is the thing that has failed.
Escalation path — what happens if the primary person is unavailable, and who has authority to invoke the plan.
Test schedule — when the plan is tested, by whom, and against what success criteria.
Mycelium 365 develops IT disaster recovery plans for Australian businesses as part of its Business Continuity Planning advisory service — integrated with Azure Backup configuration and Microsoft 365 continuity settings, so the plan and the tooling are designed together rather than bolted together afterwards.
Cloud backup for Australian compliance — APRA, ACNC, and Privacy Act
Backup and recovery obligations are now written into the frameworks Australian businesses operate under.
APRA CPS 230 requires tested business continuity and data recovery capability for regulated entities — and extends that expectation to the service providers those entities rely on. ACNC record retention requirements (7 years for financial records) mean email and document backup is not optional for Australian NFPs. The Privacy Act requires reasonable security measures for personal information — which includes protection against loss and unauthorised destruction, not just theft.
Azure Backup with geo-redundant storage in Australian datacentres satisfies Australian data sovereignty requirements for all three frameworks. Mycelium 365 provides backup configuration evidence and restore test documentation suitable for APRA, ACNC, and Privacy Act audit purposes — produced as a by-product of the managed service, so it stays current between audits.
How to set up cloud backup for your Australian business — step by step
Step 1 — Inventory what needs backing up. List every critical data source: Azure VMs, SQL databases, file shares, on-premises servers, and Microsoft 365 workloads (Exchange, SharePoint, OneDrive, Teams). Prioritise by the business impact if each were lost.
Step 2 — Define RTO and RPO for each system. Document how quickly each system must be restored and how much data loss is acceptable. These two numbers drive backup frequency, retention, and the recovery procedure itself.
Step 3 — Configure Azure Backup for infrastructure. Set up Recovery Services vaults for VMs, databases, and file shares. Configure daily backup schedules at minimum, retention of 30 days or more, and geo-redundant storage in Australian regions.
Step 4 — Configure Microsoft 365 backup. Enable backup for Exchange Online, SharePoint, OneDrive, and Teams, and verify daily backup completion — SaaS data is the most commonly overlooked layer.
Step 5 — Test recovery quarterly. Restore actual data from each protected system and verify it meets the documented RTO. Record the results. An untested backup is not a reliable backup.
Mycelium 365 runs this entire process as part of the Secure Cloud managed package, or as a standalone backup implementation project. Contact Mycelium 365 for a backup assessment to review your current recovery position.