Server Admin Авторский блог системного администратора
Нужно было быстренько настроить бэкап mysql базы в docker контейнере. Оказывается, это сделать очень просто. Поделюсь с вами информацией и себе на память сохраню.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном онлайн-курcе по администрированию MikroTik. Автор курcа – сертифицированный тренер MikroTik Дмитрий Скоромнов. Более 40 лабораторных работ по которым дается обратная связь. В три раза больше информации, чем в MTCNA.
Если не знаете, что такое докер и как с ним работать, вот моя статья на эту тему - установка docker в centos. Для бэкапа mysql базы достаточно запустить mysqldump в контейнере и сохранить файл на хост. Делается это все одной командой:
# docker exec container_name /usr/bin/mysqldump -u root --password=rootpass db_name > /mnt/backup/db_name.sql
Ну и сразу же простенький скрипт приведу по регулярному созданию бэкапов:
#!/bin/bash
DATA=`date +"%Y-%m-%d_%H-%M"`
PATHB=/mnt/backups
# Бэкапим дампом
docker exec container_name /usr/bin/mysqldump -u root --password=rootpass db_name > "$PATHB"/"$DATA"-db_name.sql
# Жмем
/bin/gzip "$PATHB"/"$DATA"-db_name.sql
# Чистим, удаляя файлы старше 10-ти дней
/usr/bin/find "$PATHB" -type f -mtime +10 -exec rm -rf {} \;
На сервере с бэкапами забираем эти файлы через rsync:
/usr/bin/rsync -av -e "ssh -p 17222 -i /root/.ssh/id_rsa" rsyncuser@62.211.78.55:/mnt/backups/* /backups/mysql
Я подключаюсь пользователем rsuncuser по ключу из файла /root/.ssh/id_rsa к серверу 62.211.78.55 с портом ssh 17222 и забираю все файлы из директории с дампами базы. Дальше уже правила хранения на самом бэкап сервер настраиваю в зависимости от потребностей.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном онлайн-курcе по администрированию MikroTik. Автор курcа – сертифицированный тренер MikroTik Дмитрий Скоромнов. Более 40 лабораторных работ по которым дается обратная связь. В три раза больше информации, чем в MTCNA.
Как вариант, создать файл и в него писать 0 или 1 в зависимости от состояния бэккпа. 1 можно забирать, а 0 еще не готово.
Соответственно при подключении считывать цифру.
Или просто файл создавать 0 или 1. Тогда сам файл открывать не требуется.
збс! просто, лаконично и с душой) дай бог здоровья автору и всего наилучшего!
Боагодарю за статью. Мне очень помогло, так как делал бекап впервые в жизни.
В процессе столкнулся с проблемой "mysqldump: [Warning] Using a password on the command line interface can be insecure." но решил ее с помощью статьи по утилите mysql_config_editor.
Для себя, немного модифицировал скрипт и поставил на крон на сервере.
Еще раз благодарю за помощь.
Это не проблема, а просто предостережение на тему того, что вы в явном виде указываете пароль от mysql. Это может быть не безопасно. Но в общем случае ничего страшного в этом нет, так как этот же пароль скорее всего используется в исходниках сайта, который подключается к базе.
#!/bin/bash
PASS="*******"
USER="****"
docker exec mysql_jira sh -c -e "/usr/bin/mysqldump -u $USER --password=$PASS jiradb > /mnt/backups/jiradb.sql" > /dev/null 2>&1
/bin/gzip /home/mysql/jiradb.sql - делаем архив базы, которая находится в папке на хосте и эта папка примонтирована в контейнер
/usr/bin/find /home/mysql -type f -mtime +10 -exec rm -rf {} \;
Понимаю, что механика резервного копирования это тема отдельной статьи и акцент здесь сделан не на это, но как вы выбираете момент запуска rsync'a относительно времени запуска скрипта создания бэкапа? Вы ведь не используете триггеры (успешного) завершения последнего? Не лучше ли было запускать rsync в обратную сторону на стороне сервера с докером по окончании сжатия? Ведь такой вариант, как мне кажется, еще лучше и в плане безопасности — сейчас у вас бэкапный сервер имеет доступ ко всем остальным. Интересно ваше мнение. Спасибо.
Как лучше отправлять бэкапы на отдельный сервер это палка о двух концах. Я сторонник подхода, когда сам сервер с бэкапами забирает все данные, а на целевых серверах нет возможности получить доступ к бэкап-серверу. Рассуждаю просто - публичные сервера больше подвержены взлому. Соответственно, если сервер взломают и с самого сервера есть доступ к бэкапам, можно их потерять. В моем же случае доступ к бэкап-серверу ограничен, он вне публичной области, доступ к нему чаще всего ни у кого нет, кроме администратора.
А на тему того, как синхронизировать создание бэкапа и его отправку на бэкап-сервер. Я прикидываю на глазок. Конечно, если у тебя база дампится несколько минут, то нужно как-то синхронизировать этот процесс, если бэкап отправляется, например, раз в час на бэкап-сервер. А если раз в сутки, то тут вообще нет проблем, как сделать так, чтобы не было пересечения.
В каждом конкретном случае смотрю по ситуации. Где-то вручную распределяю время, где-то одним скриптом все делаю, чтобы последовательно выполнялись команды. Не вижу тут большой проблемы, разруливается эта ситуация по месту.