Аннотация
В статье рассматривается практический подход к автоматизации резервного копирования баз данных MySQL с использованием Bash-скриптов и планировщика задач Cron. Предложенное решение обеспечивает регулярное создание сжатых дампов, ротацию архивов с автоматическим удалением устаревших копий, а также передачу резервных копий на удалённый сервер по протоколу SCP. Описанный метод отличается простотой реализации, надёжностью и может быть адаптирован для различных сред эксплуатации.
Ключевые слова: резервное копирование, MySQL, Bash, Cron, автоматизация, SCP, ротация архивов, SSH-аутентификация.
Введение
Обеспечение сохранности данных является одной из критически важных задач при эксплуатации информационных систем на базе реляционных СУБД. В случае с MySQL наиболее распространённым и надёжным инструментом резервного копирования выступает утилита mysqldump, позволяющая создавать логические дампы баз данных. Однако ручное выполнение данной операции не может гарантировать регулярность и полноту резервного копирования, особенно в условиях интенсивной эксплуатации системы.
Наиболее эффективным решением данной проблемы является создание автоматизированного Bash-скрипта, выполняющего полный цикл операций по созданию, сжатию, ротации и удалённому сохранению резервных копий, с последующей интеграцией в систему планирования задач Cron. Такой подход обеспечивает регулярное создание снапшотов БД, минимизирует человеческий фактор и гарантирует наличие актуальных резервных копий для восстановления в случае аварийных ситуаций.
В настоящей статье представлен готовый скрипт, реализующий описанную логику, выполнен детальный разбор его компонентов и предложены рекомендации по безопасной эксплуатации.
1. Общая архитектура решения
Предлагаемый скрипт представляет собой последовательность команд, выполняющих следующие функции:
- создание директории с меткой текущей даты для хранения резервной копии;
- формирование сжатого дампа базы данных MySQL с использованием архиватора gzip;
- удаление резервных копий, созданных более 30 дней назад;
- полная очистка директории хранения от пустых каталогов;
- передача свежего бэкапа на удалённый сервер по протоколу SCP.
Данная архитектура позволяет организовать непрерывный цикл резервного копирования с автоматической ротацией архивов, что исключает переполнение дискового пространства.
2. Структура и реализация скрипта
Ниже представлен полный листинг скрипта с последующим детальным анализом каждой его части.
#!/bin/bash
TIMESTAMP=$(date +"%F")
BACKUP_DIR="/var/backup/database/$TIMESTAMP"
mkdir -p "$BACKUP_DIR"
mysqldump --user=root --host=localhost --password=sNhrky6538TB@ db1 | gzip > $BACKUP_DIR/$(date '+%Y-%m-%d-%H-%M-%S').sql.gz
find /var/backup/database -type d -mtime +30 -delete
find /var/backup/database -type f -mtime +30 -delete
sudo rm -d /var/backup/database/*
sudo scp -v -P 3456 -r /var/backup/database/$(date +"%F")/ admin@10.129.0.23:/home/admin/backupsv2
2.1. Определение интерпретатора
#!/bin/bash
Данная строка является shebang-директивой, указывающей системе, что скрипт должен интерпретироваться оболочкой Bash. Это обязательный элемент любого исполняемого скрипта в Unix-подобных операционных системах.
Создание директории с временной меткой
TIMESTAMP=$(date +"%F")
BACKUP_DIR="/var/backup/database/$TIMESTAMP"
mkdir -p "$BACKUP_DIR"
- TIMESTAMP=$(date +"%F") — формирует переменную, содержащую текущую дату в формате ГГГГ-ММ-ДД (например, 2026-06-20);
- BACKUP_DIR="/var/backup/database/$TIMESTAMP" — конструирует полный путь к целевой директории для хранения резервных копий;
- mkdir -p "$BACKUP_DIR" — создаёт указанную директорию; флаг -p обеспечивает рекурсивное создание всех промежуточных каталогов при их отсутствии.
В результате выполнения данного блока создаётся директория вида /var/backup/database/2026-06-20/.
2.3. Создание сжатого дампа базы данных
mysqldump --user=root --host=localhost --password=s3sbsFG8B@ db1 | gzip > $BACKUP_DIR/$(date '+%Y-%m-%d-%H-%M-%S').sql.gz
- mysqldump — стандартная утилита для создания логических дампов баз данных MySQL;
- --user=root — определяет пользователя для аутентификации;
- --host=localhost — указывает хост, на котором функционирует сервер MySQL;
- --password=... — содержит пароль для аутентификации (в производственной среде требуется более безопасный способ хранения учётных данных);
- db1 — имя базы данных, подлежащей резервному копированию;
- | gzip — выполняет сжатие дампа с использованием архиватора gzip;
- > $BACKUP_DIR/$(date '+%Y-%m-%d-%H-%M-%S').sql.gz — сохраняет сжатый дамп в файл, имя которого содержит точную временную метку с точностью до секунды.
Итоговое имя файла имеет формат 2026-06-20-03-15-42.sql.gz, что позволяет идентифицировать точное время создания резервной копии.
2.4. Удаление устаревших резервных копий
find /var/backup/database -type d -mtime +30 -delete
find /var/backup/database -type f -mtime +30 -delete
- find /var/backup/database — выполняет рекурсивный поиск объектов в указанной директории;
- -type d и -type f — фильтруют объекты по типу (каталоги и файлы соответственно);
- -mtime +30 — выбирает объекты, дата последнего изменения которых превышает 30 дней;
- -delete — удаляет найденные объекты.
Данный механизм обеспечивает автоматическую ротацию архивов, гарантируя хранение резервных копий только за последние 30 дней, что предотвращает неконтролируемый рост используемого дискового пространства.
2.5. Очистка директории от пустых каталогов
sudo rm -d /var/backup/database/*
Команда rm -d удаляет только пустые каталоги внутри /var/backup/database/. При наличии файлов в каталоге удаление не производится, что обеспечивает безопасность данных. Использование sudo обусловлено необходимостью прав суперпользователя для выполнения операций в системной директории.
2.6. Передача резервной копии на удалённый сервер
sudo scp -v -P 3456 -r /var/backup/database/$(date +"%F")/ admin@10.129.0.23:/home/admin/backupsv2
- scp — утилита для защищённого копирования по протоколу SSH;
- -v — активирует подробный режим вывода, полезный для диагностики;
- -P 3456 — указывает нестандартный порт SSH-соединения;
- -r — включает рекурсивное копирование каталогов;
- /var/backup/database/$(date +"%F")/ — путь к свежесозданной директории с резервной копией;
- admin@10.129.0.23:/home/admin/backupsv2 — целевой адрес удалённого сервера и путь для сохранения.
Результатом выполнения данного этапа является доставка актуальной резервной копии на внешний сервер для обеспечения географически распределённого хранения.
3. Настройка беспарольной аутентификации по SSH для SCP
Для корректной работы команды scp в автоматическом режиме необходимо настроить SSH-аутентификацию по ключам. Это позволяет передавать файлы на удалённый сервер без интерактивного ввода пароля, что критически важно для работы автоматизированных скриптов.
3.1. Принцип работы SSH-ключей
SSH-аутентификация по ключам основана на асимметричной криптографии. Генерируется пара ключей: приватный (закрытый) и публичный (открытый). Приватный ключ хранится на клиентской машине и никогда не передаётся третьим лицам. Публичный ключ размещается на удалённом сервере в специальном файле. При попытке подключения сервер проверяет, что клиент владеет соответствующей приватной частью ключа, после чего предоставляет доступ без запроса пароля.
3.2. Генерация ключевой пары
На сервере, с которого будет осуществляться передача файлов, выполняется команда:
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
Параметры команды:
- -t rsa — тип генерируемого ключа (RSA);
- -b 4096 — длина ключа в битах (рекомендуется 4096 для повышенной стойкости);
- -C "your_email@example.com" — комментарий, позволяющий идентифицировать ключ.
В процессе генерации система запросит следующие параметры:
- Путь для сохранения ключа — рекомендуется нажать Enter, чтобы оставить значение по умолчанию (~/.ssh/id_rsa);
- Парольная фраза — для автоматических скриптов рекомендуется оставить пустым (нажав Enter), хотя для повышения безопасности можно установить парольную фразу, но в этом случае потребуется использование ssh-agent.
Результатом выполнения команды является создание двух файлов:
- ~/.ssh/id_rsa — приватный ключ (конфиденциальная информация, не подлежащая распространению);
- ~/.ssh/id_rsa.pub — публичный ключ (может свободно распространяться для размещения на серверах).
3.3. Размещение публичного ключа на удалённом сервере
Существуют два основных способа копирования публичного ключа на удалённую систему.
Способ 1. Автоматическое копирование с использованием утилиты ssh-copy-id:
ssh-copy-id user@remote-server-ip
Утилита запросит пароль пользователя на удалённом сервере и автоматически добавит публичный ключ в файл ~/.ssh/authorized_keys, создав необходимые директории и настроив корректные права доступа.
Способ 2. Ручное копирование:
Сначала необходимо отобразить содержимое публичного ключа:
cat ~/.ssh/id_rsa.pub
Затем скопировать полученный вывод и на удалённом сервере выполнить следующие команды:
mkdir -p ~/.ssh
echo "скопированный_ключ" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
chmod 700 ~/.ssh
Данный способ требует больше ручных операций, но может быть полезен в условиях, когда утилита ssh-copy-id недоступна.
3.4. Проверка подключения
После размещения публичного ключа необходимо проверить возможность подключения без ввода пароля:
ssh user@remote-server-ip
Если подключение произошло успешно без запроса пароля — настройка выполнена корректно. Теперь команды scp в составе автоматизированного скрипта будут выполняться без интерактивного взаимодействия.
4. Интеграция с системой планирования Cron
Для обеспечения автоматического выполнения скрипта по расписанию необходимо интегрировать его с планировщиком задач Cron. Существует два основных способа добавления задач в cron.
4.1. Специализированные директории cron
Система cron поддерживает несколько специализированных директорий, в которые можно помещать исполняемые скрипты для автоматического запуска с заданной периодичностью:
- /etc/cron.hourly/ — скрипты выполняются каждый час;
- /etc/cron.daily/ — скрипты выполняются ежедневно;
- /etc/cron.weekly/ — скрипты выполняются еженедельно;
- /etc/cron.monthly/ — скрипты выполняются ежемесячно.
Для использования данного способа необходимо:
- Разместить скрипт в соответствующей директории;
- Сделать его исполняемым:
sudo chmod +x /etc/cron.hourly/backup.sh
Преимуществом данного метода является простота настройки. Недостатком — ограниченная гибкость: невозможно задать произвольное время выполнения (например, 00:00 или 23:59). Время запуска определяется системными настройками cron, обычно это происходит в начале соответствующего периода.
4.2. Настройка через crontab
Для более точного контроля над расписанием выполнения задач используется редактирование файла crontab. Это универсальный и наиболее гибкий способ настройки автоматизации.
Формат записи в crontab:
минута час день_месяца месяц день_недели команда
Примеры конфигурации:
Ежедневно в 00:00 — 0 0 * * * /path/to/script.sh
Ежедневно в 23:59 — 59 23 * * * /path/to/script.sh
Каждый час — 0 * * * * /path/to/script.sh
Каждые 10 минут — */10 * * * * /path/to/script.sh
Еженедельно в воскресенье в 3:00 — 0 3 * * 0 /path/to/script.sh
Ежемесячно 1-го числа в 2:00 — 0 2 1 * * /path/to/script.sh
Для добавления задачи необходимо выполнить:
crontab -e
Данная команда открывает файл конфигурации для текущего пользователя в текстовом редакторе. После добавления соответствующей строки и сохранения файла задача будет автоматически активирована.
Основные команды управления cron:
crontab -e — Редактирование задач текущего пользователя
crontab -l — Отображение всех задач текущего пользователя
crontab -r — Удаление всех задач текущего пользователя
crontab -u user -e — Редактирование задач указанного пользователя (требует прав root)
4.3. Мониторинг выполнения и диагностика
Для контроля корректности выполнения задач рекомендуется анализировать системные логи:
sudo tail -f /var/log/syslog
В случае обнаружения ошибок необходимо проверить права доступа к скрипту и корректность указания полных путей к исполняемым файлам.
Потенциальные проблемы и способы их решения
В процессе эксплуатации описанного решения могут возникать следующие проблемы:
1. Хранение пароля MySQL в открытом виде в тексте скрипта
Данный подход является небезопасным. Рекомендуется создание отдельного пользователя базы данных с минимально необходимыми привилегиями и использование конфигурационного файла .my.cnf для хранения учётных данных.
2. Требование ввода пароля при выполнении SCP
Проблема решается настройкой SSH-аутентификации по ключам, описанной в разделе 3 настоящей статьи.
3. Недостаточные права доступа для удаления файлов
Рекомендуется выполнять скрипт от имени суперпользователя либо настроить соответствующие права с использованием sudo с корректной конфигурацией файла /etc/sudoers.
4. Некорректная работа find с параметром -mtime
Следует учитывать, что -mtime +30 удаляет файлы, изменённые более 30 дней назад. Округление происходит в меньшую сторону, что может потребовать корректировки значения в зависимости от конкретных требований к периоду хранения.
5. Переменные окружения в cron
Скрипты, запускаемые через cron, выполняются в ограниченном окружении. Рекомендуется использовать абсолютные пути к исполняемым файлам (например, /usr/bin/mysqldump вместо mysqldump).
Заключение
Представленный в работе скрипт представляет собой полноценный и готовый к применению инструмент для автоматизации резервного копирования баз данных MySQL. Он реализует полный жизненный цикл управления резервными копиями: создание, сжатие, ротацию и удалённое хранение. Использование системы Cron обеспечивает регулярность выполнения операций, а настройка SSH-аутентификации по ключам гарантирует бесперебойную работу механизма удалённой передачи данных без участия оператора.
Предложенная архитектура отличается простотой реализацией, гибкостью настройки и может служить основой для построения более сложных систем резервного копирования с дополнительными функциями, такими как шифрование, параллельное копирование нескольких баз данных или интеграция с облачными хранилищами.