Бэкап и восстановление Kopia

MAATRIX

restic и Borg решают задачу бэкапа надёжно, но у обоих нет штатной веб-панели — чтобы посмотреть список снапшотов не в терминале, нужно ставить что-то отдельное сверху. Kopia закрывает этот разрыв: та же дедупликация на уровне блоков и то же сквозное шифрование, но плюс встроенный веб-интерфейс, который поднимается на сервере одной командой, и сжатие данных «из коробки» с выбором алгоритма под тип данных. Ниже — установка, репозиторий на разных бэкендах, политики хранения и проверенное восстановление.

Чем Kopia отличается от restic и Borg

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

Установка

Kopia распространяется как статический бинарник на Go и через собственный APT-репозиторий:

curl -s https://kopia.io/signing-key | gpg --dearmor -o /etc/apt/keyrings/kopia-keyring.gpg
echo "deb [signed-by=/etc/apt/keyrings/kopia-keyring.gpg] http://packages.kopia.io/apt/ stable main" \
  | tee /etc/apt/sources.list.d/kopia.list
apt update && apt install kopia

Если репозиторий недоступен или вы на AlmaLinux/RHEL — берите бинарник со страницы GitHub Releases проекта kopia/kopia, распакуйте и положите в /usr/local/bin:

tar -xzf kopia-*-linux-x64.tar.gz && mv kopia-*/kopia /usr/local/bin/kopia
chmod +x /usr/local/bin/kopia && kopia --version

Репозиторий: локальный диск, S3, SFTP

Репозиторий Kopia — каталог с зашифрованными данными, привязанный к паролю. Пароль нигде не хранится в открытом виде — потеряете его, данные не восстановить.

Локальный диск или примонтированный том:

mkdir -p /mnt/backup-disk/kopia-repo
export KOPIA_PASSWORD='сложный-пароль-минимум-20-символов'
kopia repository create filesystem --path=/mnt/backup-disk/kopia-repo

S3-совместимое хранилище — вариант, когда бэкап должен физически лежать отдельно от исходного сервера:

kopia repository create s3 \
  --bucket=my-backups \
  --access-key=ваш_access_key \
  --secret-access-key=ваш_secret_key \
  --endpoint=s3.example.com \
  --region=us-east-1

Работает с любым S3-совместимым провайдером — достаточно поменять --endpoint. Требования к диску и сети для сервера-хранилища бэкапов разобраны в статье про подбор VPS под бэкапы и архив.

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

kopia repository create sftp \
  --path=/home/backupuser/kopia-repo \
  --host=203.0.113.10 --username=backupuser \
  --keyfile=/root/.ssh/id_ed25519

К уже созданному репозиторию на новой машине подключаются командой kopia repository connect с теми же параметрами вместо create — это нужно при восстановлении на другой сервер.

Первый снепшот, сжатие и политики хранения

Снепшот создаётся командой snapshot create с указанием путей:

kopia snapshot create /etc /home /var/www /var/lib/mysql
kopia snapshot list --all

Исключения задаются через политику, привязанную к пути, а не флагами команды:

kopia policy set /var/www \
  --add-ignore="*.tmp" \
  --add-ignore="node_modules" \
  --add-ignore="*.log"

Сжатие включается на уровне политики и работает до шифрования — алгоритм выбирается под тип данных: zstd как разумный баланс, s2-default для скорости на слабом CPU:

kopia policy set /var/www --compression=zstd
kopia policy set /var/lib/mysql --compression=s2-default

Экономия от сжатия зависит от данных — на текстовых конфигах и дампах БД она заметна, на уже сжатых медиафайлах смысла почти нет, там разумнее --compression=none, чтобы не тратить CPU впустую.

Retention задаётся так же через policy set, обычно глобально:

kopia policy set --global \
  --keep-latest=10 --keep-hourly=24 --keep-daily=30 \
  --keep-weekly=12 --keep-monthly=12 --keep-annual=2

В отличие от restic, где forget/prune запускают вручную по расписанию, у Kopia есть встроенное обслуживание (maintenance): быстрая уборка идёт автоматически после части снепшотов, полная — по умолчанию раз в сутки, если репозиторий подключён «владельцем» (kopia maintenance info покажет статус). Если бэкап запускаете из cron/systemd без постоянно работающего kopia server, автообслуживание может срабатывать нерегулярно — тогда добавьте kopia maintenance run --full отдельным шагом после snapshot create в тот же unit.

Kopia Server: веб-интерфейс без сторонних панелей

Главное практическое отличие от restic и Borg — веб-UI поднимается без установки отдельной панели:

kopia server start \
  --address=0.0.0.0:51515 \
  --tls-generate-cert \
  --server-username=admin \
  --server-password='отдельный-сложный-пароль-для-веб-ui'

Сервер сгенерирует самоподписанный TLS-сертификат и поднимет HTTPS на порту 51515. Браузер будет ругаться на сертификат — это ожидаемо; для валидного сертификата поставьте перед Kopia обратный прокси nginx с Let's Encrypt, настройка которого разобрана в статье про Let's Encrypt SSL на сервере.

Для постоянной работы оформите сервер как systemd-сервис:

# /etc/systemd/system/kopia-server.service
[Unit]
Description=Kopia backup server
After=network.target

[Service]
Type=simple
EnvironmentFile=/etc/kopia/env
ExecStart=/usr/local/bin/kopia server start --address=0.0.0.0:51515 \
  --tls-generate-cert --server-username=admin \
  --server-password-file=/etc/kopia/server-password
Restart=on-failure

[Install]
WantedBy=multi-user.target

systemctl daemon-reload && systemctl enable --now kopia-server

Если бэкапите несколько машин в один репозиторий и не хотите раздавать всем общий пароль, Kopia поддерживает отдельных пользователей на уровне сервера (kopia server user add alice@host-02). Открывать порт 51515 наружу без ограничений не стоит — закройте его файрволом для всех адресов, кроме своего, или ходите через SSH-туннель: ssh -L 51515:localhost:51515 user@ваш-сервер, и открывайте https://localhost:51515 уже у себя.

Восстановление: restore, mount, проверка целостности

Восстановление снепшота в отдельный каталог — восстанавливать поверх боевых данных без проверки не стоит:

kopia snapshot restore <ID-снепшота> /tmp/restore-check

Восстановление одного файла без разворачивания всего снепшота — путь внутри снепшота указывается через слэш после ID:

kopia snapshot restore <ID-снепшота>/var/www/site/wp-config.php /tmp/restore-check/wp-config.php

Через веб-интерфейс это делается нагляднее: в снепшоте можно пролистать дерево файлов и восстановить нужный по клику, не вспоминая синтаксис — ради этого многие и переходят с CLI-only инструментов.

Смонтировать снепшот как файловую систему для точечного просмотра истории (Ctrl+C в терминале с mount отмонтирует):

mkdir -p /mnt/kopia-fuse
kopia mount <ID-снепшота> /mnt/kopia-fuse

Целостность репозитория стоит проверять отдельно от бэкапа — повреждение блоков на диске или в облаке обнаруживается не при записи, а при чтении:

kopia snapshot verify --verify-files-percent=10

Полная проверка (--verify-files-percent=100) вычитывает весь репозиторий и на большом объёме дорога по трафику, особенно на S3 — выборочную проверку гоняют чаще, полную раз в месяц. Общий принцип не специфичен для Kopia: бэкап, который ни разу не восстанавливали, не даёт гарантий — практика тестового восстановления подробнее разобрана в статье про восстановление базы данных из бэкапа. Для СУБД та же оговорка, что и для любого дедуплицирующего бэкапа: копируйте логический дамп (mysqldump/pg_dump), а не «живые» файлы — так вы получаете согласованную точку восстановления.

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