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

MAATRIX

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

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

Прежде чем настраивать копирование, определитесь, что именно ценно. На типовом сервере это три вещи: файлы сайтов и приложений (обычно в /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. Предварительно создайте эту папку командой 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

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

Ротацию стоит пояснить подробнее, потому что без неё любая система бэкапов рано или поздно переполняет диск и перестаёт работать. Идея проста: свежие копии ценны, а очень старые — почти нет, ведь если вы заметили пропажу данных, то обычно в течение нескольких дней, а не месяцев. Поэтому нет смысла хранить бэкапы бесконечно — разумнее держать глубину в одну-две недели и удалять всё, что старше. Параметр -mtime +7 в команде find как раз означает «изменённые более семи дней назад». Меняя это число, вы регулируете глубину хранения: +14 оставит две недели, +30 — месяц. Некоторые администраторы усложняют схему, храня ежедневные копии за неделю плюс по одной еженедельной за пару месяцев, но для начала достаточно простой ротации по возрасту — она надёжна и понятна.

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

Теперь заставим скрипт запускаться сам каждую ночь. Откройте таблицу заданий cron командой 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 сохраняет вывод и ошибки в лог. Важный нюанс: cron запускает задачи в урезанном окружении без привычных переменных вашей сессии, и скрипт, отлично работающий вручную, может молча падать под cron из-за неверных путей. Поэтому через день обязательно загляните в лог и в папку /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 и проверьте, что таблицы читаются. Только после успешной проверки можно считать систему бэкапов рабочей. Регулярно, хотя бы раз в квартал, повторяйте эту проверку — файлы могут повреждаться, права меняться, а скрипт со временем ломаться от обновлений. Проверенный бэкап — единственный, на который можно положиться в критический момент.

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