Implement a 3-2-1 Backup Strategy

Before you start

Before starting: agree acceptable data loss (RPO) and downtime (RTO). Confirm what your cloud provider backs up and what remains your responsibility.

Put it into practice

1. Start with the most important service and available backup capabilities. Include data, configurations, and recovery dependencies.
2. For Microsoft 365, list the recovery path for each important workload. SharePoint and OneDrive version history and Recycle Bin can recover some file changes or deletions, depending on permissions and retention settings. Check those settings in your tenant and test with synthetic content; do not mistake native recovery for a separate backup or assume it covers Exchange and whole-service recovery.
3. Use 3-2-1 as a planning pattern: three copies, two storage types, one off-site. Keep an offline or appropriately immutable copy; immutability and being offline are different protections.
4. Separate backup administrator access, use MFA where supported, and encrypt sensitive backups. Verify deletion permissions and retention. Keep recovery keys accessible to authorized responders during an outage.
5. Assign someone to review failures on a schedule consistent with your recovery objectives. Repeat restoration tests after important changes and on an agreed schedule.
6. Verify: restore a representative sample safely, open restored files or start the service, check integrity, and record recovery time and the recovered data point.

Fictional example: test one restore before relying on it

An invented small team wants to check a project-folder backup. This is an illustrative exercise, not a lab result or a customer story.

1. Prerequisites: obtain approval, choose a non-sensitive test folder, confirm access to the backup and a separate restore destination, and agree what acceptable recovery time and data loss mean for this service. For this fictional exercise only, assume a four-hour data-loss target and one-business-day recovery target; real targets must come from the service owner.
2. Create two synthetic files, such as a text note and an Excel workbook with invented entries, and let the normal backup process capture them. Record the backup time and expected contents. Do not delete or overwrite the working originals to run this exercise.
3. Restore the selected files into the separate destination. Open them, compare their contents with the originals, check access permissions, and record how long recovery took and which backup point was recovered. Compare the recovered data point with the acceptable data loss agreed before the test; a readable restore can still miss that target.
4. If the restore fails or permissions are wrong, keep the originals and backup intact, record the failure, and investigate with the backup owner. Correct the cause and repeat the test before treating recovery as demonstrated.
5. After verification, remove only the temporary restored test copies through the normal approved process. Preserve the result record. A file restore does not demonstrate full-service recovery; plan a separate authorized exercise for configurations and dependencies.