Database Backups Explained What Hosts Do and What You Must
Database backups are the part of hosting that many providers automate and almost no provider explains, so the short answer to what your host does is: it depends on the plan, the control panel, and the fine print. The longer answer is that you must treat any automated backup as a convenience, not a guarantee, and you need to verify both the backup and the restore path yourself before you ever need it. This article walks through the mechanics of database backups hosting, what your host likely runs, where the gaps are, and the exact commands you can use to test your own safety net.
What Your Host Probably Runs Automatically
Most managed hosting environments run a scheduled job that dumps each database to a flat file, then stores that file on a separate volume or an offsite object store. On a typical Linux server that means mysqldump for MySQL or MariaDB, and pg_dump for PostgreSQL. The dump file is a plain text file containing SQL statements that recreate the schema and insert the data. The host will often compress that file with gzip or bzip2 to save space, and then rotate the backups so that only the last N days or N copies survive.
The critical detail is the protocol used to trigger the dump. A well designed host uses the database's native client protocol, not a filesystem copy. That means the dump is consistent at the SQL level, and it captures the state of the database as of the moment the dump starts. If the host instead copies the underlying data files while the database is live, you can end up with a corrupted backup that silently fails on restore. You can check which method your host uses by looking at the backup file itself. A mysqldump output starts with a version comment and a SET statement, while a raw data file copy has no such header.
-- MySQL dump 10.13 Distrib 8.0.36, for Linux (x86_64)
--
-- Host: localhost Database: myapp
-- ------------------------------------------------------
-- Server version 8.0.36
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT /;
/!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
That header is your first clue. If you see it, the host is using the proper dump protocol. If you open the file and see binary gibberish or a directory listing, be suspicious.
The Gaps in Automatic Backups You Must Close
Even when your host runs a perfect daily dump, there are three gaps that will catch you. First, the schedule. Most hosts back up once every 24 hours, often in the early morning. If your database is write heavy, you lose up to 24 hours of data in a crash. For many small sites that is acceptable, but for an ecommerce store or a SaaS dashboard it is not. Second, the retention window. A host that keeps only seven daily backups cannot help you when a corruption goes unnoticed for two weeks. You need your own longer term archive. Third, the restore path. The host may offer a one click restore in the control panel, but that restore often targets the same database server and the same database name. If you need to restore to a different server, a different version of MySQL, or a different database name, you are on your own.
The practical fix is to run your own backup job on top of the host's job. You do not need to replace the host's automation, you need to supplement it. Write a cron job that dumps your database to a file, compresses it, and copies it to a location outside the host's infrastructure, such as an object storage bucket you control. That gives you a backup that is independent of the host's schedule, retention, and restore tooling. The command is simple enough to run by hand first, then wrap in a script.
mysqldump --single-transaction --quick --lock-tables=false \
-u backup_user -p myapp_db | gzip > /backups/myapp_$(date +%F).sql.gz
The --single-transaction flag is essential for InnoDB tables because it produces a consistent snapshot without locking the entire database. The --quick flag streams the output row by row instead of buffering it in memory. The redirect to gzip compresses on the fly. Run that command, then verify the output file is non empty and starts with the expected header. A zero byte file is a failed backup, and you want to discover that now, not on the day you need it.
How to Verify a Database Backup Without Destroying Anything
Verification is not about checking that the file exists. It is about proving that the file can be restored into a working database. The safest way is to restore into a temporary database on a separate server or a local development machine. You never restore into your production database just to test, because the restore will overwrite existing data. Instead, create a new database with a test name, then pipe the backup file into the client.
mysql -u root -p -e "CREATE DATABASE restore_test"
gunzip < /backups/myapp_2025-01-01.sql.gz | mysql -u root -p restore_test
mysql -u root -p -e "SELECT COUNT(*) FROM restore_test.users"
That sequence creates a fresh database, restores the dump into it, and runs a count query on a known table. If the count matches your expected row count, the backup is valid. If the restore fails with a syntax error or a foreign key violation, you have a broken backup and you need to fix your dump command or contact your host. Do this at least once per month, and always before you trust a new backup schedule.
The Restore Path You Must Know Before an Emergency
Your host's control panel may offer a restore button, but you should also know the manual restore path in case the panel is down or the host's tooling fails. For MySQL, the restore is the reverse of the dump. You create a database, then feed the dump file back in. For PostgreSQL, the command is psql with the database name, and the dump format matters. A plain SQL dump is portable across servers, while a custom format dump requires pg_restore. Ask your host which format they use, or check the first line of the dump file. If it says pg_dump and the file is text, use psql. If it says pg_dump and the file is binary, use pg_restore.
The other restore path you must test is the one that goes from your own backup file, not the host's. That means you need to know the exact database name, the user credentials, and the hostname of the target server. Write those down in a runbook. When the emergency hits, you will not want to think, you will want to execute. A good runbook has the commands, the expected output, and the rollback steps if the restore goes wrong.
What to Do Next
Start with a single test. Run the mysqldump command from this article against your smallest database, check the header, and restore it into a temporary database. That one exercise will teach you more than reading any host's documentation, and it will expose the gaps in your current setup. Then set a monthly calendar reminder to repeat the test with a fresh dump. Do not wait for a crisis to discover that your host's backup is a myth or that your own script has a typo. A database backup that has never been restored is not a backup, it is a hope.
