Duplicati на Ubuntu 24.04: пошаговая установка

MAATRIX

Настраивать бэкапы через cron и голые shell-скрипты удобно, если вы админ и не против лезть в терминал каждый раз, когда нужно проверить, дошла копия или нет. Но у команды из нескольких человек, у фрилансера с десятком клиентских серверов или у того, кто просто не хочет держать в голове синтаксис crontab, есть другой запрос: кликабельный интерфейс, где видно расписание, историю запусков и кнопку «восстановить». Duplicati закрывает именно эту нишу — open-source бэкап с веб-панелью, шифрованием из коробки и поддержкой десятков типов хранилищ. Ниже — пошаговая установка на Ubuntu 24.04, от systemd-сервиса до первого проверенного восстановления.

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

Duplicati — кроссплатформенный инструмент резервного копирования с открытым кодом, написанный на .NET. В отличие от restic или borg, с которыми работают почти исключительно через CLI, у Duplicati есть полноценный веб-интерфейс: создание заданий мастером из нескольких шагов, визуальное расписание, журнал каждого запуска с длительностью и объёмом переданных данных, кнопка восстановления с выбором версии файла на конкретную дату. Внутри он использует блочное дедуплицированное хранение (похоже на идею restic) — при повторных запусках передаются только изменившиеся блоки, а не файлы целиком, что экономит трафик и место на удалённом хранилище.

Инструмент разумно выбирать, если вам нужнее удобство контроля, чем максимальная скорость и минимальный оверхед. Duplicati написан на управляемом рантайме и заметно прожорливее по CPU и памяти на больших объёмах данных, чем restic или borg — это плата за GUI, инкрементальную индексацию и широкий список поддерживаемых хранилищ. Для сайта, десятка баз и пары VPS с суммарным объёмом в единицы-десятки гигабайт разница не критична; для сотен гигабайт и множества параллельных заданий стоит заранее прикинуть ресурсы сервера — ориентиры по CPU и RAM под такие задачи разобраны в статье сколько ресурсов нужно VPS для бэкапов и архива.

Устанавливаем Duplicati на Ubuntu 24.04

Официальный путь установки — deb-пакет с GitHub Releases проекта. Сначала обновите систему и поставьте зависимости:

sudo apt update && sudo apt upgrade -y
sudo apt install -y curl ca-certificates libicu74

Duplicati с версии 2.0.7 поставляется как self-contained сборка .NET, отдельный Mono не нужен. Дальше скачиваем последний доступный релиз для Linux x64 с GUI напрямую через GitHub API — так вы всегда получаете актуальную сборку, а не устаревшую ссылку из старого мануала:

DEB_URL=$(curl -s https://api.github.com/repos/duplicati/duplicati/releases/latest \
  | grep "browser_download_url.*linux-x64-gui.deb" \
  | cut -d '"' -f4)
curl -Lo duplicati.deb "$DEB_URL"
sudo apt install -y ./duplicati.deb

Команда apt install ./файл.deb сама подтянет недостающие зависимости из репозиториев Ubuntu — в отличие от dpkg -i, после которого пришлось бы вручную гонять apt --fix-broken install. Если на странице релизов ещё нет стабильной deb-сборки под текущую версию Ubuntu (проект периодически меняет схему именования файлов), зайдите на страницу github.com/duplicati/duplicati/releases и возьмите ссылку на актуальный *-linux-x64-gui.deb вручную.

После установки пакет сам регистрирует systemd-юнит и запускает сервис:

sudo systemctl enable --now duplicati.service
sudo systemctl status duplicati.service

В выводе status должно быть active (running). По умолчанию Duplicati слушает веб-интерфейс только на 127.0.0.1:8200 — снаружи сервера он недоступен, и это осознанное решение разработчиков: панель без пароля просто так наружу не выставляется.

Открываем веб-интерфейс и задаём пароль

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

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

Пока терминал с этой командой открыт, интерфейс доступен в браузере по адресу http://127.0.0.1:8200. При первом входе Duplicati почти наверняка покажет предупреждение: интерфейс не защищён паролем, и если открыть его наружу как есть — любой сможет управлять вашими бэкапами и хранилищами. Сразу зайдите в Settings → Options → General и задайте пароль входа (Set a password для доступа к панели). Без этого шага дальше двигаться не стоит, даже если панель у вас «только для себя» — сервер может быть скомпрометирован по другим причинам, и открытый бэкап-интерфейс станет лишней дырой.

Если хотите заходить в панель постоянно без туннеля — например, с телефона или с чужого компьютера — вынесите её через reverse proxy с TLS и базовой аутентификацией, а не открывайте порт 8200 напрямую в интернет. Как поднять Caddy с автоматическим SSL под такую задачу, описано в статье Caddy с авто-SSL на Ubuntu 24.04. Порт 8200 при этом держите закрытым файрволом для всех, кроме localhost и вашего reverse proxy.

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

В панели нажмите Add backup → Configure a new backup и пройдите мастер из пяти шагов:

1. General — имя задания (например, «Сайт и база — ежедневно») и парольная фраза шифрования. Duplicati по умолчанию шифрует каждый бэкап AES-256 средствами SharpAESCrypt, встроенными в саму программу — внешний GPG не обязателен, хотя доступен опционально.
2. Destination — куда складывать копии. Список бэкендов у Duplicati один из самых широких в классе: локальная папка или примонтированный сетевой диск, SFTP, S3-совместимое хранилище (в том числе self-hosted MinIO), WebDAV, FTP, Backblaze B2, Google Drive и ещё несколько десятков вариантов. Для сервера продакшена разумно указать SFTP на отдельный VPS — тогда копия физически лежит на другой машине, а не рядом с оригиналом.
3. Source Data — какие папки бэкапить. Для типового сервера это /var/www (файлы приложений) и /etc (конфигурация служб); дампы баз данных кладите заранее в отдельную папку, например /backup/db, а Duplicati уже заберёт её как источник.
4. Schedule — частота и время запуска. Для сайта достаточно раза в сутки в ночное время, для активной базы данных — чаще.
5. Options — политика хранения версий (retention). Здесь задаётся, сколько старых копий держать: либо готовый профиль Smart backup retention (последние копии — часто, старые — реже), либо своя формула вида 1W:1D,4W:1W,6M:1M — читается как «первую неделю храним снимок за каждый день, следующий месяц — раз в неделю, дальше полгода — раз в месяц».

После сохранения запустите задание вручную кнопкой Run now и дождитесь первого полного прохода — он самый долгий, потому что передаёт весь объём данных и строит локальный индекс блоков. Последующие запуски будут заметно быстрее: Duplicati передаёт только изменившиеся блоки.

Шифрование и выбор хранилища

Парольная фраза шифрования, заданная на шаге General, — единственный ключ ко всем вашим данным в этом бэкапе. Duplicati не хранит её нигде, кроме локальной базы конфигурации на сервере, и не имеет механизма восстановления забытого пароля. Потеряли фразу — потеряли доступ к архивам, даже если файлы физически целы на удалённом хранилище. Запишите её в менеджер паролей отдельно от самого сервера: если фраза лежит только на диске, который вы бэкапите, при полной утрате сервера восстанавливать будет нечем. Общие принципы шифрованных бэкапов и типичные ошибки с ключами разобраны в статье бэкап с шифрованием на сервере: частые ошибки и решения.

По выбору хранилища есть практическое правило: держите копию не на том же физическом сервере, что и оригинал. SFTP на второй VPS — самый предсказуемый вариант для тех, кто уже привык к Linux-серверам: не нужны внешние API-ключи облачных провайдеров, трафик идёт по SSH, а тарификация хранилища понятна заранее. Если подбираете такой сервер под бэкапы, ориентиры по объёму диска и характеристикам под разный масштаб есть в статье VPS для бэкапов и архива: что выбрать и как настроить.

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

Проверенный бэкап — только тот, который хотя бы раз развернули обратно. В Duplicati это делается без командной строки: откройте задание, нажмите Restore, выберите точку во времени (доступны все версии, за которые сохранились снимки в рамках вашей retention-политики), затем — конкретные файлы или папки целиком. Есть выбор: восстановить поверх исходного пути или в отдельную временную директорию — второй вариант безопаснее для проверки, чтобы случайно не затереть текущие файлы.

Для больших объёмов или скриптового восстановления (например, при разворачивании нового сервера) доступна CLI-версия — duplicati-cli restore <backend-url> --restore-path=/путь, использующая ту же конфигурацию и тот же пароль шифрования. Если бэкапите базу данных отдельным дампом (что обычно и правильно — см. предыдущий раздел про источники), после восстановления файла дампа его ещё нужно накатить в СУБД штатной командой импорта — Duplicati возвращает вам исходный файл, а не сам разворачивает его в работающую базу.

Автоматизация, уведомления и типичные проблемы

Расписание в веб-интерфейсе — это встроенный планировщик самого Duplicati, отдельный cron под него заводить не нужно: сервис работает как systemd-демон и сам просыпается по расписанию задания, даже если панель в браузере закрыта. Чтобы не проверять статус бэкапов руками, настройте уведомления в Settings → Send-report options — Duplicati умеет слать отчёт о результате на email или дёргать произвольный webhook при успехе, ошибке или обоих случаях сразу. Для внешнего контроля «бэкап вообще жив» полезно завести дополнительный сторожевой пинг через сервис мониторинга cron-подобных задач — тогда вы узнаете о молчащем задании даже если сам email с отчётом потеряется.

Из типичных проблем стоит знать заранее о нескольких:

• «Found N remote files that are not recorded in local database» — локальный индекс разошёлся с содержимым хранилища (например, после ручного вмешательства в файлы на SFTP). Лечится кнопкой Repair — Duplicati перечитает список файлов на бэкенде и синхронизирует локальную базу.
• Первый запуск «зависает» на «Verifying backend data» — это не зависание, а проверка целостности только что загруженных данных; на медленном канале первый проход идёт заметно дольше последующих.
• Компактификация грузит CPU — периодически Duplicati переупаковывает старые блоки данных (compact), чтобы не плодить мелкие файлы на бэкенде; на слабом VPS это даёт кратковременные скачки нагрузки, обычно ночью вместе с самим бэкапом.
• SFTP-хранилище недоступно — проверьте, что исходящие соединения на порт SSH второго сервера не блокируются файрволом, и что при первом подключении вы приняли отпечаток ключа хоста кнопкой Test connection на шаге Destination.

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