Home » Полезные советы » Backup mysql базы в docker контейнере

Backup mysql базы в docker контейнере

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

Онлайн-курс по устройству компьютерных сетей

На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

Если не знаете, что такое докер и как с ним работать, вот моя статья на эту тему - установка 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.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном онлайн-курcе по администрированию MikroTik. Автор курcа – сертифицированный тренер MikroTik Дмитрий Скоромнов. Более 40 лабораторных работ по которым дается обратная связь. В три раза больше информации, чем в MTCNA.

Автор Zerox

Владимир, системный администратор, автор сайта. Люблю настраивать сервера, изучать что-то новое, делиться знаниями, писать интересные и полезные статьи. Открыт к диалогу и сотрудничеству. Если вам интересно узнать обо мне побольше, то можете послушать интервью. Запись на моем канале - https://t.me/srv_admin/425 или на сайте в контактах.

7 комментариев

  1. Андрей

    Как вариант, создать файл и в него писать 0 или 1 в зависимости от состояния бэккпа. 1 можно забирать, а 0 еще не готово.
    Соответственно при подключении считывать цифру.

    Или просто файл создавать 0 или 1. Тогда сам файл открывать не требуется.

  2. збс! просто, лаконично и с душой) дай бог здоровья автору и всего наилучшего!

  3. Боагодарю за статью. Мне очень помогло, так как делал бекап впервые в жизни.
    В процессе столкнулся с проблемой "mysqldump: [Warning] Using a password on the command line interface can be insecure." но решил ее с помощью статьи по утилите mysql_config_editor.
    Для себя, немного модифицировал скрипт и поставил на крон на сервере.
    Еще раз благодарю за помощь.

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

  4. #!/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 {} \;

  5. Понимаю, что механика резервного копирования это тема отдельной статьи и акцент здесь сделан не на это, но как вы выбираете момент запуска rsync'a относительно времени запуска скрипта создания бэкапа? Вы ведь не используете триггеры (успешного) завершения последнего? Не лучше ли было запускать rsync в обратную сторону на стороне сервера с докером по окончании сжатия? Ведь такой вариант, как мне кажется, еще лучше и в плане безопасности — сейчас у вас бэкапный сервер имеет доступ ко всем остальным. Интересно ваше мнение. Спасибо.

    • Как лучше отправлять бэкапы на отдельный сервер это палка о двух концах. Я сторонник подхода, когда сам сервер с бэкапами забирает все данные, а на целевых серверах нет возможности получить доступ к бэкап-серверу. Рассуждаю просто - публичные сервера больше подвержены взлому. Соответственно, если сервер взломают и с самого сервера есть доступ к бэкапам, можно их потерять. В моем же случае доступ к бэкап-серверу ограничен, он вне публичной области, доступ к нему чаще всего ни у кого нет, кроме администратора.

      А на тему того, как синхронизировать создание бэкапа и его отправку на бэкап-сервер. Я прикидываю на глазок. Конечно, если у тебя база дампится несколько минут, то нужно как-то синхронизировать этот процесс, если бэкап отправляется, например, раз в час на бэкап-сервер. А если раз в сутки, то тут вообще нет проблем, как сделать так, чтобы не было пересечения.

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Нажимая кнопку "Отправить комментарий" Я даю согласие на обработку персональных данных.
Используешь Telegram? Подпишись на канал автора →
This is default text for notification bar