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

MAATRIX

Бэкап нужен ровно один раз — в тот день, когда всё сломалось. Автоматические бэкапы на Ubuntu 24.04 с нуля избавляют от главной ошибки: надежды на «сделаю копию потом, руками». Мы настроим регулярное резервное копирование файлов и баз данных по расписанию, добавим ротацию старых копий и выгрузку на отдельное хранилище. К концу у вас будет система, которая молча делает копии каждую ночь, а вы про неё вспомните только когда она спасёт данные.

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

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

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

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

Начнём с файлов. Утилита 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. Предварительно создайте эту папку командой sudo mkdir -p /backup. Такой архив содержит и данные сайтов, и конфигурацию служб — этого достаточно, чтобы поднять сервис на новом сервере.

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

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

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

Команда выгружает все базы разом и сразу сжимает результат. Для автоматизации пароль в интерактивном виде не подходит — вместо флага -p заведите файл ~/.my.cnf с правами 600, где укажете логин и пароль; тогда mysqldump возьмёт их сам, без запроса. Такой дамп — это самодостаточный снимок данных на момент запуска: из него база разворачивается одной командой на любом сервере. Проверяйте, что файл дампа не пустой и имеет разумный размер, — пустой дамп означает ошибку доступа.

Стоит понимать, чем логический дамп отличается от простого копирования файлов базы, потому что от этого зависит целостность копии. Файлы MariaDB на диске постоянно меняются, пока сервер работает: часть данных лежит в памяти, часть уже записана, часть в процессе записи. Если скопировать эти файлы «на живую», можно получить внутренне противоречивый, нерабочий набор. Логический дамп через mysqldump этого лишён: он обращается к базе как клиент, читает данные согласованно и записывает их в виде понятных SQL-команд. В результате получается портируемый снимок, который развернётся не только на этой же версии сервера, но и на другой, и даже при переезде с MariaDB на MySQL. Именно поэтому для бэкапа баз почти всегда выбирают дамп, а не копирование файлов, — надёжность важнее скорости.

Пишем скрипт бэкапа

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

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

Эта строка находит все архивы старше семи дней и удаляет их — так реализуется ротация. Сделайте скрипт исполняемым командой sudo chmod +x /usr/local/bin/backup.sh. Скрипт удобен тем, что вся логика бэкапа собрана в одном месте: захотите изменить, что копировать или сколько хранить, — правите один файл. Обязательно запустите его вручную первый раз и убедитесь, что в /backup появились свежие непустые архивы.

Ставим задачу в cron

Теперь заставим скрипт запускаться сам каждую ночь. Откройте таблицу заданий cron:

sudo crontab -e

Добавьте строку, которая запускает бэкап каждый день в 3:30 ночи — время малой нагрузки:

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

Пять полей в начале — это минуты, часы, день месяца, месяц и день недели. Конструкция 30 3 * * * означает «в 3:30 каждый день». Дописка >> /var/log/backup.log 2>&1 сохраняет вывод и ошибки в лог, чтобы потом можно было убедиться, что бэкап отработал. Проверьте, что задание добавилось, командой sudo crontab -l. С этого момента копии создаются автоматически.

Одна из частых и обидных ошибок — настроить бэкап и ни разу не проверить, что он реально отрабатывает по расписанию. Cron запускает задачи в урезанном окружении, где нет привычных переменных вашей интерактивной сессии, и скрипт, отлично работающий при ручном запуске, может молча падать под cron из-за неверных путей. Поэтому через день после настройки обязательно загляните в /var/log/backup.log и в саму папку /backup: там должны лежать свежие архивы с сегодняшней датой, а лог — не содержать ошибок. Хорошая практика — в конце скрипта отправлять себе короткое уведомление об успехе или, наоборот, письмо при сбое. Тогда вы узнаете о неработающем бэкапе не в день катастрофы, а сразу, и успеете починить его, пока данные ещё целы.

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

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

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

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

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

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

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