BACKUP TABLE tbl_name[,tbl_name...] TO '/path/to/backup/directory'

Копирует в каталог резервного копирования тот минимум табличных файлов, 
который достаточен для восстановления таблицы, после сброса на диск всех изменений. На данный момент работает только для таблиц MyISAM. Для таблиц 
MyISAM копирует файлы `.frm' (определений) и `.MYD' (данных). Индексные 
файлы могут быть реконструированы по этим двум.


Перед использованием этой команды, пожалуйста, ознакомьтесь с разделом See section  4 . 4 . 1  Резервное копирование баз данных.


В процессе резервного копирования будет установлена блокировка чтения 
отдельно для каждой таблицы на время ее копирования. Если необходимо 
сделать резервное копирование в виде мгновенного образа нескольких таблиц,
 необходимо сначала запросить LOCK TABLES установки блокировки чтения для
 каждой таблицы в группе.


Команда возвращает таблицу со следующими столбцами:
Столбец 	Значение
Table 	Имя таблицы
Op 	Всегда ``backup''
Msg_type 	Одно из значений status, error, info или warning.
Msg_text 	Само сообщение.

Заметим, что BACKUP TABLE доступна только в версии MySQL  3 . 23 . 25  и выше. 

 7 . 5 . 6  Создание резервных копий и восстановление баз данных InnoDB

Чтобы обеспечить безопасное управление базами данных, необходимо регулярно создавать резервные копии.

Существует интерактивный инструмент, который можно использовать для создания резервных копий своих 
баз данных InnoDB, когда они открыты, - InnoDB Hot Backup. Для своей работы InnoDB Hot Backup не требует 
закрытия базы данных, блокировки данных или нарушения обычного хода обработки базы данных. 
InnoDB Hot Backup является платным дополнительным инструментом, не входящим в стандартный 
дистрибутив MySQL. Чтобы получить дополнительную информацию о нем и просмотреть копии экрана, см. домашнюю
страницу InnoDB Hot Backup http://www.innodb.com/hotbackup.html.

Если у вас есть возможность остановить сервер MySQL, а затем создать двоичную резервную копию своей базы
данных, необходимо выполнить следующие действия:

    * Закройте свою базу данных MySQL и убедитесь, что закрытие было произведено без ошибок.
    * Скопируйте все свои файлы данных в безопасное место.
    * Скопируйте все свои файлы журналов InnoDB в безопасное место.
    * Скопируйте свой файл конфигурации `my.cnf' в безопасное место.
    * Скопируйте все файлы `.frm' своих таблиц InnoDB в безопасное место. 

В дополнение к двоичным резервным копиям, описанным выше, необходимо также регулярно создавать дампы своих
 таблиц при помощи mysqldump. Дело в том, что повреждение двоичного файла человеку заметить сложно. Дампы 
таблиц сохраняются в текстовых файлах, которые могут прочитать люди и структура которых намного проще 
двоичных файлов базы данных. Увидеть повреждение таблицы в файле дампа легче, и благодаря простоте этого 
формата вероятность серьезного повреждения данных меньше.

Дампы лучше всего создавать одновременно с созданием двоичной резервной копии своей базы данных. Чтобы 
получить согласованную копию всех своих таблиц в дампах, необходимо запретить всем клиентам доступ к 
базе данных. Затем можно создать двоичную резервную копию и получить согласованные копии своей базы данных в двух форматах.

Чтобы восстановить исходное состояние своей базы данных InnoDB из описанной выше двоичной резервной 
копии, необходимо запустить свою базу данных MySQL с включенными общим журналом и архивацией журналов 
MySQL (здесь под общим журналом подразумевается механизм занесения записей в журнал сервера MySQL, 
независимый от журналов InnoDB).

Единственное, что нужно сделать для восстановления процесса MySQL после сбоя, - перезапустить его. 
InnoDB автоматически произведет проверку журналов и выполнит восстановление базы данных, а также 
автоматически произведет откат по незавершенным транзакциям, которые проводились на момент сбоя. 
Во время восстановления InnoDB будет выводить примерно следующую информацию:

~/mysqlm/sql > mysqld
InnoDB: Database was not shut down normally.
InnoDB: Starting recovery from log files...
InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number  0   13674004 
InnoDB: Doing recovery: scanned up to log sequence number  0   13739520 
InnoDB: Doing recovery: scanned up to log sequence number  0   13805056 
InnoDB: Doing recovery: scanned up to log sequence number  0   13870592 
InnoDB: Doing recovery: scanned up to log sequence number  0   13936128 
...
InnoDB: Doing recovery: scanned up to log sequence number  0   20555264 
InnoDB: Doing recovery: scanned up to log sequence number  0   20620800 
InnoDB: Doing recovery: scanned up to log sequence number  0   20664692 
InnoDB:  1  uncommitted transaction(s) which must be rolled back
InnoDB: Starting rollback of uncommitted transactions
InnoDB: Rolling back trx no  16745 
InnoDB: Rolling back of trx no  16745  completed
InnoDB: Rollback of uncommitted transactions completed
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Apply batch completed
InnoDB: Started
mysqld: ready for connections

Если ваша база данных повреждена или произошел сбой диска, необходимо 
произвести восстановление из 
резервной копии. В случае повреждения сначала необходимо найти целую 
резервную копию, а из резервной копии произвести восстановление по файлам 
общего журнала MySQL в соответствии с инструкциями руководства MySQL.

 7 . 5 . 6 . 1  Контрольные точки

В InnoDB реализован механизм контрольных точек, который получил название нечеткой контрольной точки. 
В InnoDB измененные страницы базы данных сбрасываются из буфера на диск небольшими частями. 
Сбрасывать содержимое буфера одним большим пакетом нет необходимости, так как это приведет к временной 
остановке обработки операторов пользователей.

В случае восстановления после сбоя InnoDB производит поиск меток контрольных точек, записанных в файлы 
журналов. Известно, что все изменения базы данных, внесенные перед меткой, уже записаны в образ базы 
данных на диске. Затем InnoDB производит сканирование файлов журналов начиная от места контрольной 
точки, и вносит зафиксированные изменения в базу данных.

Запись в файлы журналов в InnoDB осуществляется по круговому методу. Все внесенные изменения, после 
которых страницы базы данных в буфере начинают отличаться от образа на диске, должны быть записаны в 
файлы журналов, на случай, если InnoDB понадобится произвести восстановление. Это означает, что когда 
InnoDB начинает повторно использовать файл журнала по круговому методу, производится проверка на 
наличие в образах страниц базы данных на диске изменений, зафиксированных в файле журнала, который 
InnoDB собирается повторно использовать. Иначе говоря, необходимость поставить контрольную точку 
зачастую приводит к тому, что InnoDB сбрасывает измененные страницы базы данных на диск.

Из сказанного выше становится понятно, почему при больших файлах журналов сокращается количество 
дисковых операций ввода/вывода при создании контрольных точек. Иногда имеет смысл задавать общий 
размер файлов журналов равным буферному пулу или даже больше. Недостатком больших файлов журналов 
является то, что восстановление после сбоя может длиться дольше, так как к базе данных придется 
применить больше информации из файла журнала.