Database backup strategy is a recovery plan that defines how production data is captured, retained, restored, and tested against a SaaS application's acceptable data-loss and downtime limits.
For a small SaaS team, this is a product reliability decision, not a checkbox. Raff Technologies supports 3,000+ customers and 15,000+ VMs, and the recurring recovery gap is usually not whether a backup job exists. It is whether the team knows which recovery point to use, who owns the restore, and whether the full application can return within the required time.
This guide explains the decision framework for RPO, RTO, point-in-time recovery, snapshots, database-aware backups, retention, isolation, and restore testing. For the wider production model, start with Storage and Recovery Architecture for Production Apps.
Database backups protect recovery history, not uptime
A database backup is a recoverable copy or recovery chain that lets a team return data to an earlier valid state. That is different from availability.
Replication, high availability, and failover are designed to keep a database service running through certain infrastructure failures. Backups preserve history so the team can recover from failures that a healthy replica may reproduce, including accidental deletion, a bad migration, destructive application writes, or corruption discovered later.
A production recovery design should therefore answer four separate questions:
- Availability: How does the database stay reachable after a node or host failure?
- History: Which earlier states can the team recover?
- Isolation: Can one incident, credential, or host failure remove every recovery copy?
- Evidence: Has the restore path been tested end to end?
PostgreSQL separates logical dumps, filesystem-level backups, and continuous archiving with point-in-time recovery in its official backup documentation. MySQL similarly distinguishes logical and physical backup methods and supports binary-log-based point-in-time recovery. Those database-aware mechanisms solve a different problem from a VM snapshot.
A snapshot can help restore infrastructure quickly. A database backup or PITR chain helps restore database state correctly. Production systems often need both layers.
RPO and RTO define the backup strategy
Recovery Point Objective and Recovery Time Objective should be chosen before backup frequency, retention, or tooling.
| Objective | Business question | Example |
|---|---|---|
| RPO | How much recent data can we lose? | At most 15 minutes of writes |
| RTO | How long can the database or app remain unavailable? | Service restored within 1 hour |
The two targets create different requirements.
| Recovery target | Practical implication |
|---|---|
| RPO near 24 hours | A verified daily backup may be enough for low-change data |
| RPO near 1 hour | More frequent recovery points or log-based recovery are needed |
| RPO measured in minutes | Continuous WAL/binlog archiving or managed PITR becomes important |
| RTO of several hours | Manual restore may be acceptable if documented and tested |
| RTO near 1 hour | Restoration, validation, credentials, and traffic cutover need rehearsed steps |
| RTO measured in minutes | Availability architecture may be needed in addition to backups |
The key distinction is that backup frequency does not equal RPO. A backup job can fail, a recovery point can be inconsistent, or the required logs can be missing. The newest usable recovery point must satisfy the target.
RTO is also wider than restore speed. It includes detection, decision, replacement infrastructure, data restoration, application validation, and returning traffic to service.
Use RPO vs RTO for Cloud Backups when the business targets themselves are still unclear.
Recovery design needs more than one protection layer
One mechanism rarely protects a SaaS database from every failure mode.
| Failure scenario | Better protection layer | Why |
|---|---|---|
| Primary host failure | HA or replication | Restores service continuity faster |
| Accidental row deletion | PITR or database backup | Replicas may reproduce the deletion |
| Bad schema migration | Pre-change recovery point + database backup | Gives a known rollback state |
| Database corruption | Independent database-aware recovery | Current replicas may not preserve a clean past |
| VM or disk failure | Database backup plus infrastructure recovery | Data and host recovery are separate concerns |
| Credential compromise | Isolated retention and narrow backup credentials | One identity should not delete every recovery copy |
| Delayed bug discovered days later | Multi-point retention | The newest backup may already contain the problem |
| App server loss | Rebuild or VM recovery | The app runtime is not the database backup |
| User-file loss | Object-storage recovery policy | File bodies and database records are different data sets |
A useful production model is:
Database availability ↓ HA / replication where required Database recovery history ↓ Backups + PITR where required Infrastructure rollback ↓ VM / volume snapshots and backups Retained backup artifacts ↓ Separate storage where appropriate Recovery confidence ↓ Restore testing
This is why replication is not a backup and snapshots are not a complete database strategy. Each layer should have one defined job.
For PostgreSQL specifically, PostgreSQL Replication vs Backups vs Snapshots covers those failure boundaries in more detail.
Managed and self-hosted databases have different recovery responsibilities
The operating model changes who builds and maintains the recovery system.
A managed database can remove much of the host-level backup and recovery work, but the application team still owns RPO/RTO decisions, safe restore-point selection, validation, schema behavior, migrations, credentials, and the application cutover after recovery.
A self-hosted database gives the team complete control, including complete responsibility for the recovery chain.
| Responsibility | Managed database | Self-hosted database |
|---|---|---|
| Backup platform | Provider operates within service scope | Team designs and operates it |
| Database host patching | Provider scope | Team scope |
| Recovery tooling | Service-defined workflow | Team-defined tooling and runbook |
| Backup monitoring | Provider baseline + customer oversight | Team owns it |
| PITR capability | Depends on engine/service | Team configures WAL/binlog/archive chain |
| Restore validation | Customer responsibility | Customer responsibility |
| Schema and migration safety | Customer responsibility | Customer responsibility |
| Retention requirements | Customer decides within product capabilities | Customer designs and enforces them |
| Business cutover | Customer responsibility | Customer responsibility |
For self-hosted PostgreSQL, logical dumps may be useful for portability and selected restore scenarios, while physical base backups plus continuous WAL archiving support point-in-time recovery. For MySQL, logical or physical backup methods can be combined with binary logs when point-in-time recovery is required.
The important question is not which method sounds more advanced. It is whether the chosen method can meet the required RPO and RTO at the current database size.
Read Managed vs Self-Hosted Databases for the broader ownership decision.
Retention and isolation protect against delayed failures
Keeping only the latest backup is not enough for incidents discovered late.
A bug may have overwritten data three days ago. A destructive migration may not be noticed until a customer opens an old record. A compromised credential may have been used repeatedly. In those cases, the newest backup can already contain the damaged state.
Retention should therefore preserve more than one recovery point. A small team might combine:
- frequent recent recovery points for short RPO;
- daily points for recent history;
- weekly or monthly points where longer rollback is justified;
- explicit pre-migration recovery points before risky changes;
- separate retention requirements for production and non-production data.
The exact schedule should come from business risk, not a copied template.
Isolation matters as much as age. A backup stored only on the database host shares the same failure boundary. A recovery copy deletable by the same broad production credential can also share the same security failure boundary.
For self-hosted databases, a separate object-storage destination can provide a useful retention boundary for dumps or backup artifacts when the database tooling supports it. Raff Object Storage currently costs $7/month, including 100 GB storage and 1 TB monthly egress, with unlimited API requests; additional storage is $0.07/GB-month and additional egress is $0.01/GB.
That pricing is useful for planning retained artifacts, but storing a file in object storage does not prove database recoverability. The backup still needs integrity checks and a tested restore procedure.
Restore testing proves the recovery target
A backup that has never been restored is an unverified recovery option.
Restore testing should prove the complete path:
Choose recovery point ↓ Restore into isolated target ↓ Start database ↓ Validate schemas and known records ↓ Connect application safely ↓ Run critical read/write checks ↓ Measure recovered data age and total recovery time ↓ Document gaps
The recovered data age validates RPO. The time until the application can complete critical workflows validates RTO.
A database service starting successfully is not enough. The test should answer:
- Is the expected schema present?
- Are recent known records present for that recovery point?
- Can application credentials connect?
- Are migrations in the expected state?
- Can a safe write complete in the isolated environment?
- Can related object-storage files still be resolved where the app depends on them?
- How long did the complete recovery take?
- Which manual steps delayed the process?
Run the restore away from production when possible. A temporary recovery environment should not send production email, payment events, webhooks, scheduled jobs, or other customer-facing side effects.
The practical first-hand lesson from Raff deployment work is consistent: backup creation is rarely the hardest part; restore ownership and application validation are where uncertainty appears. A named recovery owner and a timed restore test reduce that uncertainty more than another untested backup copy.
Use Restore Testing Checklist for Production VMs for the wider server-level verification path.
Database migrations need an explicit recovery point
Database migrations combine application change with data change, so they deserve a dedicated recovery decision.
Before a destructive or high-risk migration, the team should know:
- which recovery point will be used if rollback is required;
- whether the backup or PITR chain is current;
- how long restoration is expected to take;
- whether the application can run against the restored schema;
- what happens to writes created after the recovery point;
- who decides to continue or roll back.
A pre-migration snapshot can provide useful infrastructure rollback around a self-hosted database, but it should not replace the database-aware recovery path. Likewise, an application rollback may not reverse a schema or data migration safely.
For managed databases, create the recovery point or confirm PITR coverage before the change. For self-hosted databases, confirm that the required backup and transaction logs exist outside the host and that the restore procedure has been exercised.
The migration is not low-risk merely because the migration command is reversible on paper. Recovery readiness depends on the real production data shape and the ability to restore it.
Raff maps database recovery to managed and self-hosted paths
Raff supports two different responsibility models for SaaS databases.
For managed PostgreSQL and MySQL, current Raff plans start at $7.99/month. Managed PostgreSQL includes nightly base backups plus continuous WAL archiving for point-in-time recovery to any minute. Managed MySQL includes nightly XtraBackup plus continuous binary-log upload for point-in-time recovery to any minute. Backups, private networking, and monitoring are included in the plan model.
A managed path looks like:
Raff VM or Raff Apps ↓ private or restricted connection Raff Managed Database ↓ Managed backup + PITR workflow ↓ Customer validates restored data and app cutover
A self-hosted path looks like:
Raff VM for app ↓ private network Raff VM for database ↓ Customer-operated database-aware backups ↓ Separate retained recovery storage ↓ Restore test environment
Use Raff Managed Databases when the team wants database backup, monitoring, patching, networking, and recovery tooling operated within a managed service boundary. Use Raff VM when the team needs full database-host control and can own backup monitoring, PITR configuration, retention, restoration, patching, and incident response.
For self-hosted backup artifacts, Raff Object Storage can provide S3-compatible retention outside the database VM. For infrastructure-level VM protection, Raff Data Protection provides snapshots and scheduled backups. Keep those infrastructure recovery points distinct from the database-native backup strategy.
Database recovery works when targets are tested
A SaaS database backup strategy should begin with the failure the business needs to survive. Define RPO and RTO, then select database-aware backups, PITR, retention, availability controls, infrastructure recovery points, and isolated copies that meet those targets.
Managed services reduce operational work, but they do not remove customer responsibility for safe migrations, restore-point selection, data validation, credentials, and application cutover. Self-hosting gives more control, but the team must own the entire recovery chain.
The most important evidence is a successful restore with measured data age and recovery time. Continue with Storage and Recovery Architecture for Production Apps for the full production model and Restore Testing Checklist for Production VMs for recovery validation.