| Table of ContentsWhat SaaS backup and disaster recovery meansWhy tenant data needs its own strategyThe 3-2-1-1-0 rule for SaaSPoint-in-time recovery for shared databasesRestoring a single tenantChoosing a disaster recovery strategyTesting restores before you need themBackups, deletion, and complianceFAQs |
In January 2017, an engineer at GitLab accidentally deleted a production database directory, and the team then discovered that several of their backup methods had not been working. Stories like that are why Acquaint Softtech treats recovery as part of support and maintenance, not an afterthought: a backup you have never restored is only a hope.
For a SaaS product, the stakes multiply. One failure can touch hundreds of customers at once, and each of them expects their own data back, quickly and intact. This guide covers how to set recovery targets, structure backups, restore a single tenant, and prove the plan works.
It draws on SaaS platforms Acquaint Softtech has built and supported as an Official Laravel Partner, with 1,300+ projects, 70+ in-house engineers, and clients across the USA, UK, Europe, and Australia who get a dedicated team within 48 hours of a brief.
What SaaS backup and disaster recovery means
SaaS backup is keeping recoverable copies of every tenant’s data, while disaster recovery (DR) is the plan for restoring service after a major failure. Backups protect data; DR protects the business that runs on it.
RPO and RTO, defined
Recovery point objective (RPO) is the maximum amount of data, measured in time, you can afford to lose. Recovery time objective (RTO) is the maximum time you can be down before service returns. Every backup and DR decision below is a trade-off between these two numbers and cost.
Why tenant data needs its own strategy
Cloud providers keep their infrastructure running, but under the shared responsibility model used by AWS, Azure, and Google Cloud, protecting your application data is your job. A managed database does not stop a bad migration or a deleted table.
Most data loss is not a disaster
Full region outages are rare. Far more common are accidental deletes, faulty deployments, corrupted imports, and ransomware. A strategy designed only for a data centre fire will miss the everyday incidents that actually cost tenants their data.
The 3-2-1-1-0 rule for SaaS
The 3-2-1-1-0 rule extends the classic 3-2-1 backup rule for the ransomware era. It gives a simple checklist for whether your backups will survive the failures that matter.
| Rule | Meaning | SaaS example |
| 3 copies | Production plus two backups | Primary database, snapshot, offsite copy |
| 2 media | Different storage types | Block storage and object storage |
| 1 offsite | Different region or provider | Cross-region backup bucket |
| 1 immutable | Cannot be altered or deleted | Object lock in compliance mode |
| 0 errors | Restores verified clean | Automated restore tests pass |
Why immutability matters
Attackers who reach production often delete backups first. Storage with write-once retention, such as Amazon S3 Object Lock in compliance mode, prevents any user, including the account root user, from deleting a backup before its retention period ends.
Point-in-time recovery for shared databases
Point-in-time recovery (PITR) restores a database to any moment, not just the last nightly snapshot. It combines a full base backup with a continuous log of changes, such as PostgreSQL write-ahead logs or MySQL binary logs, replayed up to the chosen second.
Why PITR sets your real RPO
With nightly snapshots alone, a failure at 11 pm can cost almost a full day of every tenant’s work. Continuous log archiving shrinks that window to minutes. Teams that hire DevOps engineers usually automate the archiving, retention, and cross-region copy together, so no step depends on someone remembering it.
Restoring a single tenant
Restoring one tenant is the request SaaS teams face most and plan for least. In a shared database, you cannot roll back the whole system to fix one customer’s mistake without destroying everyone else’s newer work.
Restore to the side, then extract
Restore the backup to a separate, isolated instance, extract only that tenant’s rows by tenant ID, and merge them back into production. Script this process in advance, including file storage, because a hand-built restore under pressure is where second incidents happen.
Design for it early
Every tenant-owned table needs a tenant ID column, and file paths should include it too. Database-per-tenant designs make single-tenant restores simpler, at the cost of more databases to operate.
Choosing a disaster recovery strategy
Four standard DR strategies trade cost against recovery speed. Pick the cheapest one that meets the RTO and RPO your contracts promise.
| Strategy | How it works | Recovery speed | Cost |
| Backup and restore | Rebuild from backups in a new region | Hours | Lowest |
| Pilot light | Core data replicated; servers off until needed | Tens of minutes | Low |
| Warm standby | Scaled-down copy always running | Minutes | Medium |
| Multi-site active | Full capacity in two regions | Near zero | Highest |
Testing restores before you need them
A backup is proven only by a successful restore. Schedule automatic restores into a test environment, then run checks that row counts, recent records, and file attachments match production.
Run game days
At least a few times a year, simulate a real incident and time the full recovery against your RTO. Teams that hire automation engineers turn these drills into scheduled pipelines, so a failed restore raises an alert long before a customer ever needs one.
Backups, deletion, and compliance
Privacy laws such as GDPR give people the right to have their data erased, but rewriting every backup is impractical. Regulators such as the UK ICO accept keeping deleted data “beyond use” in backups until they expire on a set schedule.
Suppress on restore
Keep a deletion log of erased tenants and users, and re-apply it after any restore, so deleted data never returns to production. Set clear retention periods and state them in your privacy policy and customer contracts.
FAQs
What is the difference between RPO and RTO?
RPO is the maximum data loss you can accept, measured in time, such as 15 minutes. RTO is the maximum downtime before service must return, such as one hour. Together they define how often you back up and how fast you must restore.
Does my cloud provider back up my SaaS data?
Not by default in a way that covers you. Under the shared responsibility model, providers protect their infrastructure, while you protect your data. Managed databases offer backup features, but you must enable, configure, copy, and test them yourself.
What is the 3-2-1-1-0 backup rule?
Keep 3 copies of data on 2 different storage types, with 1 copy offsite and 1 copy immutable or offline, and 0 errors in verified restores. It extends the classic 3-2-1 rule to resist ransomware.
How do you restore data for just one tenant?
Restore the backup to a separate isolated instance, extract that tenant’s rows by tenant ID, and merge them into production. This avoids rolling back other tenants. Script and test the process before you ever need it.
How often should SaaS backups be tested?
Automated restore tests should run at least weekly, with checks on row counts and recent records. Full disaster recovery drills, timed against your RTO, should run a few times a year and after major infrastructure changes.
How do backups work with GDPR deletion requests?
Delete the data from production immediately, keep it beyond use in backups until they expire on schedule, and log every deletion. After any restore, re-apply the deletion log so erased data never reappears in the live system.
