Как установить и настроить Kopia на VPS

MAATRIX

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

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

Kopia — открытый инструмент резервного копирования (написан на Go), который умеет то же, что restic и Borg: контентно-адресуемое хранилище, дедупликацию на уровне блоков переменного размера, сжатие и клиентское шифрование (AES-256-GCM или ChaCha20-Poly1305). Отличие — в удобстве эксплуатации.

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

Ниже — установка на Ubuntu 24.04 / Debian 12, актуальная на конец августа 2026 года. Для CentOS-подобных систем шаги аналогичны, отличается только пакетный менеджер.

Установка Kopia на VPS

Официальный способ — репозиторий apt. Добавляем ключ и источник:

sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://kopia.io/signing-key | sudo 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" \
  | sudo tee /etc/apt/sources.list.d/kopia.list

sudo apt update
sudo apt install kopia

Проверяем версию — на момент публикации актуальна ветка 0.19.x, но сверьтесь с apt-cache policy kopia, версии выходят регулярно:

kopia --version

Альтернатива — скачать статический бинарник с GitHub-релизов проекта (kopia/kopia) и положить в /usr/local/bin/kopia с правом на выполнение. Это удобно, если на сервере нет доступа к внешним apt-репозиториям или используется дистрибутив без готового пакета.

Отдельная пользовательская учётка под бэкапы — хорошая практика, особенно если Kopia будет ходить по SSH на другой сервер:

sudo useradd -m -s /bin/bash kopia-backup
sudo mkdir -p /home/kopia-backup/.config/kopia
sudo chown -R kopia-backup:kopia-backup /home/kopia-backup/.config

Дальше все команды выполняются либо от root (если бэкапите системные пути, требующие root-доступа), либо от этого выделенного пользователя.

Создание репозитория для бэкапов

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

Локальная файловая система (для теста или если диск примонтирован отдельно, например NFS/сетевой том):

kopia repository create filesystem --path=/mnt/backup-storage

SFTP на второй VPS — практичный вариант, если у вас есть отдельный сервер под архивы (пример настройки такого сервера — в статье про VPS для бэкапов и архива):

kopia repository create sftp \
  --path=/backups/prod-server-1 \
  --host=backup.example.com \
  --port=22 \
  --username=kopia-backup \
  --keyfile=/home/kopia-backup/.ssh/id_ed25519

Доступ по ключу вместо пароля обязателен для такой схемы — как его настроить, разобрано в статье про SSH-ключи вместо пароля.

S3-совместимое хранилище (подходит любой провайдер с S3 API, включая self-hosted MinIO):

kopia repository create s3 \
  --bucket=my-backups-bucket \
  --endpoint=s3.example.com \
  --access-key=AKIAxxxxxxxxxxxx \
  --secret-access-key=xxxxxxxxxxxxxxxxxxxxxxxx \
  --region=us-east-1

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

Чтобы подключиться к уже созданному репозиторию с другой машины (например, при переносе или для второй копии на чтение), используется kopia repository connect с теми же параметрами backend и паролем.

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

Снапшот — это точка сохранения состояния каталога. Запускаем вручную:

kopia snapshot create /etc
kopia snapshot create /var/www
kopia snapshot create /home

Список снапшотов и их размер после дедупликации:

kopia snapshot list --all

По умолчанию Kopia хранит все снапшоты бесконечно — это быстро съест место. Политики хранения задаются глобально или на конкретный путь:

# глобальная политика хранения
kopia policy set --global \
  --keep-latest=5 \
  --keep-hourly=24 \
  --keep-daily=14 \
  --keep-weekly=8 \
  --keep-monthly=6

# отдельная политика на путь с исключениями и своим сжатием
kopia policy set /var/www \
  --add-ignore="node_modules" \
  --add-ignore="*.log" \
  --add-ignore="/var/www/**/cache" \
  --compression=zstd

Логика такая же, как в restic и Borg: хранить последние N снапшотов, плюс по одному за час/день/неделю/месяц на нужную глубину, остальное — схлопывать при следующем обслуживании (kopia maintenance run). Обслуживание запускается автоматически при работе сервера или планировщика; если снапшоты создаются только через cron без запущенного kopia server, разово прогоните kopia maintenance run --full вручную после первых бэкапов, чтобы убедиться, что чистка отрабатывает.

Проверить целостность данных в репозитории (без полного restore):

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

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

Веб-интерфейс: запуск Kopia как systemd-сервиса

Здесь Kopia сильнее всего отличается от конкурентов — можно поднять постоянно работающий сервер с UI, который сам по расписанию снимает снапшоты по заданным политикам и показывает историю, использование места и ошибки.

Создаём пользователя для входа в UI:

kopia server user add admin@prod-server-1
# спросит пароль для этого пользователя интерфейса

Юнит systemd:

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

[Service]
Type=simple
User=kopia-backup
ExecStart=/usr/bin/kopia server start \
  --address=127.0.0.1:51515 \
  --tls-generate-cert \
  --server-username=admin@prod-server-1 \
  --insecure=false
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

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

Обратите внимание: адрес привязан к 127.0.0.1 — сервер слушает только локально. Наружу интерфейс лучше не выставлять напрямую, а пробросить через SSH-туннель (ssh -L 51515:127.0.0.1:51515 user@server) или через nginx с базовой авторизацией и отдельным TLS-сертификатом, если нужен постоянный доступ из браузера. Firewall на сервере в любом случае должен закрывать 51515 порт для внешних адресов — правило для UFW разобрано в статье про настройку firewall UFW.

После запуска сервера каталоги для бэкапа и их политики добавляются через сам UI (раздел Snapshots → Add New) — это тот случай, когда графический интерфейс реально экономит время по сравнению с флагами командной строки.

Автоматизация и восстановление данных

Если веб-сервер не нужен и достаточно снапшотов по расписанию — используем cron без запуска kopia server:

# crontab -e для пользователя kopia-backup
0 3 * * * /usr/bin/kopia snapshot create /etc /var/www /home >> /var/log/kopia-snapshot.log 2>&1
30 4 * * 0 /usr/bin/kopia maintenance run --full >> /var/log/kopia-maintenance.log 2>&1

Для восстановления есть два пути. Точечное восстановление конкретного снапшота в каталог:

kopia snapshot list /var/www
kopia snapshot restore <snapshot-id> /tmp/restore-www

И «примонтировать» снапшот как файловую систему через FUSE — удобно, если нужно достать один файл, не разворачивая весь бэкап:

kopia mount <snapshot-id> /mnt/kopia-browse
ls /mnt/kopia-browse
cp /mnt/kopia-browse/etc/nginx/nginx.conf /etc/nginx/nginx.conf.restored
fusermount -u /mnt/kopia-browse

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

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