Стратегия резервного копирования VPS: правило 3-2-1, неизменяемые копии и проверка восстановления

Что копировать, а что пропустить

Копируйте то, что нельзя воссоздать скриптом или менеджером пакетов. Для большинства небольших серверов это:

• Данные приложения: загрузки, пользовательские файлы и всё, что приложение пишет во время работы.
• Базы данных в виде корректных дампов, а не копий живых файлов данных. Используйте pg_dump для PostgreSQL или mysqldump --single-transaction для MySQL, чтобы дамп был согласованным, пока база продолжает работать.
• Конфигурация: /etc, конфиги приложений, unit-файлы systemd, crontab, а также compose-файлы и тома Docker.
• Секреты и ключи, которые нельзя сгенерировать заново, в зашифрованном виде, а также сама парольная фраза шифрования бэкапов, хранимая не на сервере.

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

Правило 3-2-1 и то, чего оно не учитывает

Правило гласит: храните три копии данных, на двух разных типах носителей, причём одну копию вне площадки. Его обычно приписывают фотографу Питеру Крогу, который описал его в книге The DAM Book. Смысл в устранении единых точек отказа: умерший диск, удалённый том или потеря дата-центра не должны забирать с собой все копии.

Чего правило не говорит, так это может ли атакующий добраться до этих копий. Некоторые вендоры расширяют его до 3-2-1-1-0: ещё одна копия, неизменяемая или изолированная от сети, и ноль ошибок после автоматической проверки. Названия в разных источниках различаются, но оба дополнения именно те, что нужны для сервера, который могут скомпрометировать. Следуйте правилу, затем убедитесь, что хотя бы одну копию нельзя изменить или удалить с рабочего сервера, и что вы проверяете записанное.

Почему снимки провайдера не стратегия

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

Оставьте снимки как удобство, а независимые бэкапы на уровне файлов храните там, куда ваш аккаунт VPS не дотянется.

Зашифрованные бэкапы с restic или Borg

Два open-source инструмента закрывают почти всё, что нужно небольшому серверу: оба дедуплицируют, сжимают, поддерживают политики хранения и шифруют данные до того, как они покинут сервер. Согласно документации restic, для доступа к репозиторию нужен пароль, поэтому защитите его и храните копию офлайн: без него бэкапы нечитаемы. Минимальная процедура restic выглядит так:

export RESTIC_REPOSITORY=sftp:backup@backup-host:/srv/restic/vps1
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init
restic backup /etc /var/www /srv/data
restic check

Borg даёт важное дополнение: режим append-only. В документации Borg объясняется, что в этом режиме Borg никогда не перезаписывает и не удаляет зафиксированные данные, и что он предназначен прежде всего для защиты бэкапов при компрометации клиентской машины. Включается он ограничением ключа клиента на хосте бэкапов:

# ~/.ssh/authorized_keys на хосте бэкапов
command="borg serve --append-only --restrict-to-path /srv/backups/vps1",restrict ssh-ed25519 AAAA... vps1-backup

# на VPS
borg init --encryption=repokey ssh://backup@backup-host/srv/backups/vps1
borg create --stats ssh://backup@backup-host/srv/backups/vps1::{hostname}-{now} /etc /var/www /srv/data

Прочитайте оговорки в документации: append-only защищает только низкоуровневую структуру репозитория, очистка и удаление из обычной сессии всё равно могут навсегда стереть данные, обычный rm на хосте бэкапов его обходит, а атакующий всё равно может повредить несколько чанков. Авторы Borg рекомендуют запускать borg check --verify-data перед очисткой.

Сделайте одну копию неудаляемой

Хотя бы для одной копии уберите возможность удаления. В объектных хранилищах это называется Object Lock. По описанию Amazon, S3 Object Lock помогает предотвратить удаление или перезапись объектов на фиксированный или переменный срок либо бессрочно по модели write-once-read-many и работает только на бакетах с включённым версионированием. В режиме compliance ни один пользователь, включая root-пользователя аккаунта, не может удалить защищённую версию в период хранения; режим governance позволяет переопределить защиту пользователям со специальными правами. Другие провайдеры предлагают похожие функции под названиями вроде неизменяемых бакетов.

CISA даёт тот же совет в терминах безопасности: включать защиту от удаления или object lock на хранилищах, которые часто становятся целью ransomware. Относитесь к этому с оговорками. То же руководство предупреждает, что неизменяемое хранилище может не соответствовать критериям некоторых регуляторных требований, а блокировка защищает только те версии, которые вы заблокировали, поэтому задайте срок хранения, превышающий время, за которое вы заметите проблему. Помогает и схема pull: пусть отдельный хост бэкапов забирает данные с VPS, чтобы на VPS не было учётных данных, способных стереть историю. Руководство по защите от ransomware объясняет, почему это разделение важно.

Проверяйте восстановление, иначе бэкапов нет

Совет CISA: регулярно проверять доступность и целостность бэкапов в сценарии аварийного восстановления. Делайте два вида проверок. Лёгкую раз в месяц: восстановите один файл и дамп базы во временный каталог и убедитесь, что они открываются. Полную не реже раза в квартал и после крупных изменений: разверните чистый VPS, восстановитесь на него, запустите приложение и проверьте, что оно работает.

Используйте полную проверку, чтобы замерить два числа, которые стоит знать до инцидента. Допустимая потеря данных (RPO) показывает, сколько свежих данных вы можете позволить себе потерять, и определяет частоту бэкапов. Допустимое время простоя (RTO) показывает, как долго вы можете не работать, и подсказывает, достаточно ли быстр ваш процесс восстановления. Запускайте и проверки целостности, restic check или borg check --verify-data, чтобы повреждения обнаруживались на учениях, а не во время сбоя. Храните несколько поколений: CISA предупреждает, что перед восстановлением нужно найти дроппер, а более старая чистая копия даст вам запасной вариант, если новейшая уже заражена.

Хранение, расписание и мониторинг

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

Наконец, запишите процедуру восстановления, включая место хранения парольной фразы, хост с репозиторием и точные команды. В инциденте вы будете уставшими и ограниченными во времени, и проверенный чек-лист стоит гораздо больше добрых намерений. Это также часть общего плана защиты: см. чек-лист безопасности VPS.

Свежее напоминание, почему копия должна лежать вне провайдера: сбои дата-центров Яндекса в октябре 2026 года.

Термины из этого руководства: RPO и RTO (допустимая потеря данных и время восстановления) и Object Lock (неизменяемое хранение объектов).