Шифрованные офсайт-бэкапы для self-hosted AI-сервера: restic + rclone + Google Drive

Если вы запускаете self-hosted AI-сервер — Hermes Agent, Codex, Claude Code, Ollama или что-то подобное — рано или поздно вы упираетесь в вопрос: а что будет, если NVMe умрёт? Локальные бэкапы — это база. Но если сервер физически выходит из строя, локальный бэкап уходит вместе с ним.

В этой статье — реальный production-опыт настройки шифрованных офсайт-бэкапов для self-hosted AI-инфраструктуры. Используем restic (шифрование на лету), rclone (транспорт), Google Drive (бесплатное хранилище 15 ГБ). Никаких VPN, никаких S3-аккаунтов, никаких ежемесячных платежей.

Почему restic, а не rsync или Borg

У нас было три требования:

Шифрование на стороне клиента. Данные уходят «наружу» уже зашифрованными. Google Drive видит бинарную кашу.
Дедупликация. AI-инфраструктура порождает много конфигов, логов, Docker-образов — они меняются инкрементально. Restic хранит только изменения.
Простота restore. Не надо вспоминать сложный синтаксис. restic restore latest /target — одна команда.

Мы рассматривали Borg (сложный restore), rsync (нет шифрования и дедупликации) и Duplicati (ненадёжный). Restic выиграл по сочетанию простоты и надёжности.

Схема получилась такая:

Hermes VM → restic → rclone → Google Drive

Всё работает через systemd-таймеры. Никаких cron-костылей.

Архитектура: два уровня бэкапов

Мы разделили бэкапы на два независимых уровня.

Локальный бэкап (первая линия обороны)

Пишется на тот же физический сервер, но в отдельную директорию /srv/hermes/backups/restic-repo. Работает ежедневно через hermes-data-backup.timer. Отсюда восстанавливаем случайно удалённый файл или откатываем неудачное обновление конфига.

Офсайт-бэкап (последняя линия обороны)

Уходит на Google Drive через rclone. Работает через hermes-offsite-backup.service + hermes-offsite-backup.timer. Именно эта схема спасает, если сервер физически умирает, или кто-то заливает шифровальщик.

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

Настройка rclone для Google Drive

Самый нетривиальный шаг — OAuth-авторизация rclone для Google Drive. Сервер в контейнере — браузерного OAuth-потока там нет. Решение: авторизация с отдельного ПК.

Процесс выглядит так:

На Windows-машине запускается PowerShell-скрипт Authorize-GDriveOffsite.ps1.
Он скачивает portable-версию rclone, если её нет.
Открывает Google OAuth в браузере.
Вы получаете токен — скрипт автоматически загружает его на сервер.
Скрипт устанавливает /root/.config/restic/hermes-offsite.env с готовой конфигурацией.

Всё, что нужно на сервере — установить токен из временной директории:

sudo hermes-offsite-gdrive-setup-token /tmp/bronevik-gdrive-token.json

Важный момент про scope: используем drive.file. Это значит, что rclone видит и меняет только те файлы, которые сам создал. Даже если кто-то получит доступ к токену — весь ваш Google Drive не раскрывается.

После настройки запускаем первый бэкап и включаем таймер:

sudo hermes-offsite-enable

Статус можно проверять одной командой:

sudo hermes-offsite-backup-status

Ожидаемый healthy-state:

configured=yes
repository=rclone:bronevik-gdrive:BronevikBackups/hermes-restic
rclone_remote_configured=yes
hermes-offsite-backup.timer enabled active
latest offsite snapshot=43928ce5

Rate Limit от Google Drive (и как мы это починили)

Первый же запуск упал с ошибкой: rateLimitExceeded.

Google Drive не рассчитан на то, что в него пишут десятки гигабайт за раз. Restic делает snapshot — это много мелких запросов. Google их отклоняет.

Решение — тюнинг rclone-параметров:

--tpslimit 8
--tpslimit-burst 8
--drive-pacer-min-sleep 100ms
rclone.connections=2

tpslimit ограничивает количество запросов в секунду до 8.
drive-pacer-min-sleep увеличивает минимальную паузу между запросами.
connections=2 ограничивает параллельные соединения.

После этих настроек бэкап прошёл штатно. Rate limit больше не возвращался.

Совет: если у вас больше 50 ГБ данных, начните с ручного запуска sudo hermes-offsite-backup-now и следите за логами. Первый бэкап будет полным — он самый тяжёлый. Дальше restic передаёт только дельту.

Restore Drill: проверка, что бэкап работает

Самая частая ошибка: настроить бэкап, убедиться, что он «зелёный», и забыть. А когда реально нужно восстановить данные — выясняется, что пароль от репозитория потерян, или rclone remote отвалился, или версия restic несовместима.

Мы провели restore drill 11 июня 2026 года.

Сценарий:

Взять последний snapshot из локального restic-репозитория.
Восстановить файлы в /tmp/scratch-restore/.
Сверить контрольные суммы с живыми файлами.
Повторить то же самое для офсайт-репозитория на Google Drive.

Результат: все файлы совпали. Восстановление из Google Drive заняло чуть дольше из-за сетевой задержки, но данные были идентичны.

Вывод: бэкап работает. Но drill выявил одну открытую проблему — restic-пароль хранится только на VM. Если VM умирает, а пароль не записан в менеджере паролей — офсайт-репозиторий становится бесполезным. Задача на escrow (вынос пароля в password manager) была зафиксирована как открытое действие.

Проверьте свой setup: если пароль от restic-репозитория существует только на той же машине, что и бэкап — у вас нет настоящего офсайт-бэкапа.

Автоматизация: systemd-таймеры

Вместо cron мы используем systemd-таймеры. Почему:

systemd логирует запуски в journald — всегда видно, когда бэкап стартовал и завершился.
Таймеры не теряют срабатывания, если система была выключена (в отличие от anacron — less is more).
Зависимости между сервисами управляются штатными средствами systemd.

Структура:

hermes-data-backup.timer        → ежедневно
hermes-offsite-backup.timer     → ежедневно, с задержкой после локального

Проверка статуса:

sudo hermes-backup-status        # локальный
sudo hermes-offsite-backup-status  # офсайт

Дополнительный уровень — VM image backups. Раз в неделю (воскресенье, 03:30) Proxmox VE делает vzdump на CIFS-шару отдельного ПК. Это снапшот всей VM — если что-то пошло не так на уровне системы, можно откатиться целиком.

Что мы узнали на практике

Семь выводов, которые стоят дорого:

Шифрование — не опция, а обязательное условие. Google Drive — это чужое хранилище. Restic шифрует AES-256 на стороне клиента. Google видит только бинарный blob.
Rate limit — первое, с чем вы столкнётесь. Не ждите, что Google Drive «проглотит» 15 ГБ за минуту. Настраивайте тюнинг rclone заранее.
Пароль от restic должен быть вне сервера. Если сервер сгорел, а пароль лежал в /root — офсайт-бэкап бесполезен. Вынесите в Bitwarden, 1Password или на бумажку в сейф.
Проверяйте restore, а не backup. Backup зелёный — не значит, что restore работает. Сделайте drill раз в квартал.
Два уровня — не роскошь. Локальный + офсайт закрывают разные сценарии отказов. Не экономьте.
PowerShell-скрипт для OAuth — спасение. rclone без браузера на headless-сервере — это боль. Скрипт, который авторизуется с рабочей машины и передаёт токен на сервер, решает проблему элегантно.
VM image backup — последний рубеж. Если конфигурация системы развалилась (обновление ядра, сломанный пакет, кривой Docker) — пофайловый restore не поможет. Только полный образ VM.

Полезные команды одной строкой

# Статус офсайт-бэкапа (быстрый)
sudo hermes-offsite-backup-status

# Полная статистика (размеры снапшотов)
sudo hermes-offsite-backup-status --full

# Ручной запуск
sudo hermes-offsite-backup-now

# Проверка локального репозитория
sudo hermes-backup-status

# Посмотреть последние снапшоты
sudo restic snapshots --last 3

Заключение

Self-hosted AI-инфраструктура с Hermes Agent, Codex и Claude Code — это не pet-проект на Raspberry Pi. Это production-система, где потеря данных означает потерю недель настройки: конфиги, навыки, memory, Obsidian-знания, интеграции.

Офсайт-бэкап с restic + rclone + Google Drive обходится в 0 рублей ежемесячно (если данные влезают в 15 ГБ). Настройка занимает вечер. Restore drill — ещё час раз в три месяца. За это вы получаете гарантию, что данные переживут физическую гибель сервера.

Настройте офсайт-бэкап сегодня. Завтра может быть поздно.