|
|
Cry MySQL How to...Backup a MySQL databaseThese notes cover different ways to perform a backup of a MySQL database.
Backup Individual Tables (MyISAM)These notes use "backup table" which should be considered as depreciated and may be completely removed in MySQL 5.2. For a more future proof method see "How to backup individual tables using mysqldump". To backup an individual table the sequence is to lock the table, flush any unwritten data, copy the table and then remove the lock. This can be accomplished using the following script: lock table table-name read; flush table table-name; backup table table-name to 'folder'; unlock tables; Where "table-name" is the name of the table to be backed up and "folder" is the name of the folder to which the backup copy will be written. Note:
To restore a table use: restore table table-name from 'folder'; be aware that the restore will fail if a table already exists with that name. How to backup individual tables using mysqldumpTo backup an individual table from the command line, use mysqldump. The syntax is:
Where:
In this instance mysqldump will generate the SQL to create the table followed by SQL to populate the data that is currently in the table. Since it is SQL which is generated, the table can be restored by simply replying the SQL, for example:
Be aware that this will drop the existing table and recreate it (complete with data). If you don't want the table dropped then you will need to edit the sql contained in backup-file.sql. Backup an Entire Database - To a Single FileTo backup an entire database (or all databases) use the "mysqldump" utility (which is run from the command line):
Where "account" is the account to connect to the database, "password" is the password to use, "host" is the name of the server on which the database is located, "database" is the name of the database to backup and "backup-file" is the name of the sql file that will be generated. You can omit the "--host=host" bit if you want to backup the mysql database on the local computer. If you omit the name of the database then all the databases will be backed up. What mysqldump does is to generate SQL to recreate the database, all
the tables and all the records in those tables. This is the reason why the
output is piped to a file. mysqldump supports many other options and its
worth consulting the manual for these - for example you can use it to dump/backup
individual database tables (using mysqldump takes a number of other options (for example it can also be used to backup a single table), and it may be worth consulting the documentation for other options (of which there are many). To restore from this backup simply apply the SQL that mysqldump generated. For example:
Backup an Entire Database - Separate Files per TableAs an alternative to generating a single output file, mysqldump can also be used to generate separate files for each database table. The syntax in this case is:
This is similar to the previous example except that mysqldump will generate backup files in the "backup-folder" specified. In this case two files will be generated for each table, a .sql and a .txt file both named after the name of the table:
An important point to be aware of is that the .sql file is generated by mysqldump whereas the .txt file is generated by mysql. So the folder location needs to be one which mysql can find and has permissions to write to. (So for example if you are backup up to "C:\Backups" and MySQL is on a different machine then you risk having the .txt files generated on the server and not locally on your pc.) To restore from such a backup you will need to use a combination of mysql and mysqlimport - mysql to run the scripts to recreate the tables and mysqlimport to import the data. So, to recreate each table:
this will need to be done for each table. Remember that the .sql files created only contain the table definition, not the data and for the data you need to use mysqlimport the syntax of which is:
Don't be tempted to change the names of the .txt files because mysqlimport uses the name of the file to determine which table to import into. You can specify multiple txt files to import. As you can see when performing a restore this technique is more cumbersome than using the single file backup approach, but it does have its uses. Whichever technique you use (and unless you have a good reason otherwise I would advocate the single file approach) be sure to test both your backup and restore. These notes have been tested against MySQL version 4.1, 5.0 and 5.1. |