This page is for DBAs, infrastructure teams and engineering leads choosing how to back up and restore production databases. It covers four quite different kinds of product: enterprise platforms that protect virtual machines, servers and databases from one console; Windows tools built only for SQL Server; free command-line backup managers for self-managed PostgreSQL and MySQL; and cloud services that manage snapshots and retention for managed databases.
The right choice depends less on features than on what you run and where. A PostgreSQL cluster on your own servers, a SQL Server estate on Windows, an Oracle and SAP HANA estate in a data centre and a set of Amazon RDS instances each point to a different shortlist, and many organisations end up with more than one tool.
What this software does
Database backup is not the same as copying files. A running database changes its data files constantly, so a usable backup must be consistent: either a logical export (SQL or a dump format, as made by pg_dump or mysqldump), a physical copy taken through the engine's own mechanism (SQL Server BACKUP, Oracle RMAN, PostgreSQL base backups, InnoDB hot copies), or a storage or VM snapshot coordinated with the engine so it is application-consistent. Physical backups restore much faster for large databases; logical dumps are portable across versions and platforms.
Point-in-time recovery (PITR) combines a full backup with the engine's change log: SQL Server transaction log backups, PostgreSQL write-ahead log (WAL) archiving, MySQL binary logs or Oracle archived redo logs. Replaying the log lets you restore to the moment before an accidental DELETE rather than to last night's backup. How often the log is shipped off the server sets your recovery point objective (RPO, how much data you can lose); restore speed, instant mount features and the size of the database set your recovery time objective (RTO, how long you are down).
Around that core, products differ in incremental methods (file level, block level, changed block tracking), compression and deduplication, encryption, where copies go (disk, object storage, tape, a separate cloud account), retention schemes such as grandfather-father-son, immutable or air-gapped copies that ransomware cannot delete, and whether restores are verified automatically. A backup that has never been restored is an assumption, not a recovery plan.
Types of product in this category
- Enterprise data protection: Platforms such as Veeam Backup & Replication, Commvault Cloud, Rubrik Security Cloud and Cohesity NetBackup that protect VMs, servers, SaaS and databases under one policy engine, using database agents or plug-ins for application-consistent backups and log-based recovery.
- Cloud backup service: A managed service, here AWS Backup, that applies backup plans, retention and vaults to a provider's own database services, with no backup servers to run but no coverage outside that cloud.
- SQL Server backup tool: Windows products built only for SQL Server, such as SQL Backup Pro and SQL Safe Backup, that add compression, encryption, central policies, verification and cloud copies on top of native SQL Server backups.
- Database backup tool: A simple scheduler, here SQLBackupAndFTP, that runs backups of a few databases on one Windows machine and sends the files to folders, FTP or cloud storage.
- Open source database backup: Free command-line tools for one engine family, such as pgBackRest, Barman, WAL-G and Percona XtraBackup, that take physical backups and archive logs for PITR; scheduling, monitoring and restore drills are up to you.
Typical use cases
Recovering from a bad change
A deployment script or a manual UPDATE without a WHERE clause damages a table. With log backups or WAL archiving in place, you restore to a point just before the change, often to a separate server first so you can copy back only the affected rows.
Ransomware and insider deletion
Attackers increasingly delete or encrypt backups before the production data. Immutable repositories, logically air-gapped vaults and separate credentials for the backup system, as offered by the enterprise suites and AWS Backup, keep at least one copy out of reach.
Large self-managed PostgreSQL or MySQL
A multi-terabyte cluster where nightly logical dumps take too long to restore. Physical backups with incrementals (pgBackRest block incremental, Barman, WAL-G deltas, XtraBackup incrementals) plus continuous log archiving to object storage keep both RPO and RTO practical.
SQL Server estates on Windows
Dozens of instances that need consistent schedules, compression, encryption, log shipping and verified restores. Dedicated SQL Server tools manage this from one console; enterprise suites do it alongside VM and file backups.
Mixed data centre estates
Oracle, SQL Server, SAP HANA, Db2 and VMs in one environment, often with tape or long-term retention requirements. This is where broad agent coverage, as documented by Commvault, Cohesity, NetBackup and Bacula Enterprise, matters most.
Managed databases in AWS
RDS and Aurora already take automated backups, but organisations add AWS Backup to apply one retention policy across accounts and Regions, copy backups to another account and run scheduled restore tests. See our RDS backups guide for the native options.
How to choose
- Engine and platform coverage. Check the vendor's support matrix for your exact engines, versions and operating systems, not the logo wall. Coverage is often uneven: for example, Veeam documents application-aware processing for SQL Server, Oracle and PostgreSQL but handles MySQL through scripts or its Linux agent, and SQL Backup Pro's published requirements stop at SQL Server 2022.
- Point-in-time recovery. Confirm PITR engine by engine and how it works: native log backups, WAL or binlog archiving, or snapshots only. Several vendors document PITR for SQL Server but not for every other engine, and AWS Backup does not offer PITR for RDS Multi-AZ clusters or for copied backups.
- Recovery time, not just backup speed. Ask how a restore actually runs: full copy back, delta restore, instant mount of a backup as a live database, or virtual databases. For large databases the difference between minutes and hours is in the restore path, so time a real restore of your biggest database during evaluation.
- Immutability and isolation. Look for immutable repositories, object lock, logically air-gapped vaults, separate administrator credentials and multi-person approval for deletions. Check that retention locks cannot be shortened by a compromised admin account.
- Restore verification. Scheduled test restores, automatic DBCC CHECKDB after restore (as SQL Backup Pro offers) or AWS Backup restore testing turn a backup into evidence. With open source tools you script these drills yourself, so budget the time.
- Storage targets and copies. Check native support for the targets you need (S3-compatible, Azure Blob, Google Cloud Storage, tape, appliances), several repositories with different retention, and cross-Region or cross-account copies. Note that some tools copy files to the cloud after the backup rather than writing to it directly.
- Managed versus self-managed databases. Physical backup tools need access to the server's data directory, so pgBackRest, Barman and XtraBackup do not apply to Amazon RDS or Azure SQL Database. For managed services, compare the provider's native backups and services such as AWS Backup instead.
- Licensing model. Meters vary widely: per workload or instance, per front-end terabyte of protected data, per server, or not based on data volume at all. Model cost at today's size and at two or three times that size, and note that most enterprise vendors publish no list prices.
- Vendor and project continuity. Backups outlive purchasing decisions. Check release cadence, version support and ownership: NetBackup is now sold by Cohesity after the December 2024 Veritas combination, Percona XtraBackup 8.0 reached end of life in June 2026, and open source tools depend on sponsors or a maintaining company.