Бэкап VPS без боли: резервное копирование данных и проверка восстановления по стратегии 3-2-1 для сайта/бота/магазина

Бэкап VPS нужен для защиты данных. Как правило, от их безвозвратной потери, которая может возникнуть как следствие взлома(-ов), «человекошибок» или банальных поломок оборудования.

Бэкап позволяет быстро восстановить работу, минимизируя простои. А потерю данных – и вовсе нивелируя.

Только вот на первый взгляд кажется, что нормально забэкапить ВПС – сложно. Причем, очень. Но на деле все несколько проще. Мы подготовили небольшой гайд – читайте дальше: разберемся, что к чему.

Что такое правила бэкапа 3-2-1 и почему это «золотой стандарт» защиты данных

Стратегия 3-2-1 – ходовой вариант для бэкапа VPS.

Она учитывает сразу три вариации рисков: технические сбои, человеческий фактор и потенциально-реальную катастрофу (взять все то же затопление серверной, например).

(3) копии данных

Первая цифра в формуле выше означает, что всегда должно быть как минимум три копии. Оригинал – первая из них. Дальше – две других. Они дадут право на ошибку: вы всегда сможете восстановить актуальную версию или откатиться к более ранней, если проблема вдруг обнаружится не сразу.

(2) разных типа носителей

Второй момент – это хранить копии на двух разных типах носителей.

Любой «физический» вариант может выйти из строя, и часто это происходит по +- схожим причинам. Иначе говоря: если хранить две копии на двух хардах, которые лежат друг на друге, и случится скачок напряжения, сгореть могут оба сразу.

Так что варианты следует комбинировать.

Например, можно держать одну копию на небольшом SSD для быстрого и оперативного восстановления, а вторую – на условном HDD. Облако – тоже не самый плохой вариант.

(1) оффсайт-копия

В довершении – оффсайт копия. Она хранится за пределами основного местоположения. Это – реальное спасение на случай форс-мажора.

Пожар, потоп, кража, даже банальные перебои в электричестве – все это может сделать локальные копии недоступными сразу же.

Собственно, по этой причине «выносная» копия обязательно должна находиться в ином месте. Например, в другом здании. Причем, «здании» – это как самый минимум. Кто-то переносит их даже в другую область, и нельзя сказать, что это прямо уж лишено смысла.

Выбираем инструмент: почему rsync идеален для наших задач

С теорией более или менее разобрались, но как вообще бэкапить сервера в реальном сценарии? VPS, например?

Rsync может хорошо помочь с этим. Его фишка – в так называемом «дельта-кодировании». То есть когда программа запускается повторно, она не перезаписывает файлы целиком. Вместо этого rsync анализирует, какие блоки данных изменились с прошлого раза, и передает лишь только их.

Это сильно экономит что трафик, что всегда уместно.

Также rsync работает поверх SSH, что априори означает наличие шифрования. Не нужно будет думать и о том, как защищать бэкапы по ходу дела. Rsync также позволяет настраивать исключения, так что при необходимости можно будет легко убрать из бэкапа папки с кэшем или временными файлами, чтобы не забивать свободное место мусором.

Важно: Если просто синхронизировать папку с сервера на внешний диск через rsync -av /source /destination, файлы в папке назначения сами по себе удаляться не будут — даже если на сервере их уже стерли. По умолчанию rsync только добавляет новые данные и обновляет изменившиеся. А вот удаление на принимающей стороне включается отдельно, через флаг --delete. То есть именно команда вроде rsync -av --delete /source /destination будет поддерживать точное зеркало источника. И это удобно, но с оговоркой: если файл удалили по ошибке, повреждение тоже может «доехать» до копии при следующей синхронизации.

Впрочем, rsync умеет не только зеркалить данные, но и помогать с версионными бэкапами. Для этого используют --link-dest: с ним можно создавать копии хоть за каждый день, при этом неизменившиеся файлы не дублируются физически, а переиспользуются через жесткие ссылки. В итоге место расходуется заметно экономнее, а на руках остаются отдельные точки восстановления. То есть при необходимости можно вернуть файл не только в его текущем виде, но и таким, каким он был неделю или даже месяц назад.

Проектируем архитектуру 3-2-1 для проекта

Начнем с основ.

Для сайта, бота или магазина архитектура должна давать быстрый RTO (время восстановления) и разумный RPO (точка восстановления). Что до схемы, то основная – это, собственно, и VPS сервер.

Также должна присутствовать локальная резервная копия. Внешняя – тоже. А вот носителей может быть несколько. На первом уровне, скажем, – локальный диск, а на втором – NAS/другой диск. На третьем же – удаленный сервер по SSH, который и будет обеспечивать вынос за пределы площадки.

Что копировать: готовим данные к бэкапу. Что не копировать

Просто копировать все подряд – идея сомнительная, если и вовсе не откровенно плохая. Это приведет к переполнению диска и к бардаку в целом. Так что нужен точечный подход. Ниже – список того, что всегда имеет смысл бэкапить:

• Код и файлы проекта – обычно директории /var/www или /home/user/project.
• Конфигурации – папки с настройками сервера (/etc/nginx, /etc/apache2), скрипты запуска и, естественно, SSL-сертификаты.
• Базы данных – копировать служебные файлы БД (например, в /var/lib/mysql) «на горячую» нельзя – гарантированно получите сломанный архив. Поэтому перед синхронизацией всегда стоит сделать дамп. Как вариант – с помощью mysqldump или pg_dump.

А вот – без чего точно можно обойтись:

• Виртуальные системы – папки /proc, /sys, /dev, /run и прочие создаются системой при загрузке. Копировать их нет никакого смысла.
• Мусор и временные файлы – директории с кэшем (/var/cache) и временными файлами (/tmp). Их избегаем. А логи (/var/log) архивировать можно, но часто этого делать все равно не нужно. Если они и пригождаются, то в основном для аналитики.
• Сами бэкапы – не храните резервные копии внутри папки, которую будете копировать. Сильно замусорится.

Пишем скрипт автоматического бэкапа с rsync

Скрипт пишется в rsync через командную строку. Чтобы скопировать содержимое одной папки в другую, используется флаг «-r».

Например: sudo rsync -r директория1/ директория2

Важно: Немного по поводу слэша выше – если он есть, в папку скопируются только файлы из «директории1». Если слэш опустить, скопируется сама папка целиком – вместе со всем содержимым внутри.

Для создания же «полноценных» копий чаще используется флаг «-a». Он сохраняет не только сами файлы, но и все их атрибуты: взять все те же права доступа.

Например: sudo rsync -a директория1/ директория2

По SSH, кстати, тоже можно создавать копии – команда в данном случае будет выглядеть примерно так:

sudo rsync -avz --progress --delete -e «ssh -p 2026» [email protected]:~/backup_data

Флаги -avz отвечают за архивный режим, вывод и сжатие при передаче. Ключ -delete – за синхронизацию. Он удаляет файлы, которых больше нет в оригинале. Конструкция -e «ssh -p 2026» указывает, что передача идет по SSH, а [email protected] – это просто учетные данные и сам адрес сервера-хранилища.

Важно: Как мы уже упоминали выше, кэш и логи можно (да и нужно) исключать из бэкапа. Но не упоминали мы того, что rsync предлагает под это целый отдельный ключ – собственно, exclude. Он подойдет, если нужно исключить один-два типа файлов. Например, --exclude *.png добавит в исключения все картинки этого формата.

Автоматизируем по расписанию (cron)

Ручной запуск бэкап-тестов хорош сам по себе, но для реальной работы, конечно, так или иначе понадобится автоматизация – всего самостоятельно не переделаешь. Самое первое и основное, что понадобится для ее настройки, – это поработать над сервером-клиентом. Тут нужно отредактировать конфиг /etc/rsyncd.conf.

Он заполняется: указываются пути для логов и файла процесса, а затем описывается отдельный блок данных. Также прописывается, какая папка будет копироваться (path = /var/log) и от имени какого пользователя (uid = root). Здесь же указывается путь к файлу с паролем (secrets file = /etc/rsyncd.scrt), где и будут храниться данные для авторизации бэкап-пользователя.

Важно: После создания файла на него обязательно выставляются права 0600 – то есть только рут-доступ.

На сервере же нужно будет написать скрипт, который сможет забирать данные.

Делается это путем создания файла – /bin/server_backup.sh. В нем описываются переменные: IP адрес сервера-источника (srv_ip), имя модуля (srv_dir=data), пользователя (srv_user=backup) и локальная папка. Последняя – как раз для сохранения бэкапов.

Строка запуска rsync в скрипте будет использовать все эти переменные для подключения к источнику и скачивания данных в папку /current/. Дополнительно стоит настроить и систему инкрементных бэкапов: старые версии файлов будут складываться в /increment/ с пометкой даты.

Когда скрипт отлажен и нормально запускается вручную, остается добавить его в расписание. Для этого нужно открыть редактор планировщика (командой sudo crontab -e) и сделать пару вещей – синтаксис cron прост: пять полей (минута, час, день месяца, месяц, день недели) и команда. Например, запись 40 13 * * * /bin/server_backup.sh будет значить, что скрипт будет запускаться каждый день, и делать это в 13:40.

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

Все сделано, но нужно убедиться в работоспособности. Вот как можно проверить бэкап:

1. Развернуть изолированный тестовый хост с той же виртуальной платформой/хранилищем.
2. Скопировать на тест-хост выбранный бэкап.
3. Выполнить восстановление образа/файлов/дисков.
4. Запустить VM и проверить загрузку ОС.
5. На уровне приложений проверить сервисы (преимущественно сам сервер и БД).
6. Сверить данные – контрольные суммы/количество файлов/базы.

Если все хорошо, то тестовую машину можно удалять. При проблемах – задокументировать ошибки и сделать откат.

Мониторинг и алерты: как понить, что бэкап сломался

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

И вот здесь отлично помогает постоянный мониторинг. А если конкретнее, то:

• Логирование – всегда есть смысл парсить файл /var/log/backup.log. Нужно периодически проверять, не появляются ли там ошибки.
• Подключение метрик – крайне желательно подключить и сторонние системы мониторинга. Они должны отслеживать «свежесть» бэкапа и его размер. С первым все понятно, что до второго – если он стал подозрительно небольшим, возможно, данные попросту не скопировались.
• Настройка алертов – настройте себе отправку уведомлений при сбое задачи в cron. Сделать это можно хоть на почту. Ну или в любое другое место, куда будет удобно. Для критичных проектов желательно использовать несколько разных каналов.

Итог здесь довольно простой: бэкап VPS — это не про «на всякий случай», а про нормальную и предсказуемую работу проекта. Один раз собрать внятную схему, понять, что именно копировать, куда складывать копии и как потом все это поднимать обратно, — уже половина дела. Дальше остается только следить, чтобы механизм действительно работал. Потому что сам по себе факт наличия бэкапа еще ничего не гарантирует. Гарантию дает только успешное восстановление — без паники, спешки и неприятных открытий в самый неподходящий момент.