В системах с высокими нагрузками особое внимание следует уделять резервному копированию (бекапам) данных. Зачастую самая важная часть данных находиться в СУБД. Проблема заключается в том, что копирование данных нужно проводить незаметным для работающей системы образом. Блокировка данных на момент создания бекапа тут не работает, т.к. время блокирования будет неприемлемым.

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

Другой подход резервного копирования - это использование специальных утилит, которые позволяют делать снимки состояния СУБД на жесткий диск, и восстанавливать состояние обратно по такому снимку. На этом остановимся подробнее.

Поскольку MySQL является одним из самых популярных решений в Web’е сегодня, рассмотрим инструменты для бекапов для этой СУБД.
XtraBackup - это утилита от Percona Labs, предназначенная для горячих бекапов таблиц InnoDB и XtraDB.

Установка

Качаем самую свежую версию отсюда и устанавливаем:

wget http://www.percona.com/mysql/xtrabackup/0.9/deb/xtrabackup_0.9_amd64.deb
dpkg --install xtrabackup_0.9_amd64.deb

Готово. После этого станет доступна утилита xtrabackup, с помощью которой и делаются бекапы.

Создание бекапов

Xtrabackup создает копии файлов данных таблиц innoDB (xtraDB), а также текущего бинлог файла. Для начала нужно создать директорию для бекапов:

mkdir /home/backup/db

Для запуска процесса создания бекапа:

xtrabackup --defaults-file=/etc/mysql/my.cnf --datadir=/var/lib/mysql \
 --target-dir=/home/backup/db --backup

Некоторые пояснения:

• –defaults-file - путь к конфигурационному файлу MySQL
• –datadir - путь к папке данных MySQL
• –target-dir - директория для бекапов

Спустя определенное время (зависит от размера данных), получим снимок в папке для бекапов, из которого можно восстановится:

xtrabackup  Ver 0.9 Rev 83 for 5.0.84 pc-linux-gnu (x86_64)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql
xtrabackup: Target instance is assumed as followings.
xtrabackup:   innodb_data_home_dir = ./
xtrabackup:   innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup:   innodb_log_group_home_dir = ./
xtrabackup:   innodb_log_files_in_group = 2
xtrabackup:   innodb_log_file_size = 134217728
xtrabackup: use O_DIRECT
>> log scanned up to (0 1283875749)
Copying ./ibdata1
     to /home/backup/db/ibdata1
>> log scanned up to (0 1283877656)
>> log scanned up to (0 1283878467)
>> log scanned up to (0 1283880148)
>> log scanned up to (0 1283881355)
>> log scanned up to (0 1283883263)
>> log scanned up to (0 1283885187)
>> log scanned up to (0 1283887688)
        ...done
xtrabackup: The latest check point (for incremental): '0:1283888607'
>> log scanned up to (0 1283890956)
xtrabackup: Stopping log copying thread.
xtrabackup: Transaction log of lsn (0 1283872324) to (0 1283890956) was copied.

Восстановление из бекапов

Для восстановления, необходимо выплнить команду с опцией “–prepare”:

xtrabackup --prepare --target-dir=/home/backup/db/ --datadir=/var/lib/mysql

xtrabackup  Ver 0.9 Rev 83 for 5.0.84 pc-linux-gnu (x86_64)
xtrabackup: cd to /home/backup/db
xtrabackup: This target seems to be not prepared yet.
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(0 1284705008)
xtrabackup: Temporary instance for recovery is set as followings.
xtrabackup:   innodb_data_home_dir = ./
xtrabackup:   innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup:   innodb_log_group_home_dir = ./
xtrabackup:   innodb_log_files_in_group = 1
xtrabackup:   innodb_log_file_size = 2097152
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: Log scan progressed past the checkpoint lsn 0 1284705008
090914 20:18:59  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Doing recovery: scanned up to log sequence number 0 1284717711 (0 %)
090914 20:18:59  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
090914 20:19:00  InnoDB: Started; log sequence number 0 1284717711

[notice (again)]
  If you use binary log and don't use any hack of group commit,
  the binary log position seems to be:

xtrabackup: starting shutdown with innodb_fast_shutdown = 1
090914 20:19:00  InnoDB: Starting shutdown...
090914 20:19:01  InnoDB: Shutdown completed; log sequence number 0 1284717711

Команду восстановления данных нужно выполнить дважды, после чего будут созданы лог файлы для MySQL. После этого нужно скопировать лог файл и файл данных в папку MySQL (по умолчанию - /var/lib/mysql).

Инкрементальные бекапы

Понятно, что делать полный бекап на больших объемах будет крайне ресурсоемко, поэтому XtraBackup обладает возможностью инкрементальных бекапов и восстановления. Для этого, Вам сначала необходимо сделать полный бекап, а затем в отдельную папку - т.н. дельта бекап:

xtrabackup --defaults-file=/etc/mysql/my.cnf --target-dir=/home/backup/dbdelta \
 --incremental-basedir=/home/backup/db --backup

Для восстановления нужно выполнить следующую команду:

xtrabackup --target-dir=/home/backup/dbdelta \
 --incremental-basedir=/home/backup/db --prepare

Полезные ссылки

• Руководство по использованию XtraBackup
• XtraBackup Launchpad