AlmaLinux 9: автоматические бэкапы с нуля

MAATRIX

Бэкап нужен ровно один раз — в тот день, когда всё сломалось. Автоматические бэкапы на AlmaLinux 9 с нуля избавляют от главной ошибки: надежды на «сделаю копию потом, руками». Мы настроим регулярное резервное копирование файлов и баз данных по расписанию через планировщик cron, добавим ротацию старых копий и выгрузку на отдельное хранилище. Учтём специфику RHEL-семейства: планировщик здесь ставится пакетом cronie, а служба называется crond.

Что и куда бэкапить

Прежде чем настраивать копирование, определитесь, что именно ценно. На типовом сервере это три вещи: файлы сайтов и приложений (обычно в /var/www), базы данных и конфигурация служб (в /etc). Пользовательские загрузки, контент, настройки — всё это невосстановимо, в отличие от самих программ, которые можно переустановить. Поэтому бэкапим данные, а не систему целиком.

Второй важный принцип — правило 3-2-1: три копии данных, на двух разных носителях, одна из них вне сервера. Копия, лежащая на том же диске, что и оригинал, бесполезна при отказе этого диска или удалении всего сервера. Поэтому по-настоящему надёжный бэкап всегда уезжает на отдельное хранилище или второй сервер. Мы построим схему именно так: сначала собираем архив локально, потом отправляем его наружу. Локальная копия — это половина дела, а не всё.

Ставим планировщик cron

В минимальной установке AlmaLinux планировщик задач может отсутствовать, поэтому первым делом поставьте его и включите службу:

dnf install -y cronie
systemctl enable --now crond

Это отличие от Debian, где cron обычно есть сразу. В RHEL-семействе пакет называется cronie, а фоновая служба — crond. После установки планировщик готов запускать задания по расписанию. Проверить, что служба работает, можно командой systemctl status crond. Без запущенного crond никакие задания из crontab выполняться не будут — распространённая причина «молчащих» бэкапов на свежем AlmaLinux, о которой стоит помнить.

Делаем архив файлов

Утилита tar собирает нужные папки в один сжатый архив с датой в имени, чтобы копии не перезаписывали друг друга:

tar -czf /backup/files-$(date +%F).tar.gz /var/www /etc

Разберём: -c создаёт архив, -z сжимает его gzip, -f задаёт имя файла, а конструкция $(date +%F) подставляет текущую дату. В результате в папке /backup появится файл вида files-2026-08-24.tar.gz. Предварительно создайте эту папку командой mkdir -p /backup. Такой архив содержит и данные сайтов, и конфигурацию служб — этого достаточно, чтобы поднять сервис на новом сервере.

Сохраняем базы данных

Файлы базы нельзя просто скопировать «на живую» — можно получить битую копию. Правильный способ — снять логический дамп через mysqldump, который выгружает содержимое базы в SQL-файл:

mysqldump --all-databases | gzip > /backup/db-$(date +%F).sql.gz

Стоит понимать, чем логический дамп отличается от копирования файлов базы. Файлы MariaDB на диске постоянно меняются, пока сервер работает, и копия «на живую» может оказаться внутренне противоречивой. Дамп через mysqldump этого лишён: он обращается к базе как клиент, читает данные согласованно и записывает их в виде SQL-команд. Результат — портируемый снимок, который развернётся и на другой версии сервера. Для автоматизации задайте доступ через файл ~/.my.cnf с правами 600, чтобы не вводить пароль вручную при каждом запуске.

Пишем скрипт и ставим задачу

Объедините оба шага в скрипт /usr/local/bin/backup.sh, добавив в конец удаление старых копий:

find /backup -name '*.gz' -mtime +7 -delete

Эта строка находит все архивы старше семи дней и удаляет их — так реализуется ротация, без которой любая система бэкапов рано или поздно переполнит диск. Меняя число в -mtime +7, вы регулируете глубину хранения. Сделайте скрипт исполняемым командой chmod +x /usr/local/bin/backup.sh, запустите вручную и убедитесь, что в /backup появились непустые архивы. Затем добавьте задание в cron командой crontab -e:

30 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

Пять полей — минуты, часы, день месяца, месяц и день недели; 30 3 * * * означает «в 3:30 каждый день». Через день загляните в лог и папку /backup: cron запускает задачи в урезанном окружении, и скрипт, работающий вручную, может падать под cron из-за путей, поэтому проверка обязательна.

Выгружаем копии на второй сервер

Локальные архивы надо увезти наружу — это ключ к правилу 3-2-1. Утилита rsync эффективно синхронизирует папку /backup на другой сервер по SSH, передавая только изменения:

rsync -az /backup/ user@backup-server:/remote-backup/

Флаг -a сохраняет права и время файлов, -z сжимает трафик. Чтобы rsync работал без пароля в автоматическом режиме, настройте вход по SSH-ключу между серверами. Добавьте эту команду в конец скрипта бэкапа — и каждая ночная копия будет сразу уезжать на отдельную машину. Тогда даже полная потеря основного сервера не уничтожит ваши данные: они лежат в безопасном месте, и восстановление сводится к скачиванию последнего архива.

Стоит оценить, чем rsync лучше простого копирования всей папки заново при каждом бэкапе. Rsync сравнивает файлы на источнике и получателе и передаёт только то, что изменилось, — новые и обновлённые файлы, пропуская нетронутые. Для бэкапов, где день ото дня меняется малая часть данных, это огромная экономия: вместо гигабайтов по сети идут мегабайты, а сама синхронизация занимает секунды вместо минут. К тому же rsync устойчив к обрывам: прервавшуюся передачу можно просто запустить снова, и она продолжит с места остановки, а не начнёт всё заново. Именно поэтому rsync стал стандартом для переноса и синхронизации данных между серверами — он быстр, экономен и надёжен, а работая поверх SSH, ещё и защищает передаваемые копии шифрованием.

Проверяем восстановление

Бэкап, который ни разу не разворачивали, — это лотерейный билет, а не страховка. Хотя бы раз проверьте весь цикл восстановления: возьмите свежий архив файлов, распакуйте его во временную папку командой tar -xzf, убедитесь, что данные на месте. Затем разверните дамп базы в тестовую базу командой вида zcat db-дата.sql.gz | mysql testdb и проверьте, что таблицы читаются. Только после успешной проверки можно считать систему бэкапов рабочей. Регулярно, хотя бы раз в квартал, повторяйте эту проверку — файлы могут повреждаться, права меняться, а скрипт со временем ломаться от обновлений. Проверенный бэкап — единственный, на который можно положиться в критический момент.

Частые вопросы