We make daily backups of all MySQL databases and keep the backup files for at least seven days, as explained on our backup policy page.
On this page:
Before you read any further, remember that no backup system can offer complete protection against MySQL database corruption, a script that fails to insert information into a database due to a bug, or similar problems.
If you store financial transactions or other critical information in your database, make sure you have access to a second copy of the data. For example, you might configure a shopping cart program to e-mail you a copy of each order (without the credit card information, of course). In the event of a MySQL problem, your data could be recreated using a combination of the e-mail messages and the credit card numbers on file at your card processing company.
The main MySQL backup we provide is an automatic, daily mysqldump backup.
Please enter your domain name above to see the exact path to the backup files.
You can make an extra backup copy of your database by setting up an additional FTP account that has access to your "home directory", then using a normal FTP program to copy this file onto your own computer.
You can also use the file to restore a database yourself from the command line if you're comfortable with that (you'll find detailed command line instructions in a file named "README" in the directory mentioned above).
If you aren't comfortable with the command line, or you need to restore an older version of your database, you should contact us. We'll be glad to do it for you (if you ask us to restore a database more than once because of a mistake you made, a fee may apply).
Another way to make backups of your database at any time is to use phpMyAdmin. Simply login to the phpMyAdmin screen, then:
In addition to daily "dump" backups, we use the MySQL binary log feature to log all commands that change a database. Our goal is to store the binary log files for seven days. We can't guarantee it, because we're occasionally forced to store less data in cases of heavy database activity caused by "runaway" scripts, but that's rare.
The binary logs usually make it possible for us to restore a database to any moment in time from the last seven days, or to send you a log of all database changes over that period.
If you need this service, please contact us. Note that restoring a database in this manner is a time-consuming, manual process for our staff, and an extra fee applies.
One of the quirks of MySQL is that if your database uses the default MyISAM table type, scripts are "blocked" from making changes to a given table while that table is being backed up.
With a small database, this won't be a problem. It takes only a few seconds to make a backup, so the only consequence is that once a day (around 1 AM Pacific time) your scripts might run for a few extra seconds if they try to save data in the database while the backup is being made. It won't cause any harm.
With larger database tables (more than 100 MB or so), this can start to be a problem. As a rough average, it takes about one minute to backup each 500 MB of data, so it's possible for your scripts to be blocked for some time while the backup runs. That can cause errors with some scripts or Web browsers.
If you have MyISAM tables that exceed 100 MB in size, our backup system tries to minimize the impact by locking individual tables as they're backed up, instead of locking the whole database from start to finish. That significantly reduces the time that most tables are locked, although the backup no longer contains a single snapshot of the whole database (it contains a series of snapshots of individual tables instead). If you're a database expert, this may seem like a problem, because it can create backups that aren't "isolated" — but MyISAM tables don't provide isolated "ACID" transactions to start with, so that issue could happen anyway.
The real solution to this problem is to use the InnoDB table type for all tables in your database. If you do so, our backup system can use a special "mysqldump" option ("--single-transaction") to backup your database without causing any scripts to be blocked. Every table in the database has to be an InnoDB table for this to work reliably.
The MySQL Web site has instructions explaining how to convert tables to InnoDB, but be aware that doing so can take a long time. We've seen it take up to an hour for large tables. If you do this, we recommend temporarily disabling the part of your site that uses the database during the conversion.
If any single table in your database exceeds 1 GB in size, our backup system will skip that table to avoid locking your database for an extended period.
It's extremely unlikely that this will happen (only about 0.02% of our customers create tables this large). If it does happen to you, we'll notify you and help you make different arrangements for backing up the table.
Occasionally, technically advanced customers want to create their own backup that exactly duplicates the format of our standard daily backups (so they can easily check for differences, for example).
The exact command our system uses depends on whether all the tables in the database are of type "InnoDB". If they are, it uses this command:
mysqldump --add-drop-table --add-locks --all \ --extended-insert --quick --routines --single-transaction \ --databases DATABASE_NAME > DATABASE_NAME.dump
(Where "DATABASE_NAME" is the name of the database, of course.)
If any tables in the database are not InnoDB (if even one of them is MyISAM, for example), we use this instead for databases under 100 MB:
mysqldump --add-drop-table --add-locks --all \ --extended-insert --quick --routines --lock-tables \ --databases DATABASE_NAME > DATABASE_NAME.dump
(In other words, "--single-transaction" is replaced with "--lock-tables".)
Finally, if the database has MyISAM tables and is larger than 100 MB, we use this command:
mysqldump --add-drop-table --add-locks --all \ --extended-insert --quick --routines \ --databases DATABASE_NAME > DATABASE_NAME.dump
This skips "--lock-tables" to minimize script timeouts, as described above.