Database Backup
MySQL Backup Best Practices: A Complete Guide
Logical vs physical MySQL backups, consistent dumps with InnoDB, binary logs and point-in-time recovery, retention and restore testing.
Your database is usually the most valuable and the most fragile part of your infrastructure. Backnix is designed to create consistent backups with the native tools of each engine, then compress, encrypt and store them offsite.
Databases keep data in memory, write to several files at once and rely on transaction logs. Copying the data directory of a running server, or a dump taken without a consistent snapshot, can capture tables in different moments of time. The file looks fine until you try to restore it.
Orders without customers, invoices without items, or tables that fail to import.
Backups that take hours can lock tables or slow down production if done the wrong way.
A nightly dump alone cannot bring back the transactions made between the backup and the incident.
When a database cannot be restored, the business loses its most recent and most valuable information: today's sales, new sign-ups, payments and support history. Even a successful restore of an old backup means re-entering data or explaining to customers why it disappeared.
Backnix is designed to run the right tool for each engine with consistency options enabled, stream the result through compression and client-side encryption, and upload it to S3 storage. Backups are tracked per database so you can see age, size and status at a glance.
Transactional logical dumps for InnoDB tables, with physical backup tools as an option for large datasets.
pg_dump for logical backups and support for WAL-based strategies when point-in-time recovery is required.
Dumps compress very well; encryption happens before the data leaves the server.
The diagram shows the designed architecture; availability is listed below.
Consistency options are part of the backup, not an afterthought.
Databases get their own schedule, retention and alerts.
Compressed logical backups typically use a fraction of the original data size; the exact ratio depends on your data.
Know which backup to use and how to load it before an incident happens.
For InnoDB tables, mysqldump --single-transaction and mariadb-dump --single-transaction read all tables from one consistent snapshot without blocking writes. MyISAM tables do not support transactions and need locking. PostgreSQL's pg_dump always works on a consistent snapshot. For very large databases or point-in-time recovery, physical backups (Percona XtraBackup, MariaDB Backup, pg_basebackup) combined with binary logs or WAL archives are the better fit. Whatever the method, test restores regularly.
Consistent MySQL backups using native tools.
Consistent MariaDB backups using native tools.
PostgreSQL backups with pg_dump and WAL-based strategies.
Run backups automatically on a schedule.
Status is updated as capabilities are released. See all features.
Database Backup
Logical vs physical MySQL backups, consistent dumps with InnoDB, binary logs and point-in-time recovery, retention and restore testing.
Database Backup
Automate PostgreSQL backups with pg_dump, pg_dumpall and pg_basebackup, add WAL archiving for point-in-time recovery and test your restores.
Database Backup
Consistent MariaDB backups with mariadb-dump and mariadb-backup, scheduling, binary logs, validation and restore procedures.
Compare storage plans in USD or BRL. Yearly plans include 50% off the first annual payment.
Tell us what you need to protect. We will answer by email; nothing is charged.