Database Backup and Recovery

Backup makes copies of data that can be restored after failure, corruption, error or attack. Recovery restores a database to a consistent state, ideally to a chosen point in time.

The recovery point objective is how much data loss is acceptable, measured as time since the last good copy. The recovery time objective is how long recovery may take. Tighter objectives need more frequent backups, continuous archiving and standby systems.

Restoring a database to a specific moment by combining a base backup with archived transaction logs. PostgreSQL documents it under continuous archiving, and Amazon RDS and Cloud SQL provide it as a managed feature.

Logical backups, such as pg_dump or mongodump, export data as statements or documents and are portable across versions. Physical backups copy data files or blocks, such as pg_basebackup or Percona XtraBackup, and are faster to restore for large databases.

No. Replicas copy deletions, corruption and malicious changes as well, so you need separate, tested backups. See the Database Replication page.

Regularly. A backup that has not been restored in a test is unproven. Automate restore tests to a scratch environment and check the data and the recovery time against your objectives.

Links and release facts were checked on 31 October 2026 from GitHub. The MySQL documentation, Rubrik and Druva returned 403 to automated checks, and a Cassandra backup documentation link that returned 404 was dropped. Descriptions follow each project's or vendor's own pages and are not rankings.

See the Database Security page for access control, encryption, auditing, masking, SQL injection prevention, cloud database security features and hardening guides.