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

MAATRIX

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

Что такое Duplicati и кому он подходит

Duplicati — open-source приложение для инкрементного резервного копирования с веб-панелью управления. Из коробки умеет:

• дедупликацию и инкрементные бэкапы (после первого полного слепка передаются только изменённые блоки);
• шифрование AES-256 или GPG прямо на клиенте, до отправки данных наружу;
• десятки бэкендов хранения: локальная папка, SFTP/SSH, S3-совместимое хранилище (Backblaze B2, MinIO, Selectel, AWS S3), WebDAV, Google Drive, OneDrive и другие;
• гибкое расписание и политику хранения версий (retention policy);
• отчёты по e-mail и через HTTP-вебхуки после каждого прогона.

Кому подходит: тем, кто обслуживает сервер не каждый день и не хочет держать в голове синтаксис restic/borg; небольшим командам, где бэкапы настраивает не только DevOps; тем, кому нужен наглядный контроль версий и быстрый рестор через браузер. Если вы уже уверенно пишете bash-скрипты и вам важна максимальная скорость и минимальный оверхед — присмотритесь к бэкапу с шифрованием на VPS, там разобран более «сырой» подход через gpg и rsync.

Минус Duplicati — он написан на .NET и веб-приложение постоянно потребляет немного памяти в фоне (обычно 150–300 МБ, но это ориентир — на вашем сервере может отличаться в зависимости от объёма и числа заданий). На VPS с 1 ГБ RAM это чувствительно, поэтому для продакшена лучше закладывать от 2 ГБ.

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

Есть два рабочих пути: через Docker (проще обновлять и изолировать) и нативно через deb/rpm-пакет. Разберём оба на Ubuntu/Debian.

Вариант 1: Docker Compose (рекомендуется)

Создайте директорию и compose-файл:

mkdir -p /opt/duplicati/{config,backups}
cd /opt/duplicati
nano docker-compose.yml

services:
  duplicati:
    image: duplicati/duplicati:latest
    container_name: duplicati
    restart: unless-stopped
    ports:
      - "127.0.0.1:8200:8200"
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Moscow
      - SETTINGS_ENCRYPTION_KEY=замените-на-случайную-строку
    volumes:
      - ./config:/config
      - ./backups:/backups
      - /home:/source/home:ro
      - /etc:/source/etc:ro
      - /var/www:/source/www:ro

Обратите внимание: порт пробрасывается только на 127.0.0.1 — это сознательно, доступ снаружи организуем позже через реверс-прокси с TLS, а не голым HTTP-портом наружу. Каталоги с исходными данными монтируются :ro (read-only), чтобы Duplicati физически не мог ничего в них изменить.

docker compose up -d
docker compose logs -f duplicati

Вариант 2: нативная установка (deb-пакет)

Подходит, если вы принципиально не используете Docker на сервере — сравнение подходов есть в статье Docker или LXC — что выбрать для сервера.

cd /tmp
wget https://github.com/duplicati/duplicati/releases/latest/download/duplicati_amd64.deb
apt update
apt install ./duplicati_amd64.deb
systemctl enable --now duplicati.service
systemctl status duplicati.service

Точное имя файла и версию берите со страницы релизов проекта — она меняется, и «зашивать» конкретный номер версии в статью смысла нет. По умолчанию сервис слушает 127.0.0.1:8200 — так же, как и в Docker-варианте.

Первый вход, пароль и HTTPS через реверс-прокси

Открывать 8200 порт наружу — плохая идея: панель управления бэкапами не должна торчать в интернет без TLS и с паролем по умолчанию (а первый запуск вообще без пароля). Правильный путь — SSH-туннель для первого захода и реверс-прокси для постоянного доступа.

Для разовой проверки прокиньте порт через SSH с локальной машины:

ssh -L 8200:127.0.0.1:8200 user@ваш-сервер

и откройте http://127.0.0.1:8200 в браузере. Сразу зайдите в Settings → General → Set password и задайте пароль веб-интерфейса — это не пароль от шифрования бэкапов, а отдельная защита панели.

Для постоянного доступа поднимите Caddy или nginx как реверс-прокси с автоматическим Let's Encrypt — это займёт 10 минут по инструкции Caddy с авто-SSL на VPS или Nginx как реверс-прокси на VPS. Пример конфига Caddy:

backup.вашдомен.ру {
    reverse_proxy 127.0.0.1:8200
    basicauth {
        admin $2a$14$хэш-пароля-bcrypt
    }
}

Двойной слой защиты (basic auth от Caddy + пароль самого Duplicati) — не паранойя, а разумный минимум для панели, через которую можно скачать содержимое всех бэкапов сервера.

Создание задания резервного копирования

В интерфейсе Duplicati задание (Backup) собирается за 5 шагов мастера.

1. General — имя задания и пароль шифрования. Duplicati предложит сгенерировать случайный AES-256 ключ или задать свой. Здесь важнейший момент всей настройки:

> Если вы потеряете пароль шифрования, восстановить данные из бэкапа будет невозможно — ни поддержка, ни разработчики Duplicati это сделать не смогут. Пароль нужно сохранить в отдельном месте, не на этом же сервере — например, в Vaultwarden на другом хосте, в менеджере паролей или в распечатанном виде в сейфе.

2. Destination (назначение) — куда пойдут данные. Для продакшн-сценария разумно хранить бэкапы не на том же сервере, а на отдельной VPS через SFTP или в S3-совместимом хранилище — иначе при потере сервера вы теряете и данные, и их копии одновременно. Пример SFTP-назначения:

• Storage Type: SFTP
• Server: IP-второго-сервера
• Port: 22
• Path on server: /backups/prod-server-1
• Username/Password или SSH key

Если под бэкапы нужен именно отдельный сервер с достаточным диском, посмотрите лучший VPS для бэкапов — там разобраны требования к объёму диска и типу хранилища под такую роль.

3. Source Data — какие пути включить в бэкап. Отмечаете директории в дереве или вписываете вручную:

/etc
/home
/var/www
/opt/*/data

Здесь же задаются фильтры исключений (Filters) — например, исключить кэш и временные файлы:

-*/node_modules/
-*/.cache/
-*.tmp

4. Schedule — расписание. Для большинства проектов достаточно ежедневного прогона ночью:

• Run: Automatically
• Next: завтра, 03:00
• Repeat: Every 1 Day
• Allowed days: все или рабочие — на ваше усмотрение

5. Options — тонкая настройка:

Retention policy 1W:1D,4W:1W,12M:1M означает: за последнюю неделю хранить снапшот за каждый день, за последний месяц — по одному снапшоту в неделю, за последний год — по одному в месяц. Это встроенный формат Duplicati, не нужно писать отдельный скрипт очистки старых копий, как при работе с сырым rsync.

Восстановление данных

Восстановление делается прямо из веб-интерфейса, без командной строки:

1. Откройте задание → вкладка Restore.
2. Выберите версию бэкапа по дате из выпадающего списка (Duplicati хранит все версии согласно retention policy).
3. Отметьте файлы или папки для восстановления — можно выбрать как весь бэкап, так и один файл.
4. Укажите, куда восстанавливать: в исходное расположение или в отдельную директорию (по умолчанию Duplicati предлагает восстановить в /tmp или отдельную папку, чтобы не перезаписать текущие данные без подтверждения).
5. Нажмите Restore и дождитесь прогресса — для больших объёмов это может занять заметное время, зависит от канала до хранилища и числа изменённых блоков.

Для баз данных (MySQL/PostgreSQL) Duplicati бэкапит файлы, но не делает консистентный дамп на лету — если в источниках есть каталоги БД, используйте mysqldump/pg_dump в отдельный файл по cron перед прогоном Duplicati, а сам Duplicati настройте на бэкап уже готового дампа. Разбор этого сценария и типичных ошибок — в статье бэкап MySQL на VPS, а общая практика восстановления БД из архива — в восстановлении базы данных из бэкапа.

Мониторинг, уведомления и частые проблемы

Duplicati умеет слать отчёт после каждого прогона на e-mail или на произвольный HTTP(S)-вебхук (Settings → Default options → send-mail- / send-http-). Второй вариант удобно завести на Uptime Kuma через push-мониторинг или на healthchecks.io — тогда вы узнаете не только о падении сервера, но и о том, что бэкап несколько дней не запускался.

Частые проблемы новичков:

• Веб-интерфейс недоступен извне. Ожидаемо, если вы не настроили реверс-прокси — по умолчанию Duplicati слушает только 127.0.0.1. Это не баг, а защита по умолчанию.
• Задание «зависает» на статусе Running. Обычно означает разрыв соединения с бэкендом на середине прогона и повреждённую локальную базу состояния. Помогает Database → Repair, в тяжёлых случаях — Recreate (delete and rebuild), что дольше, но чище.
• Бэкап растёт быстрее, чем должен. Проверьте фильтры исключений — частая причина: в source попали логи или временные файлы, которые постоянно меняются и создают новые блоки при каждом прогоне.
• Высокая нагрузка на CPU во время бэкапа. Уровень сжатия Maximum и мелкий Remote volume size (много мелких файлов) — первое, что стоит проверить и ослабить.
• Кончилось место на диске с бэкапами. Проверьте retention policy — если версий накопилось больше, чем предполагали, пересчитайте её или перенесите старые архивы. Общий подход к нехватке места на VPS — в статье кончилось место на диске VPS.

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