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

MAATRIX

Если restic и borg кажутся избыточно «терминальными» — писать скрипты, парсить вывод, помнить флаги для листинга снапшотов, — Duplicati решает ту же задачу через браузер: создали задание в веб-интерфейсе, выставили расписание, нажали «Сохранить», и дальше бэкапы идут сами. Расплата за удобство — свои нюансы: SQLite-база с состоянием, которая иногда рассинхронизируется, и процесс на Mono/.NET, который любит ошибиться в оценке памяти на слабых VPS. Разберём установку, первое задание, хранение версий и — самое важное — реальное восстановление, а не только теорию про «бэкапы должны быть».

Что такое Duplicati и когда он оправдан

Duplicati — open-source инструмент резервного копирования с веб-интерфейсом, написанный на .NET. Ключевые особенности:

• Дедупликация и инкрементальные бэкапы — после первого полного прохода каждый следующий бэкап передаёт только изменённые блоки данных.
• Встроенное шифрование AES-256 — данные шифруются до отправки на хранилище, при желании можно переключиться на GPG.
• Десятки бэкендов из коробки — локальный диск, SFTP/SSH, FTP, WebDAV, Amazon S3, Backblaze B2, Google Drive, OneDrive, Azure Blob и другие — без танцев с rclone.
• Расписание и retention-политики через UI, без правки crontab.
• Уведомления по email или через HTTP-запрос при успехе/ошибке.

Стоит выбирать Duplicati, если: вы администрируете сервер не каждый день и хотите визуально видеть статус бэкапов; в команде есть люди, которым проще открыть страницу в браузере, чем зайти по SSH; бэкапите разнородные файловые данные (не одну БД), где полезен файловый браузер для точечного восстановления.

Не самый удачный выбор, если нужен максимальный перформанс на терабайтных объёмах (restic и borg обычно быстрее и экономнее по памяти), важна декларативная конфигурация в git (Duplicati хранит состояние в собственной SQLite-базе, а не в plain-текстовых конфигах), или сервер совсем слабый — Mono-процесс под нагрузкой ест заметно больше памяти, чем компактный Go-бинарник restic.

Сравнить подходы можно в статье про установку restic на VPS — тот же класс задач, но через CLI.

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

Проще всего поднять Duplicati образом от LinuxServer.io — он уже настроен на постоянный конфиг и типовые тома. Понадобится Docker и docker-compose на сервере.

# docker-compose.yml
services:
  duplicati:
    image: lscr.io/linuxserver/duplicati:latest
    container_name: duplicati
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Moscow
      # - CLI_ARGS= #optional, для доп. флагов Duplicati
      - SETTINGS_ENCRYPTION_KEY=замените-на-случайную-строку
    volumes:
      - ./config:/config
      - ./backups:/backups        # локальное хранилище назначения
      - /home:/source/home:ro     # что бэкапим — монтируем read-only
      - /etc:/source/etc:ro
    ports:
      - "127.0.0.1:8200:8200"
    restart: unless-stopped

Обратите внимание на порт: он проброшен только на 127.0.0.1, то есть снаружи веб-интерфейс недоступен напрямую — это осознанное решение, у Duplicati в базовой поставке нет надёжной защиты от брутфорса на уровне приложения. Доступ наружу дайте через SSH-туннель (ssh -L 8200:localhost:8200 user@server) или через reverse proxy с базовой авторизацией и TLS.

docker compose up -d
docker compose logs -f duplicati

После старта откройте http://localhost:8200 (через туннель) и сразу задайте пароль на вход — Settings → Options → «Require a password to access the user interface». Без этого шага любой, кто дотянется до порта, получает полный доступ к бэкапам и их удалению.

Настройка первого задания бэкапа через веб-интерфейс

Создание задания — мастер из нескольких шагов:

1. General — имя задания (например, home-backup) и способ шифрования: AES-256 (встроенный) с passphrase или GPG. Passphrase сохраните отдельно и надёжно — без него данные не восстановить даже локально, это не «забыл пароль от сайта».
2. Backend — куда складывать бэкап: локальная папка, SFTP, S3-совместимое хранилище и так далее (подробнее ниже).
3. Source Data — какие папки бэкапить. В контейнере это пути внутри /source/..., которые вы примонтировали в docker-compose. Можно исключить по маске (*.tmp, */node_modules/*, */cache/*).
4. Schedule — расписание: ежедневно/еженедельно/ежемесячно, время запуска, разрешить ли запуск, если предыдущий ещё не завершился.
5. Options — политика хранения версий, лимиты по размеру блока (--blocksize, по умолчанию 100 КБ — для больших файлов имеет смысл увеличить до 1 МБ), throttling по скорости, число одновременных потоков загрузки.

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

Куда складывать бэкапы: локально, S3, SFTP, Backblaze B2

Правило 3-2-1 никто не отменял: локальная копия бэкапа на том же диске, что и данные, спасает от случайного rm -rf, но не от отказа диска или сервера целиком. Duplicati поддерживает несколько типов назначений одновременно — можно завести два задания на разные бэкенды с одним источником.

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

Для SFTP-назначения в Duplicati backend выглядит так:

Storage Type: SFTP (SSH)
Server: 203.0.113.10
Port: 22
Path: /backups/duplicati
Username: backupuser
Authentication: Password / Client Certificate

Проверьте подключение кнопкой Test connection прямо в мастере — она честно покажет, доступен ли путь и хватает ли прав на запись, ещё до сохранения задания.

Расписание, версии и политика хранения (retention)

Без retention-политики бэкап будет расти бесконечно — каждая версия хранит уникальные блоки, и если файлы часто меняются, место кончится быстрее, чем кажется. В Options → Backup retention доступны варианты:

• Keep all backups — ничего не удаляется (годится только для коротких периодов или очень дешёвого хранилища).
• Smart backup retention — Duplicati сам прореживает версии: последние несколько хранятся все, дальше — по одной в день, потом по одной в неделю, потом по одной в месяц.
• Custom retention — явное правило вида 1W:1D,4W:1W,12M:1M (последнюю неделю — версия за каждый день, следующий месяц — раз в неделю, следующий год — раз в месяц).

# Пример custom retention для еженедельных полных архивов сайта
7D:1D,8W:1W,12M:1M

После смены политики не забывайте про Compact — операцию, которая физически освобождает место, удаляя блоки, на которые больше не ссылается ни одна оставшаяся версия. Duplicati делает это автоматически после каждого бэкапа, но на хранилищах с платой за запросы (некоторые S3-совместимые провайдеры) это заметная статья расходов — можно отключить автокомпакт (--no-auto-compact) и запускать его отдельно, раз в неделю.

Восстановление данных: из веб-интерфейса и Disaster Recovery

Восстановление — то, ради чего всё затевалось, и именно его стоит регулярно проверять на тестовых данных, а не верить, что «раз бэкап зелёный — всё ок».

Обычное восстановление (сервер и Duplicati живы):

1. Откройте задание → вкладка Restore.
2. Выберите версию по дате — файловый браузер покажет содержимое именно этого снапшота.
3. Отметьте файлы или папки целиком, выберите «Restore to original location» или «Restore to another location» (полезно, чтобы не перезаписать текущие файлы, а сравнить).
4. При конфликте имён Duplicati предложит перезаписать, пропустить или сохранить с суффиксом.

Disaster Recovery (сервер потерян, конфигурация Duplicati недоступна) — сценарий, который проверяют реже всего, а нужен именно тогда, когда всё остальное уже пошло не так:

1. На новом сервере поднимите пустой Duplicati (тем же docker-compose).
2. На экране логина есть ссылка Restore from backup files directly — не нужно сначала пересоздавать задание.
3. Укажите тип хранилища и параметры доступа к бэкапу (тот же S3/SFTP, где лежат данные).
4. Введите passphrase шифрования — без него дальше пути нет, поэтому его нужно хранить отдельно от бэкапируемого сервера (менеджер паролей, зашифрованный файл в другом месте).
5. Duplicati скачает служебные файлы (dlist, dindex), покажет список версий и даст восстановить нужные данные напрямую, даже не создавая полноценное задание.

Отдельно проверьте восстановление баз данных — частая причина «бэкап есть, а сервис не поднимается»: для СУБД нужен консистентный дамп (pg_dump/mysqldump) до передачи файла в Duplicati, а не бэкап сырых файлов на живую. Общие грабли при восстановлении БД разобраны в статье про восстановление базы данных из бэкапа на практике.

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

Бэкап, о падении которого никто не узнал, — это отсутствие бэкапа с задержкой. В Duplicati уведомления настраиваются в Settings → General:

send-mail-to = admin@example.com
send-mail-level = Fatal,Error,Warning
send-mail-smtp-server = smtp.example.com:587

Либо через HTTP-хук (send-http-url) на сервис вроде healthchecks.io, который поднимет тревогу, если бэкап не отчитался вовремя — принцип dead man's switch надёжнее, чем «письмо только при ошибке», потому что ловит и ситуацию, когда задание вообще перестало запускаться. Как это настроить в общем виде — в статье про мониторинг cron-задач через healthchecks.io.

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

• «Database is locked» — обычно из-за перезапуска контейнера во время бэкапа или параллельного запуска двух заданий с одной БД. Дождитесь завершения текущей операции или запустите Repair базы из UI.
• Рост потребления памяти на больших источниках — увеличьте --blocksize (меньше метаданных на блок) и ограничьте --asynchronous-concurrent-upload-limit.
• Зависание на «Verifying backend files» — по умолчанию Duplicati проверяет случайную выборку файлов на бэкенде при каждом запуске; на медленном SFTP это заметно. Настраивается через --backup-test-samples.

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