В статье «Как работает бэкап на хостинге» мы уже обрисовали возможную ситуацию потери информации. Сегодня мы расскажем о том, как можно создавать резервные копии базы данных самостоятельно. Нет, это не mysqldump, это инструмент Percona Xtra, а именно Percona XtraBackup. Если потеря файлов сайта ещё не так страшна, то потеря информации в базе данных существенна и даже критична.
Да, есть привычная и любимая многими администраторами утилита mysqldump, но огромное количество опций может запутать неподготовленного пользователя. Для таких случаев и был разработан инструмент percona xtrabackup.
Создание копий в MYSQL/MARIADB Выполним команды для установки percona xtrabackup на centos/fedora/redhat:
[root@bitrix ~] yum install http://www.percona.com/downloads/percona-release/redhat/0.1-4/percona-release-0.1-4.noarch.rpm
P.S. Выбрать версию RPM пакета* percona xtrabackup для загрузки можно в официальном репозитории: http://www.percona.com/downloads/percona-release/redhat/
С информацией о том, что такое RPM пакет можно ознакомиться на сайте WIKIPEDIA: https://ru.wikipedia.org/wiki/RPM
[root@bitrix ~] yum install percona-xtrabackup -y
После этого мы увидим:
Установлено:
percona-xtrabackup.x86_64 0:2.3.5-1.el6
Зависимости установлены:
libev.x86_64 0:4.03-3.el6
Готово!
Теперь необходимо задать данные для авторизации пользователя в percona xtrabackup, в директории /root/, файл .my.cnf:
[client]
pass='passwordMYSQLserver'
Теперь нужно создать директорию, в которую будут создаваться копии:
[root@bitrix ~] cd /home/
[root@bitrix home] mkdir mysql
Запустим тестовое создание резервной копии:
[root@bitrix ~] innobackupex /home/mysql
Потребуется ожидание, длительность которого зависит от объёма базы.
В результате мы получим:
161116 10:59:56 Executing UNLOCK TABLES
161116 10:59:56 All tables unlocked
161116 10:59:56 Backup created in directory '/home/mysql//2016-11-16_10-59-53'
161116 10:59:56 [00] Writing backup-my.cnf
161116 10:59:56 [00] ...done
161116 10:59:56 [00] Writing xtrabackup_info
161116 10:59:56 [00] ...done
xtrabackup: Transaction log of lsn (1683258) to (1683258) was copied.
161116 10:59:56 completed OK!
В директории появится копия всей базы данных:
[root@bitrix ~] ls -la /home/mysql//2016-11-16_10-59-53
итого 18476
drwx------ 7 root root 4096 Ноя 16 10:59 .
drwxr-xr-x 4 root root 4096 Ноя 16 10:59 ..
drwx------ 2 root root 4096 Ноя 16 10:59 admin_db17597m
drwx------ 2 root root 4096 Ноя 16 10:59 admin_default
-rw-r----- 1 root root 386 Ноя 16 10:59 backup-my.cnf
-rw-r----- 1 root root 18874368 Ноя 16 10:59 ibdata1
drwx------ 2 root root 4096 Ноя 16 10:59 mysql
drwx------ 2 root root 4096 Ноя 16 10:59 performance_schema
drwx------ 2 root root 4096 Ноя 16 10:59 roundcube
-rw-r----- 1 root root 113 Ноя 16 10:59 xtrabackup_checkpoints
-rw-r----- 1 root root 394 Ноя 16 10:59 xtrabackup_info
-rw-r----- 1 root root 2560 Ноя 16 10:59 xtrabackup_logfile
Проверим работу системы восстановления из этой копии.
Сначала нужно остановить базу данных service mariadb stop или /etc/init.d/mysqld stop (У нас в примере cetnos6.8 поэтому дальше будет использоваться /etc/init.d/mysqld )
Мигрируем существующую базу в директорию tmp:
mv /var/lib/mysql/* /tmp/
Выполняем команду:
[root@bitrix ~] innobackupex --copy-back /home/mysql/2016-11-16_10-59-53/
После выполнения в терминале будет вывод:
completed OK!
Проверим статус:
[root@bitrix ~] /etc/init.d/mysqld status
mysqld (pid 2815) выполняется...
Если база не запустилась сама, запустим её вручную:
[root@bitrix ~] /etc/init.d/mysqld start
После всех манипуляций база данных восстановлена.
