Восстановление из бэкапа
Давайте теперь восстановим данные из сделанного бэкапа. Если это тот же сервер, то все очень просто. Нам достаточно подготовить бэкап с помощью ключа prepare, как я показал ранее и заменить содержимое рабочей директории mysql на то, что хранится в архиве.
# systemctl stop mysqld && rm -rf /var/lib/mysql/* # xtrabackup --copy-back --target-dir=/root/backupdb/full # chown -R mysql:mysql /var/lib/mysql # systemctl start mysqld
Разбираем, что я сделал.
- Остановил mysql сервер и удалил все из ее рабочей директории.
- Восстановил данные из архивной копии xtrabackup. По факту он просто скопировал данные в рабочую директорию mysql сервера.
- Назначил пользователя mysql владельцем рабочей директории и всего ее содержимого.
- Запустил mysql сервер с восстановленными данными.
После запуска mysql сервера проверяйте лог /var/log/mysql/error.log на предмет ошибок. Если увидите там такие ошибки:
InnoDB: Page log sequence number 17744745 is in the future! Current system log sequence number 9160744.
Значит забыли выполнить подготовку архива перед восстановлением. Я частенько это забываю и расстраиваюсь, когда вижу ошибки. В общем случае ошибок после восстановления быть не должно.
Если будете восстанавливать базу на другой сервер, то последовательность действий будет следующая. Подключаем репозиторий percona.
# yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm
Ставим mysql server и xtrabackup нужной версии.
# yum install Percona-Server-server-57 percona-xtrabackup-24
Копируем на новый сервер архив сервера баз данных.
# scp root@10.20.1.5:/root/backupdb/full.tar.gz ~
Распаковываем его:
# tar xzvf full.tar.gz
Восстанавливаем данные и запускаем mysql сервер.
# xtrabackup --copy-back --target-dir=~/full # chown -R mysql:mysql /var/lib/mysql # systemctl start mysqld
Заходим в консоль mysql и проверяем список баз и пользователей.
# mysql -u root -p mysql> show databases; mysql> SELECT user,authentication_string,plugin,host FROM mysql.user;
Все на месте, как и на исходном сервере.
Это я показал восстановление из полного бэкапа. Теперь показываю, как восстановиться из инкрементной копии. Для начала нам надо подготовить полную копию для накатывания на нее инкремента.
# xtrabackup --prepare --apply-log-only --target-dir=/root/backupdb/full
Теперь добавляем туда данные из инкрементного бэкапа.
# xtrabackup --prepare --apply-log-only --target-dir=/root/backupdb/full --incremental-dir=/root/backupdb/inc1
И так для всех остальных инкрементных копий, если у вас из них выстроена цепочка. Контролировать состояние полного архива и сопоставлять с инкрементами можно по содержимому файлов xtrabackup_checkpoints. После того, как восстановили все инкрементные архивы, на последнем из них не нужно использовать ключ apply-log-only. Так же он не нужен, если у вас только одна инкрементная копия. Завершающий этап подготовки полной копии должен быть без него.
После того, как восстановили всю цепочку инкрементов, с архивом можно работать как с обычным полным бэкапом.
Восстановления базы из дампа
Через phpMyAdmin
В основном, пользователи работают с MySQL через панель phpMyAdmin, поэтому ниже приведен наиболее простой способ сделать восстановление из бэкапа вручную. Чтобы восстановить базу из дампа, нужно выполнить несколько действий:
Как увеличить объем импортируемых баз данных
К сожалению, описанный выше способ восстановить базу данных MySQL подходит в основном для небольших баз данных. Ведь в phpMyAdmin «из коробки» установлены ограничения на максимальный размер загружаемых файлов на сервер в 2 Мб.
Чтобы обойти дефолтные ограничения phpMyAdmin, нужно увеличить размер разрешенных к загрузке файлов. Это можно сделать как в настройках самой программы, так и на стороне сайта/сервера.
Во втором случае (в файлах php.ini /.htaccess) потребуется увеличить значения по умолчанию ряда опций, влияющих на загрузку:
- upload_max_filesize («максимальный размер загружаемого файла»). Первоначальное значение: «2Mб».
- post_max_size («максимальный размер POST-запросов»). Значение параметра должно быть больше, чем у «upload_max_filesize».
- max_execution_time («время исполнения скрипта»). Чтобы снять ограничения с параметра, ему нужно присвоить значение «0».
- max_input_time («время обработки входящих запросов»).
Способы увеличения лимитов на исполнение php-скриптов
- В настройках конфигурационного файла phpMyAdmin (config.inc.php). В файл нужно добавить строки:
$ cfg = './upload';
После чего добавить туда же переменную, снимающую ограничения со времени исполнения скриптов (после загрузки базы данных ее лучше убрать):
$ cfg = 0;
- В пользовательском файле сайта (php.ini), где хранятся настройки исполнения php-скриптов. Файл «php.ini» можно найти, если открыть в браузере ранее добавленный (в корень сайта) php-файл. Например, ввести запрос вида «https://mysitename.com/myphpinfo.php», где «mysitename.com» — имя сайта, а «myphpinfo.php» — название php-файла. В открывшемся окне нужно найти параметры «Loaded Configuration File» или «Configuration File (php.ini) Path», где и будет указан путь к «php.ini».
Добавляем в конце файла строки:
post_max_size = 500M upload_max_filesize = 400M max_execution_time = 3000 max_input_time = 6000
- В конфигурационном файле сервера (.htaccess), отвечающем, в том числе, за настройку обработки файлов на определенном сайте. Чтобы изменения сработали для всех файлов сайта, «.htaccess» должен обязательно находится в его корневой папке.
Добавляем в файл строки:
php_value post_max_size 500M php_value upload_max_filesize 400M php_value max_execution_time 3000 php_value max_input_time 6000
Восстановление пароля
Ситуации, когда может потребоваться сброс и восстановление пароля root, также встречаются часто. Для решения этой проблемы можно воспользоваться одним из предложенных ниже способов.
![Памятка по бэкапу (mysqldump) [rtfm.wiki]](https://tehnikaarenda.ru/wp-content/uploads/7/8/6/786e0c15a86a2dc2b223fe2c89602520.jpeg)
Использование init-file
Во время запуска MySQL есть возможность сообщить сервису о файле, в котором находятся исполняемые команды SQL. Его адрес следует указать с помощью параметра «init-file».
1. В первую очередь необходимо создать файл «init-file»:
vi /home/user/init-file.txt
2. Далее нужно добавить в файл следующую строку:
UPDATE mysql.user SET password=password('новый пароль') WHERE user='root';
3. Далее следует отключить сервис, если он работает:
sudo systemctl stop mysql
4. Затем можно запустить свой файл:
sudo mysqld --user=mysql --init-file=/home/sergiy/init-file.txt --console
5. Остается подождать немного, пока все будет работать, как надо, и далее остановить данный процесс. В терминале будет отображен вывод «started as proccess» и PID (номер-идентификатор) процесса. Последний как раз и нужно выключить. К примеру*:
sudo kill -TERM 1111
* Значение PID приведено для примера. Следует заменить его на актуальное.
6. Теперь можно запустить MySQL стандартным способом и попробовать авторизоваться с помощью нового пароля:
sudo systemctl start mysql mysql -u root -p
Использование skip-grant-tables
Помимо — init-file можно выполнить сброс пароля с использованием другого параметра —skip-grant-tables. Если запустить с ним сервис, будет пропущена загрузка данных пользователей, что позволяет войти без необходимости вводить логин и пароль.
1. Здесь также сначала требуется отключить базу данных:
udo systemctl stop mysqls
2. Дальше нужно запустить вручную MySQL следующей командой:
sudo mysqld --user=mysql --skip-grant-tables
3. Теперь можно открыть консоль для работы с MySQL:
mysql -u root
4. Поскольку загрузка была осуществлена без привилегий пользователей, таблицы с ними теперь нужно подгрузить:
FLUSH PRIVILEGES;
5. На этой стадии можно менять пароль пользователя root:
UPDATE mysql.user SET password=password('новый пароль') WHERE user='root';
6. Можно закрывать консоль управления:
Exit (quit)
7. Остается выключить сервис*, как и в приведенном выше способе:
sudo kill -TERM 1111
* Значение PID приведено для примера. Следует заменить его на актуальное.
8. И, наконец, запустить MySQL в стандартном режиме работы:
sudo systemctl start mysql
9. После этого появится возможность авторизации с помощью нового пароля:
sudo mysql -u root -p
Бэкап и восстановление mysql с помощью mysqldump
Теперь просто для справки приведу примеры бэкапа и восстановления баз данных mysql с помощью mysqldump. Для небольших баз этого инструмента хватает за глаза и использовать что-то другое не имеет смысла. Преимущество xtrabackup в скорости работы и в возможности без проблем сделать инкрементный бэкап. Если он вам не нужен и база не большая, достаточно будет старого доброго mysqldump.
Бэкап всех баз mysql сервера с его помощью:
# /usr/bin/mysqldump -uroot -hlocalhost -p'password' --all-databases > /root/backupdb/all.sql
Можно сразу же сжимать его.
# /usr/bin/mysqldump -uroot -hlocalhost -p'password' --all-databases | /usr/bin/gzip -c > /root/backupdb/`date "+%Y-%m-%d"`sql.gz
Бэкап конкретной базы данных.
/usr/bin/mysqldump sitemanager -uroot -p'password' | /usr/bin/gzip -c > /root/backupdb/sitemanager_`date "+%Y-%m-%d"`sql.gz
Мне чаще всего мешают в дампе команды на создание базы данных — CREATE DATABASE, поэтому я их убираю ключом no-create-db.
/usr/bin/mysqldump --no-create-db sitemanager -uroot -p'password' | /usr/bin/gzip -c > /root/backupdb/sitemanager_`date "+%Y-%m-%d"`sql.gz
Для того, чтобы восстановить базу данных из дампа, можно воспользоваться следующими командами. Выполняются из консоли mysql.
# mysql -uroot -p mysql> use sitemanager; mysql> source /root/backupdb/sitemanager.sql;
Если дамп без команды на создание базы данных и ее нет у вас на сервере, то не забудьте ее перед этим создать. Так же восстановить базу данных из дампа можно следующим образом.
mysql> use sitemanager; mysql> \. /root/backupdb/sitemanager.sql
Вот простенький скрипт, который позволяет забэкапить все базы данных сервера, при этом бэкап каждой базы будет в отдельном файле. Это удобнее, чем все базы единым файлом. Оттуда потом трудно доставать конкретную базу.
#!/bin/bash
for i in `mysql -uroot -p'password' -e'show databases;' | grep -v information_schema | grep -v Database`;
do
/usr/bin/mysqldump -uroot -p'password' $i | /usr/bin/gzip -c > /root/backupdb/`date +%Y-%m-%d`-$i.sql.gz;
done
Так же могу порекомендовать вот этот скрипт для бэкапа — https://github.com/adegtyarev/mysqlbackup. Описывать его не буду, по комментариям в скрипте понятен его функционал.
Если вам нужно из полного бэкапа mysql восстановить отдельную таблицу, то ее можно выделить из полного дампа через обычный awk примерно вот так.
# cat sitemanager.sql | /usr/bin/awk '/CREATE TABLE `b_catalog_discount`/,/UNLOCK TABLES/' > /tmp/b_catalog_discount.sql
Дальше через source можно восстановить данные из этого дампа отдельной таблицы.
Иногда бывает полезно сделать не просто полный backup базы данных, а разбить его сразу на таблицы. Тут поможет следующий скрипт.
#!/bin/bash
USER='root'
PASS='R(zDXcVUmI[zwx%aNBTN'
MYSQL="mysql --user=$USER --password=$PASS --skip-column-names";
DIR="/root/backupdb"
for s in mysql `$MYSQL -e "SHOW DATABASES"`;
do
mkdir $DIR/$s;
for t in `$MYSQL -e "SHOW TABLES FROM $s"`;
do
/usr/bin/mysqldump --user="$USER" --password="$PASS" --opt $s $t | /usr/bin/gzip -c > $DIR/$s/$t.sql.gz;
done
done
В таком варианте он сделает потабличный бэкап всех баз данных. Если вам не нужны все базы, то в цикле можете вместо предложенного перебора всех существующих баз указать одну конкретную.
for s in mysql sitemanager;
Восстановить потом всю базу из такого потабличного бэкапа можно таким образом.
#!/bin/bash
#
DB=sitemanager;
USER='root'
PASS='R(zDXcVUmI[zwx%aNBTN'
DIR="/root/backupdb/sitemanager"
for s in `ls -1 $DIR`;
do
echo "--> $s restoring... ";
zcat $DIR/$s | /usr/bin/mysql --user=$USER --password=$PASS $DB;
done
При использовании пароля в открытом виде в mysql или mysqldump, в консоль постоянно сыпятся предупреждения.
mysql: Using a password on the command line interface can be insecure.
Чтобы их не было, перенесите, как я показывал выше, пароль в отдельный файл ~/.my.cnf, а из скрипта уберите авторизацию вообще.
На этом, пожалуй, насчет бэкапа баз mysql сервера все. Поделился основными своими наработками.
Полный бэкап Mysql сервера
Итак, база данных у нас работает, утилиту для бэкапа мы установили. Давайте теперь сделаем полный backup всех баз данных нашего сервера mysql.
# xtrabackup --backup --user=root --password='R(zDXcVUmI[zwx%aNBTN' --target-dir=/root/backupdb/full
| backup | инициируем процедуру бэкапа |
| user=root | пользователь mysql |
| password=’R(zDXcVUmI[zwx%aNBTN’ | пароль пользователя, взятый в одинарные кавычки |
| target-dir=/root/backupdb/full | директория для создания полного бэкапа mysql |
В дальнейших примерах я не буду указывать пользователя и пароль, чтобы упростить команды. Эти данные я указал в файле ~/.my.cnf.
user=root password='R(zDXcVUmI[zwx%aNBTN'
Мы сделали полный архив всего mysql сервера. В таком виде данные не консистентны, так как они могли меняться во время архивации. Если восстановить их как есть, сервер mysql не запустится. Будет ругаться на поврежденные данные. Чтобы восстановить целостность данных, необходимо выполнить еще одну команду.
# xtrabackup --prepare --target-dir=/root/backupdb/full
После этого бэкап будет полностью работоспособен и готов к восстановлению. Я обычно выполняю эту команду сразу же после бэкапа, но это не всегда возможно. К примеру, если вы захотите его сразу же сжать.
# xtrabackup --backup --compress --target-dir=/root/backupdb/full
В таком случае его сначала нужно будет распаковать, а потом подготовить. Делать это не обязательно сразу. Можно хранить бэкапы не подготовленными, а готовить только перед восстановлением, если это случится. Распаковывается бэкап следующим образом.
# xtrabackup --decompress --target-dir=/root/backupdb/full
Для того, чтобы команда decompress отработала без ошибки:
sh: qpress: command not found cat: write error: Broken pipe Error: decrypt and decompress thread 0 failed.
Необходимо установить пакет qpress.
# yum install qpress
Он есть в репозитории percona. После этого распаковка пройдет штатно.
Лично я не вижу большого смысла использовать ключи compress и decompress. Можно сделать полный бэкап, подготовить его, а потом сжать тем же gzip.
# tar -czvf /root/backupdb/full.tar.gz -C /root/backupdb full
На выходе получите тот же архив, только сжат лучше и нет необходимости ставить дополнительный софт. Gzip и tar обычно есть во всех дистрибутивах. К тому же архив в виде единого файла проще и быстрее передать на сервер бэкапов и там хранить.
В завершении раздела про полный backup, предлагаю простенький скрипт для автоматизации процесса через cron — mysql-full-backup.sh.
#!/bin/bash DATA=`date +%Y-%m-%d` mkdir -p /root/backupdb/$DATA xtrabackup --backup --target-dir=/root/backupdb/$DATA/full xtrabackup --prepare --target-dir=/root/backupdb/$DATA/full tar -czvf /root/backupdb/$DATA/full.tar.gz -C /root/backupdb/$DATA full rm -rf /root/backupdb/$DATA/full
При выполнении этого скрипта раз в день, вы будете иметь отдельные папки с именем в виде даты, а внутри полный бэкап. Дальше мы в эти же папки будем класть инкрементные бэкапы. Но обо всем по порядку.
Мониторинг бэкапов mysql
Для того, чтобы нам не тащить на бэкап сервер битые дампы, будем проверять их сразу же на месте. Сразу поясню, что это не отменяет дальнейшие проверки этих дампов на возможность реального восстановления из них. Эту процедуру надо делать на отдельном сервере. В рамках данной заметки я не буду это рассматривать. Сейчас мы просто будем следить за тем, что дамп базы данных mysql выполнен корректно.
Мониторинг за валидацией бэкапов будем осуществлять с помощью Zabbix.
Если у вас еще нет своего сервера для мониторинга, то рекомендую материалы на эту тему. Для тех, кто предпочитает систему CentOS:
- Установка CentOS 8.
- Настройка CentOS 8.
- Установка и настройка zabbix сервера.
То же самое на Debian 10, если предпочитаете его:
- Установка Debian 10.
- Базовая настройка Debian.
- Установка и настройка zabbix на debian.
Мы настроили вывод результатов проверки архивов в лог файл /var/log/mysql/backup.log. Теперь сделаем так, чтобы Zabbix анализировал содержимое файла и слал оповещение, если там появится слово corrupted, что будет означать проблему с созданием дампа.
Для этого создаем новый шаблон и добавляем туда элемент данных.
Тут всё очень просто и стандартно. Далее делаем триггер.
Выражение проблемы:
{Backup mysql status:log[/var/log/mysql/backup.log].str(corrupted)}=1
Выражение восстановления:
{Backup mysql status:log[/var/log/mysql/backup.log].str(OK)}=1
Прикрепляем шаблон к хосту, где делаем бэкап. Не забудьте убедиться, что у zabbix-agent на хосте есть доступ на чтение этого лог файла. Таким образом, если проверка дампа не будет завершена успешно, сработает триггер. Он будет висеть активным до тех пор, пока не будет создан корректный бэкап базы mysql.
Вот так достаточно просто и быстро я решаю вопрос создания, проверки и оповещения о проблемах при создании дампов и бэкапов mysql баз.
Копирование базы данных MySQL на тот же сервер
Чтобы скопировать базу данных MySQL, вам необходимо выполнить следующие шаги:
- Сначала создайте новую базу данных, используя оператор CREATE DATABASE.
- Во-вторых, экспортируйте все объекты базы данных и данные базы данных, из которой вы хотите скопировать, используя инструмент mysqldump.
- В-третьих, импортируйте файл дампа SQL в новую базу данных.
Для демонстрации мы скопируем базу данных classicmodels в базу данных classicmodels_backup.
Шаг 1. Создайте базу данных classmodels_backup:
Сначала войдите на сервер базы данных MySQL:
>mysql -u root -p Enter password: **********
Затем используйте оператор CREATE DATABASE следующим образом:
> CREATE DATABASE classicmodels_backup;
В-третьих, используйте команду SHOW DATABASES для проверки:
> SHOW DATABASES
Сервер базы данных MySQL возвращает следующий вывод:
+----------------------+ | Database | +----------------------+ | classicmodels | | classicmodels_backup | | information_schema | | mysql | | performance_schema | | sys | +----------------------+ 6 rows in set (0.00 sec)
Как видите, мы успешно создали базу данных classicmodels_backup.
Шаг 2 . Копирование объектов базы данных и данные в файл SQL с помощью инструмента mysqldump.
Предположим, вы хотите сбросить объекты базы данных и данные базы данных classicmodels в файл SQL, расположенный в папке D:\db, вот команда:
>mysqldump -u root -p classicmodels > d:\db\classicmodels.sql Enter password: **********
По сути, эта команда инструктирует mysqldump войти на сервер MySQL, используя учетную запись пользователя root с паролем, и экспортирует объекты базы данных и данные classicmodels базы данных в d:\db\classicmodels.sql
Обратите внимание, что оператор(>) означает экспорт
Шаг 3 . Импортируйте файл d:\db\classicmodels.sql в базу данных classicmodels_backup.
>mysql -u root -p classicmodels_backup < d:\db\classicmodels.sql Enter password: **********
Обратите внимание, что оператор (
Чтобы проверить импорт, вы можете выполнить быструю проверку с помощью команды SHOW TABLES.
> SHOW TABLES FROM classicmodels_backup;
Он вернул следующий вывод:
+--------------------------------+ | Tables_in_classicmodels_backup | +--------------------------------+ | customers | | employees | | offices | | orderdetails | | orders | | payments | | productlines | | products | +--------------------------------+ 8 rows in set (0.01 sec)
Как видите, мы успешно скопировали все объекты и данные из базы данных classicmodels в базу данных classicmodels_backup.
Бэкап БАЗЫ (БАЗ) данных
Для создания резервных копий баз данных MySQL из терминала Linux, существует специальная утилита mysqldump, которая устанавливается вместе с сервером. Ниже рассмотрим несколько различных примеров, используя которые можно делать резервные копии как целых баз, так и необходимых таблиц в конкретной базе.
Создаем резервную копию ОДНОЙ базы
— аргумент, означающий, что мы будем подключаться к MySQL серверу под учетной записью root (может быть любая учетная запись, имеющая необходимые права на нужную таблицу). — аргумент, означающий, что необходимо ввести пароль для авторизации (т.е. доступ для данного пользователя без пароля — не разрешен). В случае, когда пароль не требуется, данный аргумент можно упустить. — это имя базы данных, резервную копию которой мы делаем. — это название бекапа, который будет создан. Создается он в текущем каталоге из которого вы запускаете данную команду. Если вам необходимо сохранить резервную копию в какой-либо определенный каталог, то можно сразу указать путь до этого каталога, написав вместо , . Таком образом, резервная копия будет создана в каталоге
Создаем резервную копию НЕСКОЛЬКИХ баз
В случае, когда необходимо одной командой создать бекапы для нескольких баз данных, можно воспользоваться следующей командой:
— аргумент, указывающий, что далее будут перечислены базы данных, резервные копии которых мы хотим сделать. — имена баз данных, резервные копии которых мы хотим сделать. Разделяются пробелом.
Создаем резервную копию ВСЕХ баз
В случае, когда необходимо одной командой сделать резервную копию всех доступных баз данных, можно воспользоваться следующей командой:
, аргумент, указывающий, что необходимо сделать резервную копию всех доступных баз данных.
Если вы получаете ошибку «mysqldump: 1044 Access denied when using LOCK TABLES», то скорей всего вы пытаетесь делать резервную копию не под учетной записью root, а под какой то другой, у которой недостаточно прав на системные базы данных, вроде sys и mysql, либо другие. Поэтому, необходимо выдать нужные права пользователю на все базы, подробней об этом можно прочитать в данной статье: Ошибка: mysqldump: 1044 Access denied when using LOCK TABLES, либо делать резервные копии с помощью учетной записи root.
Бэкап ТАБЛИЦЫ (ТАБЛИЦ) из определенной базы данных
Создаем резервную копию ОДНОЙ таблицы из базы
В том случае, когда у вас нет нужды создавать резервную копию всей базы данных целиком, а необходимо лишь создать резервную копию одной таблицы из этой базы данных, можно воспользоваться следующей командой:
— это имя таблицы, резервную копию которой мы хотим сделать и которая находится в базе данных .
Создаем резервную копию НЕСКОЛЬКИХ таблиц из базы
В том случае, когда вам необходимо сделать резервную копию нескольких таблиц из определенной базы, можно воспользоваться следующей командой:
— это названия таблиц, резервные копии которых мы хотим сделать. В нашем примере данные таблицы находятся в базе данных .
Проверка дампа mysql
То, что вы сделали дамп базы совсем не значит, что он завершился успешно. Он может быть прерван по какой-то причине. Причем, он год может выполняться успешно, а в какой-то момент начнет давать сбой в самом конце выгрузки. Если никак не отслеживаете ситуацию, можете это не заметить, а потом получить неконсистентную (битую) выгрузку.
![Памятка по бэкапу (mysqldump) [rtfm.wiki]](https://tehnikaarenda.ru/wp-content/uploads/c/6/c/c6cdf7090a5370c4f3a9d75a3f2591b2.jpeg)
Я делаю следующую проверку дампа сразу после его создания, чтобы не тащить на сервер бэкапов битый архив. Если дамп прошел успешно, то в первой строке дампа будет примерно такая строка:
-- MySQL dump 10.13 Distrib 5.7.33-36, for Linux (x86_64)
У вас может отличаться версия сервера, но начало будет одинаковое — двойное тире и слово Mysql. В конце дампа будет следующая строка:
-- Dump completed on 2021-07-11 20:21:06
Эти две строки я и буду проверять в скрипте, который будет делать дамп в автоматическом режиме. Результат проверки бэкапа я буду записывать в лог файл, а заодно и вывод утилиты mysqldump, чтобы в случае какой-то ошибки, я смог его проанализировать.
#!/bin/bash
#ключи mysqldump
OPTS="-v --add-drop-database --add-locks --create-options --disable-keys --extended-insert --single-transaction --quick --set-charset --routines --events --triggers --comments --quote-names --order-by-primary --hex-blob"
#файл дампа
FNAME="/mnt/backup/`date +%Y-%m-%d_%H-%M`_dbname.sql"
#лог результатов проверки дампа
LOG="/var/log/mysql/backup.log"
#лог вывода mysqldump
MLOG="/var/log/mysql"
#формат даты
DATA=`date +%Y-%m-%d_%H-%M`
#делаем дамп базы и записываем вывод в лог
/usr/bin/mysqldump ${OPTS} --databases dbname -u'root' -p'password' > ${FNAME} 2>> ${MLOG}/${DATA}-mysqldump.log
#сжимаем лог
/usr/bin/gzip ${MLOG}/${DATA}-mysqldump.log
#проверяем первую и последнюю строки дампа
BEGIN=`head -n 1 ${FNAME} | grep ^'-- MySQL dump' | wc -l`
END=`tail -n 1 ${FNAME} | grep ^'-- Dump completed' | wc -l`
#если обе строки верны, то пишем в лог ОК и сжимаем дамп
if ;then
if ;then
echo `date +%F_%H-%M` ${FNAME} is OK >> $LOG
/usr/bin/gzip ${FNAME}
else
echo `date +%F_%H-%M` ${FNAME} is corrupted >> $LOG
/usr/bin/rm ${FNAME}
fi
else
echo `date +%F_%H-%M` ${FNAME} is corrupted >> $LOG
/usr/bin/rm ${FNAME}
fi
#если дамп не проходит проверки, удаляем его и пишем в лог corrupted
#удаляем бэкапы и логи старше суток.
find /mnt/backup -type f -mmin +1440 -exec rm -rf {} \;
find /var/log/mysql/*mysqldump* -type f -mmin +1440 -exec rm -rf {} \;
Я скрипт прокомментировал, так что добавить особо нечего. Делаем дамп, проверяем первую и последнюю строки. Результат проверки пишем в лог файл, за которым далее будем наблюдать с помощью Zabbix.
Общие сведения о резервных копиях файлов
Полное резервное копирование позволяет сохранить все данные, содержащиеся в одной или нескольких файлах или файловых группах. По умолчанию резервные копии файлов содержат достаточное количество записей журнала для наката файла в конце операции резервного копирования файлов.
Создать резервную копию файла или файловой группы, доступную только для чтения, одинаковую для каждой модели восстановления. При модели полного восстановления полный набор резервных копий файлов совместно с количеством резервных копий журнала, достаточным для охвата всех резервных копий файлов, эквивалентен полной резервной копии базы данных.
Одновременно может выполняться лишь одна операция резервного копирования файлов. Можно создать резервные копии нескольких файлов за одну операцию, но это может увеличить время восстановления, если нужно восстановить всего один файл. Причина этого заключается в необходимости считывания всей резервной копии в поиске нужного файла.
Примечание
Отдельные файлы могут быть восстановлены из резервной копии базы данных, однако поиск и восстановление файла из резервной копии базы данных займет больше времени, чем из резервной копии файла.
Резервные копии файлов и простая модель восстановления
В простой модели восстановления резервные копии файлов для чтения и записи должны создаваться вместе. Это гарантирует восстановление базы данных до согласованного момента времени. Вместо того чтобы указывать каждый файл или файловую группу для чтения и записи, воспользуйтесь параметром READ_WRITE_FILEGROUPS. Этот параметр создает резервные копии всех файловых групп, доступных для чтения и записи, в базе данных. С помощью параметра READ_WRITE_FILEGROUPS создаются так называемой частичной резервной копией. Дополнительные сведения см. в разделе Частичные резервные копии (SQL Server).
Резервные копии файлов и модель полного восстановления
В модели полного восстановления необходимо выполнять резервное копирование журналов транзакций отдельно от остальной части стратегии резервирования данных. Полный набор резервных копий файлов вместе с резервными копиями журналов, которых достаточно для охвата всех резервных копий файлов с момента первого копирования, эквивалентен полной резервной копии базы данных.
Восстановить базу данных лишь из файла и резервных копий журналов может оказаться сложно. Поэтому лучше выполнить полное резервное копирование базы данных, а затем начать резервное копирование журнала, чем сразу создавать резервную копию файлов. На следующем рисунке показана стратегия, согласно которой создается полная резервная копия базы данных (за время t1) вскоре после создания базы данных (за время t0). Эта первая резервная копия базы данных позволяет начать резервное копирование журнала транзакций. Резервное копирование журнала транзакций запланировано через определенные промежутки времени. Резервные копии файлов создаются через некоторый интервал времени, оптимально соответствующий требованиям предприятия. На данном рисунке показана каждая из четырех файловых групп, резервное копирование которых происходит одновременно. Порядок, в котором оно производится (группы A, C, B, A), отражает требования предприятия к базе данных.
Примечание
При использовании модели полного восстановления необходимо выполнить накат всех журналов транзакций во время восстановления резервной копии файла для записи и чтения, чтобы обеспечить согласованность состояния файла с остальной частью базы данных. Чтобы избежать необходимости наката большого количества резервных копий журналов транзакций, следует чаще создавать разностные резервные копии файлов. Дополнительные сведения см. в разделе Разностные резервные копии (SQL Server).
