Как резервировать VPS на зашифрованное офшорное хранилище

Резервные копии почти никто не настраивает в день, когда разворачивает сервер. Это происходит позже — после того, как диск заполняется во время обновления, после удаления не в той директории, после миграции, оставившей базу данных, которая запускается чисто и отвечает неправильно, после того, как кто-то посторонний получает доступ. Промежуток между работающей машиной, которая имеет значение, и копией, которая переживёт её потерю, — самое опасное окно в self-hosting, и большинство людей живёт в нём месяцами, не замечая этого, потому что долгое время ничего не идёт не так, а потом всё идёт не так сразу. Закрыть это окно не сложно и не дорого. Сложным это кажется потому, что словом «резервная копия» называют четыре разные вещи, и только одна из них останется на месте в тот самый плохой день.

Четыре вещи, которые не являются резервной копией

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

• RAID — это аптайм, а не резервная копия. Массив переживает отказ диска, не уходя в офлайн, — именно поэтому наши серверы хранения работают на RAID-6 и выдерживают два одновременных отказа. Он не переживает удалённую директорию, неудачное обновление, зашифрованное кем-то посторонним дерево файлов или уничтоженную таблицу в базе данных — каждое из этих изменений добросовестно записывается на все диски в один и тот же момент.
• Снэпшоты — это отмена действия, а не резервная копия. Они хранятся на том же томе, что и сами данные, обычно видны root на той же машине, и всё, что уничтожает том или сам хост, забирает снэпшоты вместе с собой. Откатиться по ним быстро — но бесполезно, когда сервера больше нет.
• Синхронизация — это репликация, а не резервная копия. Инструмент синхронизации существует, чтобы дальняя сторона совпадала с ближней, поэтому удаление или повреждение файла долетает до копии настолько быстро, насколько позволяет сеть. Именно так по конструкции ведут себя синхронизация Nextcloud, Dropbox и rclone.
• История версий и корзина — это удобство, а не резервная копия. Это функции самого приложения, хранящиеся в его же базе данных, со сроком хранения, который измеряется днями. Когда ломается само приложение, его собственная история ломается вместе с ним.
• Копия на том же сервере — не копия за пределами площадки. Если случается отказ самой машины, потеря аккаунта у провайдера, сбой гипервизора или изъятие оборудования, все файлы на этой машине попадают в одну и ту же зону отказа — независимо от того, в какой они директории.

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

Правило 3-2-1 и его версия, актуальная в 2026 году

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

• Три копии. Рабочие данные плюс ещё две копии. Две копии — это на один отказ ближе к единой точке отказа, а единые точки отказа обожают ломаться именно тогда, когда вы всё ещё собираетесь починить первую проблему.
• Два вида носителей. Разное железо, разное программное обеспечение, в идеале — разный провайдер. Два тома на одном хосте делят общий гипервизор, общую панель управления и общий аккаунт — а значит, делят и все способы, которыми можно потерять этот аккаунт.
• Одна копия — за пределами площадки. Физически в другом месте, на инфраструктуре, которая не ляжет вместе с вашей. Именно эта копия имеет значение при пожаре, краже, изъятии оборудования и внезапной блокировке аккаунта без предупреждения.
• Одна копия — неизменяемая или офлайновая. Шифровальщик-вымогатель и скомпрометированный root в первую очередь ищут именно резервные копии, а если сервер может писать в хранилище, он может его и стереть. Учётные данные с доступом только на дозапись или архитектура на основе pull превращают это из катастрофы в досадную неприятность.
• Ноль непроверенных восстановлений. Резервная копия, которую вы ни разу не восстанавливали, — это всего лишь гипотеза. Именно этот пункт пропускают чаще всего и жалеют об этом сильнее всего, потому что задача резервного копирования, два года подряд рапортующая об успехе, вполне может два года подряд писать нечитаемые архивы.

Что резервировать: состояние системы, а не всю машину

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

• Базы данных — через дамп, а не копированием файлов. Файл работающей базы данных, скопированный в момент, когда движок в него пишет, — это «разорванный» файл, который может восстановиться, может восстановиться неправильно, и никак не подскажет, какой из этих двух случаев произошёл. Пользуйтесь штатной утилитой дампа своего движка, либо останавливайте сервис, либо снимайте снэпшот файловой системы и делайте дамп уже с него.
• Директории с данными приложения. Загруженные файлы, медиа, сгенерированные ресурсы — дерево файлов, на которое ссылается база данных. Его нужно захватывать в ту же самую точку во времени, что и базу, — иначе при восстановлении вы получите индекс, описывающий файлы, которых на самом деле нет.
• Конфигурация и всё, что вы правили руками. Настройки веб-сервера и reverse-proxy, юниты systemd, записи cron, правила файрвола — те двадцать мелких исправлений, которые вы внесли в два часа ночи и потом ни за что не вспомните.
• Секреты и ключи — отдельно и с повышенной осторожностью. TLS-сертификаты и их приватные ключи, хостовые ключи SSH, API-токены и, прежде всего, файлы кошельков и seed-фразы. Для них нужна собственная зашифрованная копия, которая хранится не только на арендованной машине.
• Описания контейнеров и тома. Compose-файлы и файлы окружения, плюс именованные тома — именно про них чаще всего забывают, потому что сами контейнеры пересоздаются элементарно, а вот их тома — нет.
• Список того, что установлено, — а не сама установка. Короткая опись пакетов, версий и того, что где запущено, восстанавливается быстрее и занимает меньше места, чем образ всей корневой файловой системы.

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

Расчёт размера хранилища и его реальная стоимость

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

• Закладывайте примерно объём вашего текущего состояния плюс тридцать-пятьдесят процентов на историю — это типичная политика хранения для сервера, который меняется с обычной скоростью.
• На рост объёма куда сильнее влияет срок хранения, чем частота снэпшотов. Ежечасные снэпшоты, которые хранятся два дня, обходятся дешевле, чем ежедневные, которые хранятся три года. Решите, насколько глубоко в прошлое вы реально когда-либо захотите вернуться, и настройте автоматическую очистку под этот срок.
• Уже сжатые данные повторно не сжимаются. Видео, фотографии, архивы и зашифрованные блобы занимают в резервной копии почти столько же места, сколько и в оригинале, поэтому серверу с большим количеством медиа нужен реальный объём, а не хитрые настройки.
• Базы данных плохо дедуплицируются между дампами, потому что сжатый дамп чуть изменившейся базы — это совершенно другой поток байт. Делайте дамп без сжатия и отдайте сжатие на откуп инструменту резервного копирования — стоимость хранения резко упадёт.
• Медленная только первая загрузка. После неё ночной запуск переносит лишь дельту, а это на большинстве серверов — считаные мегабайты. Трафик здесь безлимитный, так что первый проход — вопрос терпения, а не бюджета.

На практике это самая дешёвая страховка во всём вашем стеке. Сервер хранения начинается от $7.99/mo за 1 TB на RAID-6 — это намного больше, чем займёт состояние нескольких VPS-инстансов, — а STO-2 за $12.99/mo удваивает объём. Там, где объём действительно важен, — медиатеки и долгий срок хранения: STO-4 за $22.99/mo даёт 4 TB, STO-8 за $39.99/mo даёт 8 TB. Хранилище понимает rsync, SFTP и S3-совместимый API, так что с ним без плагинов работает любой массовый инструмент резервного копирования, а тома зашифрованы AES-256 в состоянии покоя с поддержкой собственных ключей — хотя, как показывает следующий раздел, шифровать стоит ещё до того, как данные покинут исходную машину.

Выбор инструмента: для чего на самом деле нужен каждый

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

• restic — рекомендация по умолчанию для большинства серверов. Шифрование на стороне клиента, дедупликация, один статический бинарник без демона, и он умеет писать напрямую в SFTP, S3-совместимые эндпоинты и обычные директории. Его режим только-дозапись — самый простой способ получить хранилище, которое скомпрометированный сервер не сможет стереть.
• BorgBackup — отличная дедупликация и сжатие, очень эффективен на медленных каналах, зрелый и хорошо проверенный временем инструмент. Для удалённых репозиториев ему нужен собственный агент на стороне хранилища — небольшое ограничение в обмен на заметно меньший расход места.
• rclone — правильный инструмент, когда задача на самом деле сводится к переносу данных между объектными хранилищами или когда нужно зеркало, а не история версий. Если используете его напрямую, добавьте слой шифрования crypt и помните, что обычная синхронизация распространяет и удаления тоже.
• Для баз данных — всегда штатные утилиты дампа. mysqldump, pg_dump и их аналоги дают согласованную логическую копию, которую движок точно сможет прочитать обратно. Делайте дамп в файл, а затем пусть restic или Borg подхватят уже этот файл, — не пытайтесь заменить дамп хитрым копированием на уровне файлов.
• Снэпшоты провайдера — только как быстрый локальный слой. Берите их для быстрого отката вокруг рискованных обновлений, но никогда не считайте одной из трёх обязательных копий.

Шаг за шагом: рабочая зашифрованная резервная копия за один присест

1. 01Разверните хранилище и сразу защитите егоСервер хранения в регионе, отличном от серверов, которые он защищает. SSH только по ключам, отдельный пользователь и никакого повторного использования учётных данных с машин, которые будут в него писать.
2. 02Определите список состояния ещё до выбора инструментаВыпишите каждый путь и каждую базу данных, которые должны пережить сервер. Десять минут с текстовым файлом сейчас избавят вас от восстановления, во время которого выясняется, что одну директорию никто не внёс в список.
3. 03Инициализируйте зашифрованный репозиторийСгенерируйте надёжный пароль репозитория, инициализируйте его через SFTP или S3 и храните этот пароль где угодно, только не на резервируемом сервере. Репозиторий, чей ключ существует только на погибшей машине, восстановить нельзя.
4. 04Сначала дамп баз данных, потом архивированиеОбёрточный скрипт, который сначала делает дамп каждой базы данных во временную директорию, а затем запускает один проход резервного копирования сразу и по дампам, и по дереву файлов. Именно такой порядок делает базу данных и её файлы согласованными друг с другом.
5. 05Запустите первое резервное копирование и дождитесь концаПервый проход — самый долгий. Запускайте его в мультиплексоре терминала, чтобы разрыв соединения его не убил, и засеките, сколько он занял, — заодно узнаете и своё окно восстановления.
6. 06Настройте срок хранения и автоматическую очисткуЧто-то вроде семи ежедневных, четырёх еженедельных и шести ежемесячных снэпшотов подходит большинству серверов. Настройте очистку в той же задаче — иначе репозиторий будет расти, пока однажды не откажет.
7. 07Поставьте по расписанию и сделайте сбой заметнымНочной таймер или запись в cron, плюс оповещение, когда задача не отрапортовала об успехе. Молчаливая задача резервного копирования неотличима от полного её отсутствия — сколько бы месяцев ни потребовалось, чтобы это заметить.
8. 08Сегодня же восстановите что-нибудь из резервной копии на другой машинеНе просмотр содержимого архива — а настоящее восстановление одного реального файла и одной реальной базы данных на черновой сервер. Пока вы не сделали это хотя бы раз, у вас есть скрипт резервного копирования, а не резервная копия.

Как сделать так, чтобы копия пережила то, что убило сервер

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

• Используйте на источнике учётные данные с доступом только на дозапись. И restic, и Borg поддерживают режим, в котором пишущая машина может создавать новые снэпшоты, но не может удалять или очищать существующие. Очистка в этом случае запускается откуда-то ещё, по расписанию, с отдельным ключом.
• Где возможно, отдавайте предпочтение архитектуре pull. Если хранилище само забирает данные из источника, а не источник отправляет их, у источника вообще никогда не появляется учётных данных для доступа к архиву.
• Никогда не используйте одни и те же SSH-ключи или пароли репозитория на разных серверах. Компрометация одной машины должна стоить вам резервных копий одной машины, а не всего парка целиком.
• Держите как минимум одну копию в другой юрисдикции и другой зоне отказа. Разнесение по регионам — это не паранойя, а разница между аппаратным инцидентом и полной потерей данных.
• Храните ключ репозитория полностью вне инфраструктуры. Менеджер паролей, аппаратный токен, бумага в сейфе — где угодно, кроме машин, которые этот репозиторий защищает.
• Обращайте внимание на резервное копирование, которое вдруг начинает завершаться подозрительно быстро. Задача, которая раньше занимала двадцать минут, а теперь занимает сорок секунд, обычно резервирует пустую или размонтированную директорию — и при этом продолжает исправно рапортовать об успехе.

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

Восстановление: то, что никто не репетирует

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

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

Тренировка дважды в год решает всё это разом. Разверните одноразовый VPS, восстановитесь на него из настоящего репозитория, запустите сервис, посмотрите на данные, уничтожьте машину. Это стоит пару долларов и час времени, а систему резервного копирования из предмета веры превращает в установленный факт. Проделайте это один раз с открытым runbook-ом и исправьте в нём всё, в чём он вам соврал.

Слой приватности: резервная копия может свести на нет вашу анонимность

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

• Имена файлов и структура директорий — это метаданные, даже когда содержимое зашифровано. Шифрование на стороне клиента в restic и Borg скрывает и имена тоже; обычное зеркало rsync — нет, а одного листинга директории часто достаточно, чтобы понять, что это за сервер и кто им управляет.
• Аккаунт хранилища — часть той же истории. Хранилище резервных копий, арендованное по карте на ваше настоящее имя, привязывает это имя ко всему, что в нём лежит, — независимо от того, насколько аккуратно была сохранена анонимность исходной машины.
• Трафик резервного копирования — это постоянная, регулярная по расписанию, объёмная связь между двумя адресами. Это один из самых читаемых паттернов, которые вообще производит сервер, и он каждую ночь указывает прямо на хранилище.
• Старые снэпшоты переживают решения, которые их породили. То, что вы перестали хранить год назад, всё ещё лежит в архиве, если срок хранения его так и не вычистил, — отличное свойство для восстановления и скверное для приватности.
• Логи и история команд оболочки попадают в архив вместе со всем остальным. В нём часто оказываются те самые IP-адреса, команды и учётные данные, с которыми вы были так осторожны на рабочей машине.

Исправления здесь самые обычные. Пользуйтесь инструментом, который шифрует не только содержимое, но и имена. Арендуйте хранилище так же, как арендовали источник, — у хостинга, который никогда не спрашивал, кто вы, оплачивая его с криптобаланса, а если хотите закрыть и платёжный след, добавьте пополнение через Monero. Если беспокоит сам паттерн трафика, пускайте перенос через туннель WireGuard. И примените к серверу хранения ту же защиту первых десяти минут, что и к продакшену, — потому что машина, хранящая копию всего, не менее ценная цель, чем оригинал, а зачастую и более ценная.

Ошибки, которые стоят людям их данных

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

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