Бэкап всего сервера целиком

MAATRIX

Сервер живёт до первого сбоя диска, неудачного обновления или ошибочной команды — и всё, что на нём было, исчезает. Бэкап всего сервера целиком превращает катастрофу в получасовое неудобство: вы восстанавливаете систему из копии и продолжаете работу. Ниже разберём по шагам, что именно копировать, как автоматизировать резервное копирование и, главное, как проверить, что бэкап реально восстанавливается — с командами и практикой эксплуатации сервера.

Что входит в полный бэкап

Слова «бэкап всего сервера» звучат монолитно, но на деле копия складывается из нескольких разных по природе частей, и каждую нужно снять правильно. Первое — пользовательские данные и файлы сайтов: содержимое веб-каталогов, загрузки, документы. Второе — базы данных: их нельзя копировать как обычные файлы на ходу, нужен корректный дамп. Третье — конфигурация системы и сервисов: настройки веб-сервера, фаервола, cron, системные файлы из /etc. Четвёртое — список установленных пакетов, чтобы быстро воссоздать окружение.

Есть два подхода к полному бэкапу. Первый — образ всего диска (снапшот), который снимает сервер целиком, включая систему. Многие провайдеры предлагают снапшоты на уровне панели — это самый простой способ получить копию всей машины одной кнопкой. Второй — файловый бэкап отдельных частей, который гибче, занимает меньше места и позволяет восстанавливать выборочно. На практике их комбинируют: периодический снапшот всей системы плюс частые файловые бэкапы данных и баз.

Копируем файлы

Для файлового бэкапа удобнее всего rsync: он копирует только изменившееся, переживает разрывы и не гоняет одно и то же дважды. Скопируйте важные каталоги на другой сервер или в отдельное хранилище:

rsync -avz --delete /var/www/ user@backup-host:/backups/www/
rsync -avz /etc/ user@backup-host:/backups/etc/

Каталог /var/www хранит сайты, /etc — конфигурацию системы и сервисов. Ключ -a сохраняет права и владельцев, -z сжимает при передаче. Флаг --delete держит копию точным зеркалом источника, удаляя то, что удалено на сервере, — используйте его осознанно, чтобы не потерять нужное. Дополнительно зафиксируйте список установленных пакетов, чтобы при восстановлении не вспоминать, что стояло:

dpkg --get-selections > /backups/packages.list

Этот список позволяет одной командой доустановить те же пакеты на новом сервере.

Дамп баз данных

Базу нельзя просто скопировать файлами на работающем сервере — вы получите несогласованный и, скорее всего, нерабочий бэкап. Нужен логический дамп средствами самой СУБД, который снимает согласованное состояние. Для MySQL или MariaDB это делается так:

mysqldump --single-transaction --all-databases > /backups/mysql-$(date +%F).sql

Ключ --single-transaction снимает согласованный дамп без блокировки таблиц, а подстановка даты в имя файла даёт понятную историю копий. Для PostgreSQL аналогичную роль играет pg_dumpall. Храните дампы вместе с файловыми бэкапами и обязательно сжимайте — текстовые дампы отлично ужимаются gzip в разы.

Автоматизация и правило 3-2-1

Бэкап, который делается вручную по настроению, рано или поздно не сделается в самый нужный момент. Автоматизируйте резервное копирование через cron: соберите шаги в один скрипт и запускайте его по расписанию, например ежедневно ночью. Скрипт должен снимать дамп базы, синхронизировать файлы, складывать всё с датой и удалять копии старше заданного срока, чтобы не забить хранилище.

Держите в голове правило 3-2-1: три копии данных, на двух разных носителях, одна — вне сервера. Главная ошибка новичков — хранить бэкап на том же сервере, что и данные: при сбое диска или потере доступа к серверу вы теряете и данные, и их копию разом. Бэкап должен лежать в другом месте — на отдельном сервере, в объектном хранилище или у другого провайдера. Только тогда он реально страхует от катастрофы, а не создаёт иллюзию защиты.

Отдельно продумайте глубину истории копий, а не только их наличие. Одной последней копии часто недостаточно, и вот почему: беда не всегда происходит мгновенно и заметно. Сайт могли взломать неделю назад, база могла потихоньку портиться несколько дней, а вредная правка — попасть в данные вчера. Если вы храните только вчерашний бэкап, он уже содержит проблему, и откатываться некуда. Поэтому разумная схема хранит несколько поколений: ежедневные копии за последнюю неделю, еженедельные за последний месяц, и хотя бы одну-две месячные. Такая ротация занимает не намного больше места благодаря сжатию, но даёт возможность откатиться не только на вчера, но и на заведомо здоровую точку в прошлом. Настройте скрипт так, чтобы он не просто перезаписывал одну копию, а вёл эту лесенку поколений и сам удалял то, что старше заданных сроков.

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

Самая опасная ошибка — считать, что бэкап есть, ни разу не попробовав его восстановить. Копия, которая не разворачивается, бесполезна, а узнать об этом в момент аварии — худший сценарий. Поэтому проверка восстановления обязательна и должна быть регулярной. Возьмите свежий бэкап и разверните его на тестовом сервере или в отдельном окружении: восстановите файлы, залейте дамп базы, поднимите сайт и убедитесь, что он работает с реальными данными.

Такая проверка ловит типовые проблемы заранее: неполный дамп, битый архив, забытую часть данных, несовместимость версий. Раз в месяц провести пробное восстановление — недолго, а спокойствия даёт много. Регулярная проверка бэкапов — признак зрелой эксплуатации сервера, отличающий тех, у кого копии реально работают, от тех, у кого они есть только на бумаге.

Куда складывать копии

Место хранения бэкапов не менее важно, чем сам факт их создания. Идеально держать копии у другого провайдера или в отдельном хранилище, чтобы проблемы у основного хостинга не задели резерв. Для этого удобен недорогой VPS или хранилище в другой локации, куда скрипт складывает бэкапы по расписанию. Если основной сайт для российской аудитории, а копии вы хотите держать за рубежом, или наоборот, у MAATRIX есть ноды в RU, US и UK, и второй сервер под бэкапы удобно взять там же, с оплатой из России картой или криптой. Разнесение основного сервера и хранилища копий по разным площадкам — надёжная страховка от локальных сбоев.

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