Backup & recovery
Design backup and recovery for cloud-hosted Access with tested restore workflows.
Moving Microsoft Access to the cloud improves infrastructure reliability , but it does not automatically solve backup and recovery. Cloud-hosted Access databases face unique backup challenges: .accdb files require consistent-state copies, multi-user sessions complicate snapshot timing, and restore procedures must be tested regularly to be trustworthy. This guide covers backup strategy for each cloud architecture, RPO/RTO target setting, automated backup configuration, and disaster recovery planning.
Access databases often contain years of operational data , customer records, transaction history, inventory levels, financial calculations , that would be expensive or impossible to recreate from paper records or email threads. Yet backup strategy is frequently an afterthought during cloud migration projects, overshadowed by access setup, user onboarding, and performance tuning.
The risk profile actually increases during and after cloud migration. Data moves between environments. Connection strings change. Users access the database from new locations. Front-end versions multiply. Each transition is a point where data can be lost, overwritten, or corrupted if backups are not in place before the migration begins.
Cloud infrastructure providers offer snapshot and backup tools, but those tools capture disk state , not necessarily a consistent Access database state. If a snapshot runs while users have the .accdb open with uncommitted writes, the backup may contain a corrupted or incomplete file. Application-aware backup strategy is essential for Access, regardless of whether the server is on-premises or in AWS, Azure, or a managed hosting environment.
If you are evaluating cloud hosting options, include backup requirements in your vendor evaluation from day one. See our Access database online service page for managed hosting that includes tested backup and restore workflows.
Before configuring any backup tool, define two business metrics that drive every technical decision:
RPO answers: how much data can we afford to lose? If your team enters 200 transactions per day and you back up nightly at midnight, your RPO is up to 24 hours of data , potentially 200 lost transactions if the database fails at 11:59 PM. For most Access-based business systems, an RPO of 4–24 hours is acceptable. High-transaction systems (order processing, inventory receiving) should target 1–4 hours.
RTO answers: how quickly must we be back online after a failure? If your business stops when Access is unavailable, your RTO should be measured in hours, not days. A realistic RTO for cloud-hosted Access with pre-tested restore procedures is 2–4 hours. Without tested procedures, RTO can stretch to days while IT reconstructs the environment.
Document your RPO and RTO targets and share them with your hosting provider or IT team. Backup configuration should be driven by business requirements, not by whatever default the cloud platform offers.
| Architecture | Backup method | Typical RPO | Restore complexity |
|---|---|---|---|
| File BE on cloud VM | VSS snapshot + file copy to S3/Blob | 4–24 hours | Moderate , remount file, verify integrity |
| SQL BE on RDS/Azure SQL | Automated DB snapshots + log backups | 1–4 hours | Low , point-in-time restore |
| Hosted desktop (managed) | Provider-managed snapshots + off-site copy | 4–24 hours | Low , provider handles restore |
| Web app + SQL back-end | RDS snapshots + app-level export | 1 hour or less | Low , automated failover options |
| Hybrid (Access + SQL + web) | Layered: file + SQL + app backups | 1–4 hours | Moderate , coordinate across layers |
Different Access cloud architectures require different backup approaches. Using the wrong method produces backups that look valid but fail on restore.
Front-end files contain forms, reports, VBA code, and queries , but not business data. Back up front-end files in version control (Git) rather than snapshot-based backup. This gives you change history, diff capability, and reliable rollback for application logic changes.
Not confident your cloud Access backups would survive a real failure?
Request a backup auditManual backups fail because people forget, go on vacation, or skip steps under pressure. Automate everything possible and verify automation with monitoring alerts.
If you use a managed provider like our host MS Access online service, confirm these items in your service agreement:
An untested backup is a hope, not a strategy. Schedule restore drills quarterly and document results. Here is a step-by-step restore test protocol for cloud-hosted Access:
If restore time exceeds your RTO target, investigate bottlenecks , slow storage, missing automation, or incomplete runbook steps , and optimize before the next drill.
Backups protect against data loss. Disaster recovery protects against extended downtime when the entire hosting environment , not just the database file , becomes unavailable. Cloud-hosted Access needs a DR plan that covers server failure, region outage, ransomware, and accidental deletion.
As your Access system evolves , SQL upsizing, web app conversion, user count growth , update the DR plan to match the new architecture. A DR plan written for file-based Access on a single VM is insufficient after you migrate to RDS and a web app front-end.
For architecture planning that incorporates backup from the start, explore MS Access to web app conversion and review modernization pricing for phased migration that includes backup infrastructure at each stage.
Remote access reliability and backup strategy are closely linked , an Access system that users cannot reach is functionally equivalent to data loss during the outage window. See remote access options for architecture choices that reduce downtime risk.
Want backup and disaster recovery configured correctly from day one?
Book a free backup strategy reviewRelated reads: Access database online · Host MS Access online · Remote access without VPN · Modernization pricing · Access to web app
For managed backup and hosting, see our Access Database Online.
At minimum, daily automated backups with 30-day retention. For databases with continuous data entry, consider hourly snapshots or transaction log backups if using a SQL back-end. The backup frequency should match your recovery point objective (RPO) , how much data loss you can tolerate.
Copy the back-end file during a maintenance window when no users are connected, or use Volume Shadow Copy Service (VSS) on Windows for point-in-time snapshots. Store copies in a separate storage account or region from the production server. Never rely on a single copy on the same disk as the live file.
Cloud VM snapshots (EBS, Azure Disk) capture the entire server state but may not produce a clean .accdb copy if users are connected during the snapshot. Combine VM-level snapshots with application-aware backups that ensure the database file is in a consistent state.
Restore to an isolated test environment quarterly. Open the restored .accdb, verify record counts against production, run Compact and Repair, and test critical forms and reports. A backup that has never been restored is an untested assumption , not a safety net.
Web apps use SQL database backups (automated RDS snapshots, pg_dump, or managed backup services) instead of file copies. Migration projects should include a parallel backup period where both the legacy Access file and the new SQL database are backed up until cutover is validated.
Yes. Follow the 3-2-1 rule: three copies of data, on two different media types, with one copy off-site. Cloud hosting covers two of those; an additional off-site copy (different cloud region or local archive) protects against provider-level incidents.