Ручной
mysqldump работает ровно до того момента, пока кто-то не забыл его запустить. Для продакшна нужен автоматический запуск по расписанию.Скрипт с ротацией и сжатием
Создаём файл
/opt/scripts/mysql-backup.sh:#!/bin/bash
BACKUP_DIR="/opt/backups/mysql"
CONTAINER="mysql-container"
DB_USER="root"
DB_PASS="yourpassword"
DATABASE="mydatabase"
RETENTION_DAYS=7
mkdir -p "$BACKUP_DIR"
FILENAME="$BACKUP_DIR/${DATABASE}_$(date +%Y%m%d_%H%M%S).sql.gz"
docker exec "$CONTAINER" mysqldump \
-u "$DB_USER" -p"$DB_PASS" \
--single-transaction \
--routines \
--triggers \
"$DATABASE" | gzip > "$FILENAME"
if [ $? -eq 0 ]; then
echo "Backup completed: $FILENAME"
else
echo "Backup failed!" >&2
exit 1
fi
find "$BACKUP_DIR" -name "*.sql.gz" -mtime +$RETENTION_DAYS -delete
Флаг
--single-transaction снимает дамп без блокировки таблиц — важно для InnoDB в продакшне. --routines и --triggers включают в дамп хранимые процедуры и триггеры, которые по умолчанию не экспортируются. find в конце удаляет файлы старше RETENTION_DAYS дней.Добавляем в cron. Запуск каждый день в 4 утра:
0 4 * * * /opt/scripts/mysql-backup.sh >> /var/log/mysql-backup.log 2>&1
Ограничения
Для небольшого пет-проекта этого хватит. Но у подхода есть три слабых места, которые становятся проблемой при серьёзной нагрузке.
Нет алертов при сбое. Скрипт пишет ошибку в лог, но никто не узнает об этом, пока не заглянет туда вручную. Бэкап может не работать неделями без каких-либо уведомлений.
Файлы хранятся локально. Если сервер упадёт или диск сгорит, бэкапы уйдут вместе с данными. Для надёжности нужен вывод в S3 или другое внешнее хранилище.
Плохо масштабируется. Несколько баз — значит несколько копий скрипта, которые нужно поддерживать отдельно.
Для проекта, потеря данных в котором некритична, этот скрипт закрывает задачу. Для всего остального эти три пункта рано или поздно дадут о себе знать.
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#root_prompt