Бэкап restic и borg в S3: настройка, шифрование, тесты

Что значит «без коммерческих агентов» и зачем это нужно

«Без коммерческих агентов» обычно означает, что вы не ставите на каждый сервер или рабочую станцию проприетарный агент от вендора бэкапа и не завязываетесь на его лицензии, закрытый формат и отдельную консоль. Вместо этого используются простые инструменты вроде restic или borg, а данные отправляются в S3-совместимое хранилище.

На практике такой подход часто проще и надежнее. Меньше движущихся частей: один бинарник, понятные команды, шифрование на стороне клиента, обычные логи. Если завтра нужно восстановиться на другом железе, вам не нужен «тот самый» агент и сервер управления. Достаточно ключей и доступа к репозиторию.

Минусы тоже есть. Без единого GUI сложнее видеть картину по всем узлам и быстро понимать, кто давно не бэкапился. Обычно это компенсируют дисциплиной и простыми заменами: единый шаблон конфигов и именования репозиториев, централизованный сбор логов с уведомлениями о провалах, регулярные тесты восстановления по расписанию, короткие отчеты (что копировали, сколько заняло, сколько данных добавилось).

Важно понимать границы. Restic и borg в S3 отлично закрывают файловые данные: каталоги, конфиги, дампы баз данных, снимки важных папок на серверах и виртуалках. А вот консистентные бэкапы сложных приложений все равно требуют сценариев: корректно остановить сервис или сделать дамп, проверить восстановление, убедиться, что приложение действительно стартует.

Подход хорошо подходит, если у вас один сервер в офисе, несколько филиалов, небольшая виртуальная среда или парк рабочих станций и серверов (например, на типовых ПК и стойках), где важны прозрачность, контроль и независимость от конкретного вендора.

Базовая схема: что копируем, куда и как защищаем

Минимальная рабочая схема для бэкапа restic и borg в S3 состоит из трех частей: источник данных (сервер или рабочая станция), репозиторий бэкапа (куда пишутся снапшоты) и S3-совместимое хранилище как удаленная цель. Поверх этого всегда есть еще два слоя: ключи шифрования и правила доступа.

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

Шифрование в restic включено по смыслу всегда: репозиторий шифруется паролем, а на стороне S3 лежат только зашифрованные блоки. У Borg шифрование зависит от режима при инициализации репозитория, поэтому важно один раз осознанно выбрать вариант с шифрованием и не держать репозиторий в открытом виде.

Ключевой вопрос: где хранить пароль и ключи. Самые практичные варианты:

• переменные окружения и файл с правами только для root
• системное хранилище секретов (если уже используете)
• отдельный офлайн-носитель для аварийного доступа (на случай, если сервер потерян)

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

• запись (append) для ежедневной работы
• только чтение для проверок и тестов восстановления
• отдельный админ-доступ, который не используется в расписании

Пример: в офисе госоргана в Казахстане можно настроить так, что файловый сервер пишет в S3-репозиторий ночью, а днем отдельная учетная запись только читает и раз в неделю делает тестовое восстановление во временную папку. Даже если ключ записи утечет, злоумышленнику будет сложнее незаметно удалить историю, если удаление и управление бакетом доступны только админ-ключом.

Restic или Borg: как выбрать без лишней теории

Restic и Borg решают одну и ту же задачу: делать «снимки» данных так, чтобы повторные бэкапы занимали меньше места. Оба поддерживают дедупликацию, сжатие (в разных формах) и шифрование на стороне клиента, то есть в хранилище уезжает уже зашифрованный набор блоков.

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

Когда проще выбрать restic

Restic часто выигрывает там, где нужен бэкап в S3 без лишних промежуточных слоев. Он говорит с S3-совместимым хранилищем «из коробки», поэтому схема обычно прямолинейная: машина -> S3.

Restic подходит, если у вас:

• S3-репозиторий как основной вариант (облако или S3 в своем ЦОД)
• много одинаковых узлов и хочется одинаковых команд и одинаковых логов
• минимум зависимостей в окружении и простая установка
• важна понятная автоматизация через cron/systemd без сложной обвязки
• нужно быстро подключать новые серверы по шаблону

Когда логичнее выбрать borg

Borg часто удобнее, если репозиторий вы держите на выделенном сервере и забираете данные по SSH. Это хороший вариант для сценария «центральный бэкап-сервер + много источников», особенно если S3 у вас только как внешняя копия через дополнительную синхронизацию.

Borg подходит, если вам ближе:

• репозитории на файловой системе и доступ по SSH
• строго контролируемая сеть без прямого выхода на S3 с рабочих серверов
• модель «один бэкап-хост обслуживает всех»

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

Подготовка S3-совместимого хранилища и доступов

Перед тем как настраивать бэкап restic и borg в S3, убедитесь, что выбранное хранилище действительно подходит. Термин «S3-совместимое» иногда означает «похоже на S3», но с нюансами, которые всплывают ночью, когда окно бэкапа уже закрывается.

Проверьте у провайдера вещи, которые чаще всего влияют на работу: поддержка AWS Signature v4, корректная работа больших объектов (multipart upload), лимиты на число запросов и размер объекта, а также формат адресации бакета (virtual-hosted или path-style). Если есть отдельный endpoint для региона, уточните его заранее и зафиксируйте в настройках.

Дальше разделите ресурсы. Делайте отдельный бакет под бэкапы и отдельного пользователя (или ключ) только для бэкапа. Это снижает риск случайного удаления и упрощает аудит.

Короткий чек-лист прав для пользователя бэкапа:

• доступ только к одному бакету
• чтение, запись, список объектов (без админских операций по аккаунту)
• запрет на удаление, если это возможно в вашей модели доступа
• отдельные ключи для тестовой и боевой среды

Если в хранилище доступно версионирование, включите его для бакета с бэкапами. Оно спасает, когда кто-то удалил или перезаписал объекты. Добавьте правила удаления (lifecycle), чтобы версии не росли бесконечно: например, хранить частые точки восстановления коротко, а редкие - дольше.

Секреты доступа храните так, будто это пароль от всего: не в общем чате и не в «заметках». Минимум - файл с правами 600 и доступом только сервисному пользователю. Лучше - системное хранилище секретов или механизмы systemd credentials.

В конце проверьте сеть: загрузите и скачайте тестовый файл на 1-5 ГБ с сервера, где будет идти бэкап (например, с вашей стойки или с сервера уровня GSE S200). Зафиксируйте реальную скорость и задержку, чтобы оценить, поместится ли копирование в доступное окно.

Настройка restic: пошаговый минимум для старта

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

Дальше подготовьте доступы к S3-совместимому хранилищу (ключ/секрет, имя бакета, путь) и выберите место, где будет храниться пароль репозитория. Пароль нужен всегда: restic шифрует данные на стороне клиента, и без пароля бэкап превращается в «невосстановимый архив».

Инициализация репозитория и первая проверка выглядят так (подставьте свои значения):

export AWS_ACCESS_KEY_ID="..."
export AWS_SECRET_ACCESS_KEY="..."
export RESTIC_REPOSITORY="s3:s3.example.local/backup-prod"
export RESTIC_PASSWORD="сильный_пароль"

restic -o s3.endpoint=s3.example.local init
restic snapshots

После init сделайте первый полный бэкап. На этом шаге важнее получить рабочий снимок, чем «идеальный» набор исключений:

restic -o s3.endpoint=s3.example.local backup /etc /home /var/lib/app
restic snapshots

Теперь добавьте исключения, чтобы не гонять лишнее. Обычно исключают:

• каталоги кэшей (например, */cache*)
• временные файлы (/tmp, */tmp*)
• большие каталоги сборки и загрузок, если они не нужны для восстановления
• логи, если у вас есть отдельная политика хранения логов

И последний обязательный шаг - «восстановление на пробу» в отдельную папку. Это занимает минуты, но сразу показывает, что пароль, доступ к S3 и структура данных в порядке.

mkdir -p /restore-test
restic restore latest --target /restore-test
ls -la /restore-test

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

Настройка borg: рабочая схема без сюрпризов

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

Самые надежные варианты два. Первый - репозиторий на отдельном SSH-шлюзе (или бэкап-сервере) с обычным диском, а уже потом каталог репозитория копируется в S3 отдельной задачей. Второй - промежуточное хранилище, где S3 смонтирован как файловая система. Он удобнее, но чаще дает проблемы из-за задержек, блокировок и неполной POSIX-совместимости. Для Borg обычно безопаснее «сначала локально, потом выгрузить».

Инициализация и шифрование

Выберите режим ключей: проще всего repokey (ключ хранится в репозитории, доступ защищен паролем) или keyfile (ключ отдельным файлом, его тоже надо резервировать). Пример инициализации:

export BORG_REPO=ssh://backup@backup-gw/./repos/app1
export BORG_PASSPHRASE='СильныйПароль'

borg init --encryption=repokey-blake2 "$BORG_REPO"

Дальше договоритесь о понятных именах архивов. Практика: имя хоста + роль + дата, чтобы быстро искать и сравнивать:

borg create --stats --compression lz4 \
  "$BORG_REPO"::"srv1-app-{now:%Y-%m-%d_%H%M}" \
  /etc /var/lib/app

Запуск по расписанию делайте через cron или systemd timer. В схеме «restic/borg + S3» Borg часто отвечает за локальные инкременты, а выгрузка в S3 идет отдельной задачей после успешного создания архива.

Проверка и тестовое восстановление

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

borg check --verify-data "$BORG_REPO"

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

mkdir -p /tmp/restore-test
borg extract "$BORG_REPO"::srv1-app-2026-01-11_0200 etc/app.conf
borg extract "$BORG_REPO"::srv1-app-2026-01-11_0200 --target /tmp/restore-test var/lib/app

Расписание и контроль окна бэкапа

Хороший бэкап живет по расписанию и не мешает рабочим сервисам. Для restic/borg чаще всего хватает cron или systemd-timer. Важнее не чем вы запускаете задания, а что и как проверяете после запуска.

Как сделать расписание

Начните с простого набора точек восстановления и усложняйте только если есть реальная потребность. Базовая схема обычно такая:

• каждый день ночью: инкрементальный бэкап данных и конфигов
• раз в неделю: «контрольная» копия + проверка целостности репозитория
• раз в месяц: отдельная точка, которую вы точно не удалите раньше срока
• после изменений: внеплановый бэкап перед обновлением или миграцией

Так вы покрываете и повседневные ошибки (удалили файл), и редкие проблемы (сбой после обновления).

Как держать окно под контролем

Окно бэкапа - это время, когда копирование влияет на диски, сеть и S3. Оцените его один раз и пересматривайте после роста данных: возьмите размер изменяемых данных за сутки, умножьте на 2 (запас), и сравните с реальной скоростью выгрузки и временем дедупликации.

Если бэкап мешает, ограничивайте нагрузку, а не «сдвигайте на потом». Рабочие приемы:

• ограничить скорость: у restic есть лимиты на upload/download, у borg - remote-ratelimit
• уменьшить параллелизм: меньше потоков часто дает более предсказуемую нагрузку
• разделить задачи: базы и большие каталоги копировать в разное время
• исключить лишнее: кэши, временные файлы и логи, которые можно восстановить иначе

Успех - это не «процесс что-то написал в лог». Считайте успешным только то, что завершилось корректным кодом: restic - 0, borg - 0 (код 1 у borg обычно означает «есть предупреждения», его стоит разбирать).

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

Хранение, ротация и проверки целостности

Хранилище бэкапов быстро превращается в свалку, если не договориться о простых правилах: сколько копий держим, когда удаляем и как убеждаемся, что архивы читаются. Для «бэкап restic и borg в S3» это особенно важно, потому что S3 обычно оплачивается по объему и операциям.

Правила хранения: сколько держать и почему

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

• Ежедневные: 7-14 дней, чтобы закрывать случайные удаления и быстрые откаты.
• Еженедельные: 4-8 недель, чтобы пережить поздно замеченные проблемы.
• Ежемесячные: 6-12 месяцев, если нужны отчеты, аудит или сезонные данные.
• «Перед изменениями»: отдельный снимок перед обновлениями, миграциями и патчами.

У restic и borg есть встроенные механизмы retention (политики сохранения). Важно одно: правила должны быть одинаковыми для всех серверов одного типа, иначе сложно прогнозировать объем.

Политика удаления и защита от ошибок

Удаление делайте только через безопасные команды самого инструмента, а не руками в бакете. Перед тем как включать автоматическое prune/compact, проведите 1-2 недели в режиме «только отчет»: пусть задача пишет, что именно будет удалено.

Проверка целостности нужна по расписанию. Обычно достаточно:

• быстрая проверка метаданных раз в неделю ночью или в выходные
• полная проверка (глубже и дольше) раз в месяц в отдельное окно, когда нагрузка минимальна

Стоимость S3 и роль дедупликации

Дедупликация у restic и borg снижает рост хранилища, если в данных много повторов (например, файловые шары, профили, почтовые базы). Но первый полный бэкап все равно будет большим, а затем рост зависит от ежедневных изменений. Следите за двумя метриками: общий размер репозитория и «сколько добавилось за сутки». Так вы быстро заметите, что кто-то начал бэкапить временные файлы или логи без ротации.

Простой журнал изменений настроек

Даже без сложных систем полезно вести короткий лог изменений:

• дата и причина (например, добавили исключение каталога)
• кто согласовал
• что поменяли в расписании/retention
• ожидаемый эффект на окно бэкапа и объем

Так проще разбирать инциденты: «почему удалились старые копии» или «почему проверка целостности стала идти вдвое дольше».

Регулярные тесты восстановления: как делать системно

Бэкап без восстановления не считается бэкапом. Пока вы не попробовали вернуть данные и запустить сервис, вы проверили только то, что «что-то куда-то записалось». Ошибка ключа шифрования, неверные права, битая цепочка инкрементов или забытый пароль репозитория часто всплывают именно в день аварии.

Чтобы тесты не превращались в разовую проверку «для галочки», сделайте простой календарь: раз в месяц проверяйте восстановление одного файла или небольшой папки, а раз в квартал прогоняйте полный сценарий. Это одинаково важно и для restic, и для borg, и для варианта с S3, где добавляется риск с доступами и политиками хранения.

Где и как восстанавливать

Лучше восстанавливать не поверх живых данных. Подойдет отдельная VM, отдельный каталог на тестовом диске или небольшой стенд. В офисной инфраструктуре это может быть тестовая виртуалка на сервере (например, на rack-сервере класса S200) с отключенным доступом пользователей, чтобы не было случайной порчи.

Один рабочий цикл теста может выглядеть так:

• выбрать «эталон» (файл, папку проекта, дамп базы) и дату восстановления
• восстановить в тестовую локацию и сверить размер, количество файлов, выборочно хэши
• проверить права (владельцы, группы, режимы), чтобы приложения могли читать данные
• запустить приложение или сервис в тестовом режиме и проверить ключевой сценарий (логин, отчет, поиск)
• удалить тестовые данные или заархивировать результат проверки

После каждого теста фиксируйте минимум: сколько заняло времени, какой объем восстановили, точные команды и шаги, итог (успех/частичный успех/провал) и причину, если что-то сломалось. Отдельно отмечайте, уложились ли в допустимое окно восстановления и не уперлись ли в пропускную способность сети или лимиты хранилища.

Если тест провалился, не откладывайте: исправление стоит вносить в тот же день, иначе к следующей аварии «временное» станет постоянным.

Частые ошибки и ловушки в настройке

Самая болезненная ошибка при работе с шифрованием - потерять пароль или ключ и понять это только в момент аварии. Для restic и borg это означает одно: данные в репозитории есть, но прочитать их нельзя. Минимум, который спасает: хранить секреты в менеджере паролей, иметь запасной способ доступа (например, запечатанный офлайн-контейнер) и заранее назначить ответственного, кто знает, где лежит план восстановления.

Вторая ловушка выглядит логично, но опасна: делать бэкап «рядом», то есть на тот же сервер, в тот же RAID или в то же облако под одной учетной записью. При взломе, ошибке администратора или сбое хранилища часто исчезает и рабочая копия, и резервная. Если вы делаете бэкап restic и borg в S3, разделяйте хотя бы уровни доступа и, по возможности, учетные записи.

Очень частая проблема - слишком широкие права к S3. Когда ключ может удалять бакеты и версии объектов, один неверный скрипт или компрометация ключа превращают резерв в пустоту. Давайте ключу только то, что нужно: запись в конкретный бакет, чтение для проверки и минимум прав на удаление, если ротация делается на стороне клиента.

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

Наконец, бэкапы часто «ломаются тихо»: ночь за ночью задания падают, а никто не замечает. Проверьте себя по короткому списку:

• есть оповещение о неуспешном запуске и о превышении времени выполнения
• виден последний успешный бэкап и его размер (чтобы заметить внезапное «0 МБ»)
• ключи доступа к S3 имеют срок и понятную процедуру ротации
• по расписанию делается проверка целостности репозитория
• раз в месяц выполняется тестовое восстановление в отдельную папку или VM

Простой пример: после обновления приложения каталог с данными переехал с /var/lib на /srv, а исключения остались прежними. Бэкап продолжает «успешно» проходить, но восстановить нечего. Такие вещи ловятся только мониторингом размеров и регулярными тестами восстановления.

Пример сценария: офисная инфраструктура и S3 как внешняя копия

Представим обычный офис на 15-30 пользователей. Есть файловый сервер с общими папками (договоры, сканы, проекты), отдельная машина под 1С и база данных, плюс несколько важных каталогов на сервере приложений (конфиги, отчеты). Задача простая: если сломается диск, сервер или кто-то удалит папку, данные должны вернуться быстро и без «охоты» по ноутбукам.

RPO и RTO лучше формулировать по-человечески. RPO - сколько данных вы готовы потерять: например, максимум 1 час работы бухгалтерии и 4 часа по общим папкам. RTO - как быстро нужно восстановиться: например, доступ к файлам за 2 часа, 1С за 4-6 часов (хотя бы на временный стенд).

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

По расписанию это обычно выглядит так:

• ночью: полный прогон (или «полный по логике», с дедупликацией), когда нагрузка минимальна
• днем: короткие дельты каждые 1-2 часа только по самым важным данным
• перед закрытием дня: отдельный бэкап базы 1С (дамп или штатный механизм) и сразу отправка во внешний репозиторий

Тест восстановления стоит сделать частью рутины. Раз в неделю восстановите выборку: пару папок с документами и один случайный файл «из глубины». Раз в месяц поднимите полный стенд: разверните сервер (можно на отдельной машине или виртуалке), восстановите базу и проверьте, что 1С реально открывается.

Понять, что «все в норме», помогают простые метрики:

• возраст последнего успешного бэкапа (в часах) по файлам и по базе
• длительность бэкапа и укладывается ли он в окно ночью
• процент успешных задач за 7 дней (без ручных «перезапусков»)
• время реального тестового восстановления (сколько минут до открытия нужного файла/базы)

Следующие шаги: закрепить результат и масштабироваться

Перед тем как выпускать бэкап restic и borg в S3 в прод, полезно навести порядок в мелочах. Именно они чаще всего ломают восстановление в самый нужный момент.

Чеклист перед запуском

Проверьте базу по короткому списку, и только потом ставьте расписание «как у взрослых»:

• доступы: отдельные ключи для бэкапов, минимум прав, понятное имя репозитория
• шифрование: пароль/ключи хранятся отдельно от сервера, есть резервная копия ключевого материала
• тест восстановления: хотя бы один раз развернули файлы в пустую папку и проверили, что они открываются
• окно бэкапа: вы знаете, сколько занимает полный и инкрементальный прогон, и это укладывается в ночь/выходные
• логи и уведомления: видно, когда был последний успешный прогон и сколько данных ушло

Если тест восстановления проходит только «на словах», это не бэкап, а надежда.

Как масштабировать без хаоса

Когда бэкап охватывает не один сервер, а несколько ролей (БД, файлы, виртуалки), заранее решите, как разделяете ответственность и репозитории. Часто работает одна из простых моделей:

• один репозиторий на сервер (проще искать и восстанавливать точечно)
• один репозиторий на роль (например, отдельно базы, отдельно файловые данные)
• разные репозитории по уровню доступа (чтобы админы приложений не имели доступа к критичным копиям)

Дальше все упирается в ресурсы. Отдельный сервер под бэкапы стоит добавить, если ночные окна не укладываются, растет нагрузка на прод или нужно хранить локальный буфер перед выгрузкой в S3. Обновление железа оправдано, когда компрессия/дедупликация «съедает» CPU, а проверка целостности начинает мешать работе.

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

Если нужна помощь с инфраструктурой, у GSE.kz есть опыт системной интеграции. Для задач бэкап-сервера или узла под хранение могут подойти стойчные серверы GSE S200, а дальше важнее всего договориться о понятном SLO по восстановлению и регулярных проверках.