Зашифрованные бэкапы VPS на удалённой площадке

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

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

• Машина умирает. Железо, гипервизор, файловая система, которая после сбоя поднимается только для чтения. Редко, буднично, и с этим случаем справляется любой бэкап.
• Вы ломаете всё сами. Миграция, прошедшая наполовину, rm с чересчур смелой маской, изменение конфигурации, которое было в порядке до перезагрузки. С огромным отрывом самая частая причина, по которой кто-либо вообще что-либо восстанавливает.
• Кто-то другой получает root. Случай, который определяет всю вашу архитектуру. Атакующий, которому нужен рычаг давления, сначала удаляет бэкапы и только потом шифрует сервер; если на вашем сервере лежат учётные данные, способные стереть репозиторий, вы построили систему, которая ему помогает.
• Аккаунт исчезает. Не прошедший платёж, спор, блокировка. Если оригинал и копия находятся за одним и тем же логином, у них одна и та же единая точка отказа, и она не техническая.
• Приходит кто-то с полномочиями. Железо могут изъять, а аккаунт заморозить в установленном порядке, без всякой атаки. Помогает только копия в другой юрисдикции, и то лишь если вы по-прежнему можете до неё добраться.

Обратите внимание, от скольких из этих случаев никак не спасает снапшот, сделанный вашим же провайдером, на вашем же аккаунте, в том же дата-центре.

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

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

Современное расширение правила — 3-2-1-1-0, и в 2026 году важны именно две добавленные цифры. Дополнительная 1 — это неизменяемая или офлайн-копия — то, что атакующий с вашими учётными данными не сможет удалить, а это ровно то, что даёт режим append-only. 0 — это ноль ошибок при проверке: бэкап, который вы проверили, а не просто сделали.

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

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

Настоящие различия касаются другого конца.

• restic — это один статически собранный бинарник на Go, и от места назначения он ничего не требует. Он пишет по SFTP, в S3-совместимое объектное хранилище, на собственный REST-сервер или куда угодно, куда дотягивается rclone. Шифрование — AES-256 с аутентификатором Poly1305; во втором формате репозитория появилось сжатие. Если ваша цель — бакет или машина, на которую нельзя ставить софт, ответ — restic, и спорить тут особо не о чем.
• Borg требует, чтобы borg был установлен на обоих концах, и общается сам с собой по SSH. Взамен он даёт то, для чего restic нужен помощник: настоящий, принудительно применяемый на сервере режим append-only, закреплённый опцией command= в authorized_keys удалённой учётной записи. Клиент — в том числе скомпрометированный — может добавлять архивы, но не может их удалять. Для модели угроз из предыдущего раздела это самая ценная функция обоих проектов.

Так что решение короткое. Если вы контролируете другой конец, используйте Borg в режиме append-only. Если нет — restic, а то же свойство верните себе, либо запустив на целевой машине rest-server --append-only, либо используя бакет с object lock. Ниже показаны оба пути.

Одна оговорка, прежде чем вы определитесь с репозиторием: набор команд Borg не стабилен между основными ветками — сокращение repo::archive, которое используется ниже, относится к серии 1.x и в 2.x меняется — так что сверяйте borg --version с той документацией, которую читаете, а не наоборот. restic здесь стабильнее, хотя и ему пришлось пройти через собственную миграцию формата репозитория.

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

Всё, что выше, — стандартные советы. А вот эту часть обычно опускают.

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

• Append-only на стороне хранилища. Другой конец принимает новые данные и отказывается что-либо удалять, что бы ни просил клиент. Именно так работают borg serve --append-only и rest-server --append-only, с принудительным применением на сервере, а удаление становится операцией, которую вы осознанно выполняете с бэкап-сервера.
• Object lock. S3-совместимое хранилище может держать объекты неизменяемыми в течение срока хранения. Эффективно, но доверие при этом переносится на провайдера и на ваши платёжные отношения с ним.
• Pull вместо push. Бэкап-сервер сам подключается к рабочему серверу и читает данные. Ничто на рабочем сервере не может дотянуться до репозитория — но теперь у бэкап-сервера есть ключ к продакшену, так что вы перевернули доверие, а не избавились от него. Разумно, когда бэкап-сервер действительно защищён лучше; в остальных случаях преимущество не очевидно.

Вариант с append-only — самый дешёвый и с наименьшим числом оговорок, поэтому ниже строится именно он.

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

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

Подобрать ему размер проще, чем настоящему серверу, потому что сервер для бэкапов — это диск с приделанным к нему процессором. Что ему действительно нужно — это достаточно памяти, чтобы выполнить очистку (prune) и проверку целостности без свопинга, ведь это единственная по-настоящему прожорливая операция — так что одного гигабайта впритык, а с двумя комфортно. Из линейки тарифов:

• Cub — 1 vCPU / 2 GB / 40 GB NVMe, $5.00/мес. Вариант по умолчанию. Обычный веб-сервер или сервер приложений с 10–15 GB рабочих данных и годом ежедневной истории помещается сюда с запасом, потому что основную работу делают дедупликация и сжатие.
• Scout — 2 vCPU / 4 GB / 70 GB, $9.00/мес. Несколько серверов в одном репозитории или Nextcloud с фотографиями.
• Runner и Hunter — 100 GB за $14.00 и 140 GB за $19.00. Сюда в итоге попадают почтовое хранилище, медиатека или история за несколько лет.
• Pup — 1 vCPU / 1 GB / 25 GB, $3.50/мес. Годится только для конфигурации и дампов баз данных. Не направляйте на него большое дерево файлов в расчёте на то, что обслуживание останется приятным.

Рабочее правило для диска: закладывайте в два-три раза больше размера одного полного бэкапа, и у вас будет год истории с запасом на ошибку. Разместите сервер там, где нет оригинала — Амстердам, Париж, Бухарест и София идут по базовой цене, Рейкьявик — с коэффициентом 1.20, а Цюрих — 1.35, так что Cub в Швейцарии обойдётся в $6.75 в месяц. Первая загрузка — единственная крупная передача, которую вы когда-либо сделаете, а трафик безлимитный на скорости 1 Gbps, так что начальное заполнение репозитория не обернётся счётом в конце месяца.

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

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

restic forget --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --keep-yearly 2 --prune

borg prune --keep-daily=7 --keep-weekly=5 --keep-monthly=12 --keep-yearly=2 ::
borg compact

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

И здесь есть настоящее противоречие с предыдущим разделом: очистке нужно удаление, а вы только что отняли удаление у клиента. Это правильный компромисс, а не изъян конструкции. Разрешается он так: очистку выполняют с бэкап-сервера, где репозиторий локальный, а у клиента нет права голоса — еженедельным таймером на целевой машине, вообще без участия рабочего сервера. Если это больше механики, чем вам хочется, альтернатива — второй SSH-ключ без --append-only, который хранится не на рабочем сервере и используется вручную раз в несколько месяцев. Чего делать не стоит — так это возвращать неограниченный ключ на сервер ради того, чтобы упростить cron-задачу.

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

• Оповещение о сбое. Юнит systemd может при сбое запустить другой юнит с помощью OnFailure=, а тот может отправить вам сообщение. Необходимо, но это самое слабое из трёх, потому что срабатывает, только когда что-то действительно запустилось и сообщило об ошибке.
• Оповещение о возрасте. Спрашивайте у репозитория, когда он в последний раз что-либо получал, и поднимайте тревогу, если ответ старше суток-двух. Так ловятся замаскированный таймер, заполнившийся диск, переставшее резолвиться имя хоста — все сбои, которые не породили ни одной ошибки, потому что ничего так и не запускалось.
• Dead man’s switch («кнопка мертвеца»). Переверните логику: задача при успехе пингует URL, а внешний сервис поднимает тревогу, когда пинги прекращаются. Только этот вариант переживает исчезновение всего сервера целиком, а это тот сбой, о котором меньше всего хочется узнать от клиента.

Проверка, которая окупается сама, — проверка возраста, и это три строки:

#!/bin/sh
# alert if the newest snapshot is older than 36 hours
last=$(restic snapshots --json --latest 1 | grep -o '"time":"[^"]*"' | head -1 | cut -d'"' -f4)
[ $(( $(date +%s) - $(date -d "$last" +%s) )) -lt 129600 ] || echo "BACKUP STALE: $last"

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

Примерно в порядке того, как часто они превращают бэкап в сувенир:

• База данных копировалась на ходу. Каталог данных InnoDB, захваченный посреди записи, восстанавливается в базу, которая не запускается, и происходит это тихо — бэкап завершается, все файлы на месте, размер выглядит правильным. Сначала дамп. Недаром это третий шаг.
• Пароль был только на сервере. Безупречный зашифрованный репозиторий, чья парольная фраза жила в /root на сгоревшей машине, — это высококачественный шум. Как и парольная фраза в менеджере паролей, единственная копия которого синхронизируется через тот же самый сервер.
• Никто ни разу не восстанавливался. Список исключений оказался слишком агрессивным, дамп базы три месяца был пустым, путь был неверным. Всё это невидимо до восстановления и очевидно уже через десять минут после его начала.
• Бэкапы были на том же аккаунте. Тот же провайдер, тот же логин, те же платёжные отношения. Спасает при отказе диска и больше ни в чём.
• Клиент мог удалять. Шифровальщик удаляет бэкапы до того, как тронет данные, потому что в этом вся его бизнес-модель. Append-only — или смиритесь с тем, что этот сценарий не покрыт.
• Целевой сервер тихо заполнился. Политика хранения так ничего и не чистила, или в список включений добавили новый большой каталог. Каждая следующая задача падает, и если вы не следили за возрастом бэкапов, никто вам об этом не скажет.
• В бэкап попал блокчейн. Бэкапить каталог данных Bitcoin или Monero — значит платить за хранение публичного реестра, который можно бесплатно скачать заново. Бэкапьте кошелёк и конфигурацию, а цепочку исключайте.
• Список исключений что-то съел. Шаблон, рассчитанный на /var/cache, заодно совпал с каталогом кеша приложения, где лежало состояние, которое приложение так и не восстановило. Один раз внимательно прочитайте список файлов вашего первого бэкапа.
• Для восстановления нужен был ключ, лежавший в репозитории. Режим repokey в Borg хранит ключ внутри репозитория, что удобно ровно до тех пор, пока вы не потеряете сам репозиторий. Один раз, в самом начале, сделайте borg key export куда-нибудь в другое место.

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

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

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

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

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