Резервное копирование VPS.
Вне сервера, с дедупликацией — и вне досягаемости.

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

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

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

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

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

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

Последняя строка — это то, вокруг чего строится остальная часть руководства. Она не дороже строки выше: настройка append-only бесплатна, а вторая юрисдикция стоит те же $3.90, что и первая.

Правило 3-2-1, переформулированное для одного VPS. Три копии данных, на двух разных типах хранилищ, одна из которых — вне площадки. Классическая формулировка родом из эпохи ленточных накопителей и офисных серверов, и дух правила переживает перенос лучше, чем буква. Для одной самостоятельно размещённой машины это звучит так: рабочие данные на VPS, репозиторий на второй машине где-то ещё и — для всего по-настоящему незаменимого — третья копия, которую можно подержать в руках: на диске дома или в ящике стола. По-настоящему важно не число «три». Важно, сколько независимых вещей должно пойти не так, прежде чем данные пропадут. Минимум, который стоит иметь, — два.

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

Для типичного самостоятельно размещённого VPS этот список короткий и всегда содержит эти пять пунктов:

• 01Содержимое базы данных. Не каталог данных — дамп. Почему, объясняется в шаге 05.
• 02Файлы, загруженные пользователями. Тома Docker, каталог загрузок или медиафайлов, почтовое хранилище. Обычно именно здесь основная масса байтов.
• 03Конфигурация и секреты. Файлы Compose, файлы .env, ключи шифрования, API-токены. Немного места, но именно они определяют разницу между двухчасовым восстановлением и двухдневным.
• 04Состояние системы, которое вы изменили. /etc целиком достаточно мал, чтобы забрать его весь без разбора: конфигурация sshd, правила файрвола, юниты systemd, записи cron, настройка почтовой маршрутизации, на которую вы потратили целый вечер.
• 05Всё, что привязано к личности. Ключ скрытого сервиса Tor, ключ подписи Matrix, приватный ключ WireGuard, кошелёк ноды. Потеряйте любой из них — и сервис не восстановится: вместо него появится другой сервис с тем же именем.

Превратите список в два файла на исходном сервере. Include-список делает намерение видимым; exclude-список отсеивает шум. Оба читаются командой бэкапа, и оба сами должны входить в резервную копию.

/etc/backup/include.txt

/etc
/opt
/root
/var/backups
/var/lib/docker/volumes
/home

/etc/backup/exclude.txt

# Caches and rebuildable artefacts
**/node_modules
**/.cache
**/*.tmp
/var/lib/docker/volumes/*/_data/cache
# Log noise — keep the config, drop the volume
/var/log/journal
# Never back up the mount point you restore into
/mnt/restore

Два замечания по этой строке про Docker, потому что на ней часто ошибаются. Именованные тома (named volumes) лежат в /var/lib/docker/volumes — это как раз то, что нужно; bind mount'ы лежат там, куда вы их поместили, обычно рядом с файлом Compose, и охватываются /opt. Образы контейнеров — не данные: они возвращаются через pull, и бэкап, который их тащит, тащит лишние ненужные гигабайты.

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

du -sh --exclude=/var/lib/docker/overlay2 /etc /opt /root /home /var/lib/docker/volumes

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

В панели: Order → VPS → Sentinel, образ Debian 12 и — в этом вся суть — другой бастион, отличный от того, где работает источник. Helsinki — рабочая машина, Reykjavík — хранилище. Для открытия аккаунта не требуется email, а счёт оплачивается в Monero, Bitcoin, Lightning или любом другом поддерживаемом активе, а значит вторая машина не возвращает ту личность, которую первая так тщательно скрывала.

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

На приёмнике — непривилегированный пользователь и каталог.

adduser --disabled-password --gecos "" backup
install -d -m 0700 -o backup -g backup /srv/restic/web01

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

На источнике — ключ, который не используется больше ни для чего.

ssh-keygen -t ed25519 -f /root/.ssh/id_backup -N "" -C "backup:web01"
cat /root/.ssh/id_backup.pub

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

Снова на приёмнике — ограничьте возможности этого ключа. Вставьте публичный ключ в /home/backup/.ssh/authorized_keys с префиксом перед ним. Для restic через SFTP:

restrict,from="198.51.100.7" ssh-ed25519 AAAAC3NzaC1lZDI1... backup:web01

Опция restrict одним словом отключает проброс портов, проброс агента, X11 и выделение PTY, оставляя только передачу файлов и ничего больше. Условие from= привязывает ключ к адресу источника, так что копия, украденная с сервера, бесполезна где-либо ещё. Для Borg сделайте ещё один шаг и принудительно задайте команду — именно там живёт его режим append-only:

command="borg serve --append-only --restrict-to-path /srv/borg/web01",restrict ssh-ed25519 AAAAC3NzaC1lZDI1... borg:web01

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

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

Host rkv-repo
    HostName 198.51.100.42
    User backup
    IdentityFile /root/.ssh/id_backup
    IdentitiesOnly yes

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

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

Всё собирается в один скрипт. Поместите его в /usr/local/sbin/nb-backup.sh, сделайте исполняемым и держите его копию внутри самой резервной копии:

#!/bin/sh
set -eu

# ---- 1. Consistent dumps, written where the include list will find them.
install -d -m 0700 /var/backups/db

# PostgreSQL in a container:
docker exec -t app-db pg_dumpall -U postgres | gzip -9 > /var/backups/db/postgres.sql.gz

# MariaDB / MySQL, InnoDB tables:
# docker exec -t mail-db mariadb-dump --single-transaction --all-databases \
#   | gzip -9 > /var/backups/db/mariadb.sql.gz

# SQLite — never a plain file copy:
# sqlite3 /opt/app/data/app.db ".backup '/var/backups/db/app.db'"

# ---- 2. The snapshot.
restic backup \
  --files-from /etc/backup/include.txt \
  --exclude-file /etc/backup/exclude.txt \
  --tag nightly --one-file-system

# ---- 3. Retention, then reclaim the space it freed.
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

# ---- 4. Structural check every night; read 5% of the data on Sundays.
restic check
[ "$(date +%u)" = "7" ] && restic check --read-data-subset=5%

echo "backup ok: $(date -u +%FT%TZ)"

Три детали в этом скрипте делают больше, чем кажется на первый взгляд. set -eu в начале означает, что неудавшийся дамп прерывает запуск, а не тихо снапшотит вчерашний дамп на следующие полгода. forget и prune объединены в одну команду, потому что политика хранения, которая никогда не освобождает место, — это диск, который переполняется. А воскресная проверка читает часть реальных данных, а не только индекс — повреждение репозитория редко и происходит тихо, и обнаружить его может только чтение.

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

/etc/systemd/system/nb-backup.service

[Unit]
Description=Nightly encrypted offsite backup
Wants=network-online.target
After=network-online.target docker.service

[Service]
Type=oneshot
EnvironmentFile=/etc/backup/restic.env
ExecStart=/usr/local/sbin/nb-backup.sh
Nice=10
IOSchedulingClass=idle

/etc/systemd/system/nb-backup.timer

[Unit]
Description=Nightly encrypted offsite backup

[Timer]
OnCalendar=*-*-* 03:00:00
RandomizedDelaySec=45m
Persistent=true

[Install]
WantedBy=timers.target

systemctl daemon-reload
systemctl enable --now nb-backup.timer
systemctl list-timers nb-backup.timer
systemctl start nb-backup.service && journalctl -u nb-backup.service -n 40 --no-pager

Случайная задержка — не украшение. Каждый самостоятельно размещённый сервер в интернете запускает обслуживание ровно в 03:00, и бэкап, стартующий в ту же секунду, что ротация логов, обновление сертификата и обновление контейнеров, всю ночь борется с ними за I/O. Размазывание старта на сорок пять минут ничего не стоит и убирает целый класс необъяснимо медленных ночей.

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

restic snapshots --latest 3        # is the newest one from last night?
systemctl list-timers nb-backup.timer   # is the timer still armed?

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

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

Первый способ — принудительный append-only через SSH. Это родная территория Borg и самый чистый вариант из доступных на машине, которой вы владеете. Запись в authorized_keys из шага 03 принудительно запускает borg serve --append-only, так что удалённая сторона отказывает в удалении, что бы ни просила ближняя. Prune всё равно должен выполняться, но выполняется он со стороны назначения, по расписанию, на которое источник не может повлиять, от имени аккаунта, до которого источник не может дотянуться. Атакующий с root на источнике может забить репозиторий мусором; он не может удалить архив за ночь до своего появления.

Второй способ — append-only REST-эндпоинт. У сопутствующей restic программы rest-server есть режим --append-only с тем же свойством: новые blob'ы принимаются, существующие удалить нельзя. Запустите его на приёмнике за TLS, укажите в RESTIC_REPOSITORY адрес https:// вместо sftp:, и форма защиты окажется идентичной. Это стоит одного дополнительного сервиса на приёмнике и даёт ту же гарантию.

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

Если ничего из этого не подходит — обычный SFTP, ключ, который может писать и, следовательно, удалять, — не делайте вид, что это не так: добавьте вторую, независимую копию, до которой источник вообще не может дотянуться. Pull вместо push: пусть приёмник сам входит на источник, читает то, что ему нужно, и сохраняет это у себя. Тогда учётные данные хранятся на машине, которая не выставлена наружу, и атакующий на источнике не найдёт ничего, что указывало бы на резервную копию. Настроить это чуть сложнее, зато риск разворачивается ровно в нужную сторону.

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

borg delete ::name-of-an-old-archive
# → Remote: Repository is in append-only mode. Refusing to delete.

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

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

Одна юрисдикция — одна юридическая рамка. Четыре северных бастиона не взаимозаменяемы — Швеция, Финляндия, Норвегия и Исландия защищают немного разные вещи, а Норвегия и Исландия вообще находятся вне Европейского союза. Разнести рабочую машину и её репозиторий между двумя из них означает, что копия не просто «где-то ещё» — она находится под вторым, независимым набором правил. Справочник по северным юрисдикциям разбирает законодательство по пунктам.

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

Задержка здесь роли не играет. От Helsinki до Reykjavík — 30 ms по магистрали, от Helsinki до Stockholm — 8 ms, от Stockholm до Oslo — 11 ms. Ежесуточной резервной копии нет дела ни до одной из этих цифр, как и восстановлению, скорость которого ограничена пропускной способностью диска. Выбирайте пару по юридическому расстоянию, а не по сетевому — сетевое расстояние внутри Nordics является статистической погрешностью.

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