Decision: Which backup strategy?
A backup strategy is chosen by balancing three factors: how much data loss you can tolerate (RPO), your data size, and how quickly you must recover (RTO). No single method fits every scenario. Starting from the RPO target, this tree guides you between logical dumps, physical backups + PITR, and snapshots, and reminds you that 3-2-1 and verification are non-negotiable.
What is your data loss target (RPO)?
Start with the most decisive constraint: in a disaster, how many minutes/hours of data can you afford to lose? If near-zero data loss is required, continuous log archiving (PITR) is mandatory; if daily/weekly backup tolerance is acceptable, simpler methods are enough. RPO defines the framework of the strategy.
- Near zero — I must be able to return to any point in time
- Daily/periodic backups (a few hours of loss) are acceptable
- First remind me of general best practice (3-2-1 / verification)
What are the data size and portability requirements?
If periodic backups are enough, the next question is scale and purpose: is the database small/medium and do you want the backup to be portable to another environment/version, or is the data large and your main concern getting back within minutes? This decides between a logical dump and a snapshot.
- Small/medium, portable and compatible across versions
- Large data, recovery must be very fast (low RTO)
Recommendation: Logical dump
Exports data at the logical level (schema definitions + rows); the output is either SQL/text (pg_dump plain format, mysqldump) or a tool-specific binary dump (pg_dump -Fc, Oracle Data Pump). A flexible and portable method for small and medium databases, migrations, version upgrades, and recovery of selected tables/objects.
Recommendation: Physical backup + WAL/archived logs (PITR)
You take regular physical base backups and continuously archive the transaction logs (WAL/redo/binlog). This lets you perform Point-in-Time Recovery to any moment and reduce data loss to near zero.
Recommendation: Snapshot
Takes a block-level snapshot of the data at the storage or virtualization layer. Backup and restore are very fast even for very large databases; however, it depends on the infrastructure and requires careful use.
Recommendation: 3-2-1 rule + offsite + mandatory verification
Whatever method you choose, these principles must sit on top of the strategy. The mere existence of a backup is not enough; it must be on different media, in a different location, and tested regularly. This is a framework that complements all of the options above.