Kopia или restic: что выгоднее и когда

MAATRIX

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

Архитектура и подход к бэкапам

Restic написан на Go, распространяется одним статическим бинарником и сознательно минималистичен: никакого демона, никакого веб-интерфейса, только CLI. Репозиторий — это набор зашифрованных блоков (pack-файлов) в плоской структуре, снапшоты — метаданные поверх них. Формат репозитория стабилен с версии 2 (repository format version 2, поддержка с restic 0.14+) и документирован — при желании можно разобрать структуру руками.

Kopia — тоже Go, тоже один бинарник, но устроена сложнее: под капотом content-addressable storage с собственным индексом блоков, плюс отдельный демон kopia server с веб-UI и API. Kopia изначально проектировалась с прицелом на многопользовательские сценарии — несколько машин пишут в один репозиторий, у каждой свой набор политик (retention, расписание, исключения), и всё это видно в одном UI.

Практический вывод: если вам нужен именно бэкап-инструмент для скриптов и cron — восстановления и здравомыслия хватит у обоих. Если нужен центр управления бэкапами нескольких машин с визуальным контролем — Kopia ближе к этому из коробки.

Дедупликация и производительность

Оба инструмента режут файлы на чанки переменного размера (content-defined chunking) и хранят только уникальные блоки — это и есть дедупликация, которая экономит место при бэкапе однотипных данных (виртуалки, базы, логи).

Разница в деталях:

• Restic использует алгоритм chunking на основе полиномиального Rabin fingerprinting, размер чанка ~512 КБ – 8 МБ (усреднённо ~1 МБ). Хранит индекс блоков в памяти при бэкапе и check — на репозиториях в сотни ГБ это заметно ест RAM.
• Kopia по умолчанию режет чанками помельче и использует более новый splitter (buzhash по умолчанию, есть варианты), плюс параллельную загрузку блоков в несколько потоков — на многоядерных серверах бэкап обычно идёт быстрее restic при прочих равных.

Точных цифр «во сколько раз быстрее» приводить не буду — разброс сильно зависит от типа данных (много мелких файлов вроде node_modules бэкапится совсем не так, как один большой дамп PostgreSQL), скорости диска и сети до хранилища. На своих тестах меряйте сами: time restic backup /data против time kopia snapshot create /data на одинаковом наборе файлов и одинаковом бэкенде.

Один нюанс, который часто упускают: у restic команда check --read-data перечитывает весь репозиторий целиком для проверки целостности, и на большом архиве это не быстрая операция. У Kopia есть встроенная периодическая проверка (kopia maintenance), которая размазывает нагрузку по расписанию, а не требует ручного полного прогона.

Хранилища и облака: куда бэкапить

Здесь оба инструмента практически равны — оба поддерживают локальный диск, SFTP, S3 и S3-совместимые хранилища (MinIO, Backblaze B2 через S3-API), Azure Blob, Google Cloud Storage.

Если бэкапите на MinIO, который сами же и держите на арендованном сервере — разницы почти нет, оба подключаются одинаково просто. Если же хочется единую точку с UI, куда льют бэкапы несколько машин с разными правами доступа (репозитории с ACL по клиенту) — тут у Kopia готовое решение, а у restic пришлось бы городить это вручную поверх SFTP-chroot или отдельных S3-бакетов на клиента.

Установка и первый бэкап

Restic:

# Ubuntu/Debian
apt install restic
# или последний бинарник
curl -L https://github.com/restic/restic/releases/latest/download/restic_linux_amd64.bz2 \
  -o restic.bz2 && bunzip2 restic.bz2 && chmod +x restic && mv restic /usr/local/bin/

export RESTIC_REPOSITORY=s3:https://s3.example.com/my-backups
export RESTIC_PASSWORD=выберите-надёжный-пароль
export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...

restic init
restic backup /var/www /etc /home --exclude='*.log'

Kopia:

# скачать бинарник с GitHub Releases
curl -L https://github.com/kopia/kopia/releases/latest/download/kopia-linux-amd64.tar.gz \
  -o kopia.tar.gz && tar xzf kopia.tar.gz && mv kopia-*/kopia /usr/local/bin/

kopia repository create s3 \
  --bucket=my-backups \
  --access-key=... --secret-access-key=... \
  --endpoint=s3.example.com \
  --password=выберите-надёжный-пароль

kopia policy set --global --exclude='*.log' --keep-daily 7 --keep-weekly 4
kopia snapshot create /var/www /etc /home

Разница уже видна: у restic политики хранения (retention) задаются отдельной командой forget --keep-daily 7 --keep-weekly 4 при каждом запуске или через systemd-таймер с двумя шагами (backup + forget + prune). У Kopia политика — часть репозитория, задаётся один раз через policy set и применяется автоматически при каждом снапшоте, prune (kopia maintenance run) тоже запускается по расписанию сама, без отдельного шага в скрипте.

Для восстановления доступа к репозиторию по SSH пригодится статья про установку restic на VPS и параллельно про установку Kopia на VPS — там подробно расписана подготовка сервера и systemd-юниты.

Восстановление, verify и обслуживание репозитория

Восстановление у обоих простое:

# restic
restic snapshots
restic restore latest --target /restore

# kopia
kopia snapshot list
kopia snapshot restore <snapshot-id> /restore

Разница проявляется в удобстве частичного восстановления. У Kopia можно смонтировать снапшот как файловую систему (kopia mount <snapshot-id> /mnt/backup) и скопировать нужные файлы через обычный cp — удобно, когда нужен один файл из бэкапа за прошлый вторник, а не весь снапшот целиком. У restic то же самое делается через restic mount /mnt/backup (нужен FUSE), работает похоже, но интерфейс монтирования у Kopia субъективно отзывчивее на больших репозиториях.

По обслуживанию:

• restic: restic forget --keep-daily 7 --prune удаляет старые снапшоты и освобождает место; restic check проверяет целостность метаданных, restic check --read-data-subset=10% — частичная проверка данных без перечитывания всего репозитория (разумный компромисс для регулярного запуска).
• Kopia: обслуживание встроено — kopia maintenance run (быстрый режим по умолчанию каждый час, полный — раз в сутки при активном сервере) чистит неиспользуемые блоки и проверяет консистентность индекса без ручного планирования.

На практике это значит: с restic вам придётся самим собрать cron/systemd-таймер из трёх шагов (backup → forget → check), с Kopia через kopia server --insecure большая часть обслуживания уходит в фон сама. Если сервер держите именно под бэкапы нескольких проектов, посмотрите также сколько RAM нужно под Kopia и сколько RAM нужно под restic — потребление памяти у обоих растёт с размером репозитория, но по-разному, и это стоит учитывать при выборе тарифа сервера.

Что выбрать: сценарии

Коротко по ситуациям:

• Один сервер, простой cron-бэкап в S3, минимум зависимостей. Restic — один бинарник, три команды в скрипте, никакого демона в фоне. Меньше площадь для сюрпризов.
• Несколько серверов/рабочих станций, бэкап в общий репозиторий, нужен обзор состояния бэкапов в одном месте. Kopia с kopia server и веб-UI — не придётся писать свой дашборд поверх restic snapshots по cron с рассылкой в Telegram.
• Бэкап большого числа мелких файлов (десятки миллионов, например веб-хостинг с тысячами сайтов). Тут стоит протестировать оба на реальных данных — параллельная загрузка Kopia часто выигрывает по времени, но indexing на старте у обоих может быть заметно медленнее на файловых деревьях такого масштаба.
• Уже есть скрипты и опыт с restic, всё работает. Менять шило на мыло смысла нет — restic зрелый, стабильный, формат репозитория не меняли годами.
• Нужна интеграция с существующей инфраструктурой мониторинга через API. У Kopia есть HTTP API сервера из коробки, у restic для метрик обычно оборачивают вывод команд самописным экспортёром для Prometheus.

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

Ни то ни другое не заменяет главное правило бэкапов — 3-2-1 (три копии, два разных носителя, одна вне площадки). И restic, и Kopia одинаково хорошо укладываются в эту схему: локальный снапшот на диске сервера плюс копия в S3-хранилище в другом регионе или у другого провайдера закрывает большинство сценариев отказа, включая полную потерю сервера.

Частые вопросы