Бэкап VPS, который реально восстанавливается

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

Хостинг, который никогда не спрашивал вашу личность, взамен от чего-то отказывается — и здесь честно об этом сказать. Здесь нет менеджера, которому можно позвонить, нет тикета, который воскресит стёртый том, и наша собственная политика хранения прямо называет причину: данные сервера уничтожаются в течение 24 часов после его удаления, диски криптографически стираются, а не форматируются, и никакие бэкапы не хранятся. Это то же самое свойство, за которое платформу и выбирают — просто с другой стороны. Всё, что вы захотите вернуть после плохой ночи, должно уже лежать где-то ещё, и положить его туда — ваша задача.

Что на самом деле убивает серверы

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

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

Снапшот — это не бэкап, и ваш хостер тоже не бэкап

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

Здесь это различие важнее, чем у обычного хостера, потому что привычные страховочные сетки убраны намеренно. Никто не заходит на клиентские серверы, поэтому никто не заметит, что ваша задача бэкапа не выполняется с марта. К аккаунту не привязана личность, поэтому нет человеческого пути вида «докажите, кто вы, и мы восстановим». А удаление здесь по-настоящему необратимо: закончившийся баланс — это событие потери данных, а не биллинговое событие.

Правило 3-2-1, переписанное для тех, кто никогда не показывал документы

Классическое правило гласит: три копии, на двух видах носителей, одна из них — за пределами площадки. Оно написано для эпохи ленты и вращающихся дисков, и пункт про носители незаметно перестал что-либо значить: диск продакшена — NVMe, диск бэкап-цели — тоже NVMe, и называть это «двумя видами носителей» — это история, которую вы рассказываете сами себе. Стоит сохранить пункт про дистанцию, а для офшорной инфраструктуры дистанция измеряется не в километрах.

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

На практике это дёшево. Бэкап-цели не нужны ядра, и сеть ей почти не нужна — нужны диск и адрес. Самый младший тариф VPS в другой из наших семи локаций — вполне достойная точка назначения для restic или Borg, а для архивов на терабайты выделенный сервер с настоящими дисками обходится дешевле за терабайт, чем любое объектное хранилище. Там, где данных действительно много и читают их редко, экономика с большим отрывом на стороне «железа».

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

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

Push, pull и ошибка, из-за которой одна плохая ночь съедает обе копии

Вот схема, которую почти все строят первой. Задача на продакшен-сервере запускается по ночам, хранит ключ или токен для бэкап-цели, подключается и отправляет данные (push). Это работает, это просто, и у этого есть свойство, которое становится видно только в худший день жизни сервера: кто контролирует продакшен-машину, тот контролирует и бэкапы.

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

Есть два чистых решения, и они хорошо сочетаются с базовым хардненингом, который вы уже должны были сделать.

• Цель в режиме append-only. Оба основных инструмента поддерживают режим, в котором клиент может добавлять данные, но не может их удалять. Borg делает это, закрепляя SSH-ключ на цели за borg serve --append-only; restic делает то же самое REST-сервером, запущенным с --append-only. Продакшен-сервер пишет каждую ночь и структурно не способен уничтожить историю. Удаление старых снапшотов происходит уже на стороне цели, в сессии, которую продакшен-машина начать не может.
• Pull вместо push. Разверните направление: бэкап-хост сам подключается к продакшену, читает и сохраняет. У продакшена вообще нет учётных данных для цели, поэтому красть нечего. Ограничьте ключ, который используется на стороне продакшена, директивой restrict и принудительной command=, чтобы украденный ключ бэкапа не превратился в шелл.

Pull — более надёжная модель и требует чуть больше работы для настройки; append-only почти ничего не стоит, если вы уже используете Borg или restic. Любой из этих вариантов превращает «атакующий удалил мои бэкапы» из результата в неудавшуюся попытку. Если вы возьмёте из этого гайда только одну мысль, пусть это будет она.

Шифруйте на источнике, а затем решайте, кто держит ключ

Оба серьёзных инструмента шифруют данные на той машине, которую бэкапят, прежде чем что-либо уходит в сеть. Цель хранит блоки, которые не может расшифровать — именно это делает копию у другого провайдера безопасной. Ваш второй хост не обязан быть заслуживающим доверия или хотя бы дружелюбным; ему нужно быть достижимым и иметь диск. Именно это свойство превращает «сервер в стране, о которой я ничего не знаю» из риска в инфраструктуру.

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

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

• Храните парольную фразу на сервере только как файл, читаемый исключительно root, на который ссылаются через --password-file, чтобы она никогда не попадала в список процессов или историю шелла.
• Храните человекочитаемую копию вне всех задействованных машин. Бумажка в ящике стола действительно надёжнее менеджера паролей, синхронизирующегося с аккаунтом, доступ к которому вы тоже можете потерять.
• Добавьте в репозиторий второй ключ — командой restic key add или экспортированным ключом Borg — чтобы одна забытая парольная фраза была неудобством, а не концом архива.

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

Выбор инструмента одной таблицей

Выбор инструмента значит меньше, чем направление соединения и состояние вашего ключа, поэтому он идёт шестым пунктом, а не первым. Тем не менее разница между инструментами реальна, и неверная форма под задачу создаёт лишнюю работу потом.

Для одного сервера restic на второй VPS — самый короткий путь к правильному решению. Для сидбокса, медиаархива или чего угодно с множеством похожих крупных файлов дедупликация Borg — это разница между забитым диском и комфортным; гайд по сидбоксу подробнее разбирает сторону хранения для такой нагрузки.

Всё, что запущено, — это не файл

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

Три выхода, в порядке возрастания усилий. Сделать дамп: mysqldump --single-transaction даёт согласованный дамп InnoDB без блокировки записывающих процессов, а pg_dump делает то же самое для PostgreSQL. Снять снапшот: заморозить файловую систему или сделать снапшот LVM или ZFS, скопировать из снапшота, освободить его — так поступают с наборами данных, слишком большими для ночного дампа. Или остановить: для небольшого сервиса две минуты простоя в 04:00 — вполне достойная стратегия консистентности, и единственная, у которой нет краевых случаев.

Та же логика касается не только баз данных. Записываемый слой контейнера одноразовый, а вот его тома — нет, как и лежащий рядом файл docker compose с окружением: бэкап, который восстанавливает данные, но не определение, оставляет вас пересобирать стек по памяти. Очереди сообщений, Redis с включённой персистентностью и почтовый спул, в который пишет MTA, заслуживают того же отношения: заморозить, снять снапшот или сделать дамп, но никогда не копировать напрямую в надежде на лучшее.

Что бэкапить и что все забывают

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

• /etc целиком, плюс юниты и таймеры systemd, которые вы написали, и любые crontab, лежащие вне него.
• Сертификаты TLS и их приватные ключи, или как минимум ключ аккаунта ACME, чтобы сертификаты продлевались, а не начинались с нуля.
• Правила файрвола и список пакетов, которые вместе восстанавливают облик машины быстрее, чем любая память о нём.
• Секреты приложения и файлы окружения — те, что намеренно исключены из вашего репозитория кода и потому больше нигде не хранятся.
• DNS-записи, экспортированные в текст, включая обратные записи и записи PTR, которые живут у провайдера, а не на сервере.

Непроверенное восстановление — это слух

Программа для бэкапов отчитывается сама о себе, и отчитывается она честно, но не о том, что важно. «Снапшот завершён» означает, что данные записаны в репозиторий. Это ничего не говорит о том, можно ли прочитать этот репозиторий на другой машине, человеком, который не помнит, что он настраивал одиннадцать месяцев назад.

Начните с дешёвых проверок целостности — restic check --read-data-subset=5% или borg check --verify-data по расписанию — и помните, что они проверяют архив, а не вашу способность им воспользоваться. Настоящая тренировка устроена иначе и занимает один день, один раз. Закажите свежий сервер с почасовой оплатой в локации, которую вы обычно не используете. Разверните бэкап, имея только адрес репозитория, парольную фразу и собственные заметки. Поднимите сервис. Засеките время всего процесса. Затем уничтожьте машину. Итоговая стоимость — несколько долларов, и это единственное упражнение, дающее цифру, которой можно доверять.

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

Запишите два числа, которые даёт тренировка: сколько заняло восстановление и сколько работы может потерять ваше расписание. Это и есть политика бэкапов. Всё, что было сказано выше, — детали реализации на службе у этих двух чисел.

Автоматизация, чтобы это продолжало происходить

Запускайте задачу через таймер systemd, а не через cron. Так вы получаете логи в одном месте, реальную запись о последнем запуске и расписание, переживающее перезагрузки — ничего из этого cron без лишней работы не даёт. Держите парольную фразу вне самого юнит-файла, который любой с доступом к шеллу может прочитать прямо через systemctl cat.

Затем разберитесь с той причиной сбоя, которая реально подводит людей, — это не ошибка, а тишина. Бэкап, переставший работать шесть недель назад, выглядит точь-в-точь как отработавший идеально, потому что оба не выдают вывода. Оповещайте об отсутствии, а не об ошибке. Пусть задача при успехе пингует монитор, а монитор жалуется, когда пинг не приходит — и держите этот монитор где угодно, кроме сервера, за которым он следит, ведь упавшая машина не может сообщить, что она упала.

Настраивайте глубину хранения осознанно, а не по умолчанию. Что-то вроде --keep-daily 7 --keep-weekly 4 --keep-monthly 6 покрывает и ошибки, которые вы заметите сегодня ночью, и порчу данных, которую вы заметите весной, не разрастаясь бесконечно. Запускайте удаление старых копий на стороне цели, если вы перешли на append-only, — в этом весь смысл перехода на append-only. Объём передачи редко становится ограничением в нашей сети — трафик безлимитен на любом тарифе, — поэтому планируйте расписание ради стабильности, а не ради квоты, и сверяйте время с собственными тихими часами. Более широкие привычки вокруг всего этого разобраны в гайде по опсеку сервера.

Краткая версия

Если вы не сделаете с этой страницей больше ничего, сделайте эти шесть вещей, примерно в таком порядке:

• Разместите одну копию у второго провайдера, во второй юрисдикции, оплаченную так же приватно, как и первая.
• Сделайте эту копию append-only или забирайте её с цели через pull, чтобы скомпрометированный сервер не мог её уничтожить.
• Пусть инструмент шифрует на источнике, и держите ключ вне обеих задействованных машин.
• Делайте дампы баз данных и останавливайте или снимайте снапшот с того, что запущено; никогда не копируйте живое состояние напрямую.
• Бэкапьте ключи идентичности отдельно — onion, WireGuard, DKIM, seed ноды, — потому что их нельзя сгенерировать заново.
• Один раз разверните бэкап на одноразовом сервере, засеките время и запишите, чего не хватило.

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