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

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

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

Теоретический курс по основам сетевых технологий. Позволит системным администраторам упорядочить и восполнить пробелы в знаниях. Цена очень доступная, есть бесплатный доступ. Все подробности по . Можно пройти тест на знание сетей, бесплатно и без регистрации.

Если не знаете, что такое докер и как с ним работать, вот моя статья на эту тему - установка 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 Certified Network Associate. Помимо официальной программы, в курсах будут лабораторные работы, в которых вы на практике сможете проверить и закрепить полученные знания. Все подробности на сайте . Стоимость обучения весьма демократична, хорошая возможность получить новые знания в актуальной на сегодняшний день предметной области. Особенности курсов:
  • Знания, ориентированные на практику;
  • Реальные ситуации и задачи;
  • Лучшее из международных программ.

Автор Zerox

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

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

  1. Аватар

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

    • Zerox

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

  2. Аватар

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

  3. Аватар

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

    • Zerox

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

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

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

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

Ваш адрес email не будет опубликован.

Нажимая кнопку "Отправить комментарий" Я даю согласие на обработку персональных данных.