Duplicati в офисе: бэкап в облако без боли и сюрпризов

Меня зовут Семёнов Евгений Сергеевич, я директор АйТи Фреш. За 15 лет я видел, как сгорали серверы, как шифровальщики уносили в небытие базы 1С компаниям с миллиардными оборотами, как «надёжный» NAS падал вместе с офисом, который его арендовал. Любой опытный сисадмин скажет: единственная страховка — независимая копия данных в облаке, которую нельзя удалить из офиса. Эта статья — про то, как мы в АйТи Фреш ставим Duplicati клиентам в Москве, чтобы по-настоящему спать спокойно.

Почему Duplicati, а не Veeam, Acronis или robocopy в облако

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

• Образы виртуальных машин и физических серверов целиком. Здесь правит Veeam Agent или Veeam B&R, и Duplicati тут проигрывает.
• Пофайловое резервирование с дедупликацией и историей версий. Это сценарий «у нас 4 ТБ файлового сервера, нужно бэкапить каждую ночь и держать 90 дней истории». Здесь Duplicati — лидер по соотношению цена/качество.
• Бэкапы баз данных (1С, PostgreSQL, MS SQL). Здесь Duplicati работает в связке с штатными утилитами выгрузки — сначала pg_dump или dt-выгрузка, потом загрузка дампа в облако через Duplicati.

В Москве 80 % моих клиентов — это офисы с файловым сервером и базой 1С. Для них Duplicati закрывает 70 % задач бэкапа. Под образ системы я ставлю Veeam Agent (бесплатной редакции хватает), а вот всё, что касается файлов, документов, конфигов и дампов — это задача Duplicati.

Что мне нравится в Duplicati после трёх лет промышленной эксплуатации:

• Полностью бесплатный, без лицензионных ограничений на количество клиентов и объём.
• Работает с любым S3-совместимым облаком (Yandex, Selectel, VK Cloud, MinIO, Wasabi, Backblaze B2) — нет привязки к одному вендору.
• Шифрование AES-256 на стороне клиента — облако никогда не видит ваши данные в открытом виде.
• Дедупликация на уровне блоков — файл 1 ГБ, изменённый на 1 МБ, добавит к бэкапу ~2 МБ, а не гигабайт.
• Веб-интерфейс на порту 8200, никаких толстых клиентов.
• Кроссплатформенность — один инструмент для Windows-серверов, Linux-серверов и MacBook директора.

Архитектура, которую я ставлю клиентам

Когда я приходу в новый офис, прежде чем что-то ставить, я рисую на листочке схему «откуда — куда — как часто — с какой глубиной хранения». Без этого получается «бэкапим всё в одно место раз в неделю» — а потом шифровальщик за 12 часов сжирает и оригиналы, и бэкап, и облачные синхронизации (если они инкрементальные синхронные, как Я.Диск или Dropbox).

Стандартная схема для офиса 20–50 рабочих мест с одним сервером 1С:

Главный принцип здесь — правило 3-2-1: три копии данных (оригинал + локальный бэкап + облако), на двух разных типах носителей (диск + объектное хранилище), одна копия — географически удалённая. У меня сейчас 8 клиентов с двумя облаками: Yandex Object Storage как основной, Selectel S3 как второй. Если что-то случится с одним провайдером (а в апреле 2025 года Yandex Cloud лежал 6 часов — клиенты с одной копией просто не могли восстановиться), всегда есть запасной канал.

Установка Duplicati на Windows-сервер

В офисах с Windows Server 2019/2022 ставлю Duplicati как системную службу. Это критично — без службы он работает в сессии пользователя, и если RDP-сессия закрылась, бэкапы остановились.

# PowerShell от Administrator
# Скачиваем последний релиз с github.com/duplicati/duplicati/releases
# Берём duplicati-2.0.8.x_stable_2024-XX-XX-x64.msi

msiexec /i Duplicati-2.0.8.x.msi /qb

# Включаем как службу с автостартом
sc.exe create Duplicati binPath= "\"C:\Program Files\Duplicati 2\Duplicati.WindowsService.exe\"" start= auto displayname= "Duplicati Service"
sc.exe start Duplicati

# Веб-интерфейс будет на http://localhost:8200
# Сразу ставим пароль доступа в Settings → UI password

На Linux-серверах (а у меня большинство файловых серверов и почтовиков клиентов на Debian/Ubuntu) — пакеты из репозитория:

# Debian 12 / Ubuntu 24.04
wget https://updates.duplicati.com/stable/duplicati_2.0.8.1-1_all.deb
sudo apt install ./duplicati_2.0.8.1-1_all.deb

# Запускаем как сервис
sudo systemctl enable --now duplicati.service

# Доступ к UI через SSH-туннель — наружу 8200 не открываем!
# ssh -L 8200:localhost:8200 user@server-ip

Настройка задания: пошагово, как для своего

Дальше в веб-интерфейсе создаём задание. Я разберу на примере бэкапа файлового сервера в Yandex Object Storage — самого частого сценария:

1. Source data. Выбираем папки. Для файлового сервера — обычно D:\Shares или /srv/shares. Исключаем мусор: *.tmp, ~$*.docx, Thumbs.db, .DS_Store, директории профилей AppData\Local\Temp.
2. Destination. Выбираем «S3 Compatible», указываем endpoint https://storage.yandexcloud.net, бакет backup-clientname, регион ru-central1, AccessKey/SecretKey из сервисного аккаунта Yandex Cloud.
3. Encryption. Включаем AES-256. Пароль генерирую длиной не менее 32 символа через openssl rand -base64 32. Этот пароль сохраняю в трёх местах: KeePass у клиента, KeePass у меня в АйТи Фреш, и распечатанный лист в сейфе у директора. Без пароля бэкап — это бесполезный мусор.
4. Schedule. Ежедневно 02:00, на случай пропуска — повтор через 6 часов. Чтобы не положить интернет в офисе, ставлю throttle upload до 80 % от ширины канала.
5. Retention. Smart backup retention: keep all backups within 7 days, then keep one per day for 30 days, then one per week for 12 weeks, then one per month for 12 months. Итого 14 версий в году — оптимально по соотношению объём/глубина.
6. Notifications. Email-нотификация на admin@itfresh.ru + я допиливаю через скрипт после задания пинг в Telegram.

Восстановление: репетируйте, иначе бэкап не работает

Главная истина после 15 лет в IT — бэкап без проверенного восстановления не существует. У меня регламент: раз в квартал по каждому клиенту я заходу в Duplicati, выбираю случайный файл из бэкапа недельной давности и восстанавливаю его в тестовый каталог. Раз в полгода — полное восстановление дампа 1С на тестовый сервер с подключением к платформе.

В Duplicati есть три сценария восстановления:

• Restore files. Через веб-интерфейс — выбираете дату, дерево файлов, нажимаете restore. Подходит для «бухгалтер удалила файл, нужно вернуть».
• Restore с другого сервера. Через «Direct restore from backup files» — указываете URL бакета, ключи, пароль шифрования. Так я восстанавливаю клиенту, у которого сгорел исходный сервер. Нужны только ключи S3 и пароль шифрования — больше ничего из старого офиса не требуется.
• CLI-восстановление. duplicati-cli restore "s3://..." --restore-path=/restore --passphrase=... — для сценариев автоматизации и массового восстановления через скрипт.

Был у меня кейс в феврале 2025 — у клиента сгорел RAID-контроллер на сервере 1С, базу подняли с Duplicati за 4 часа: 40 минут на загрузку 12 ГБ дампа из Yandex Object Storage, час на восстановление в платформе, час на проверку остатков и закрытий. Если бы не было Duplicati — клиент потерял бы день работы 18 человек, а это 80–100 тыс. руб. упущенной выручки.

Мониторинг: чтобы узнавать о провалах раньше клиента

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

Простой скрипт-обёртка, который я ставлю на каждое задание Duplicati. Срабатывает в run-script-after, проверяет ParsedResult и пишет в Telegram:

#!/bin/bash
# /etc/duplicati/notify.sh
TG_TOKEN="123456:ABC..."
TG_CHAT="-1001234567890"
HOST=$(hostname)
JOB="$DUPLICATI__OPERATIONNAME"
RESULT="$DUPLICATI__PARSED_RESULT"

if [ "$RESULT" = "Success" ]; then
  STATUS="OK"
  SIZE=$(echo "$DUPLICATI__BACKUP_SIZE" | numfmt --to=iec)
  MSG="Duplicati [${HOST}] ${JOB}: ${STATUS}, размер ${SIZE}"
else
  STATUS="FAIL"
  MSG="Duplicati [${HOST}] ${JOB}: ${STATUS} — ${DUPLICATI__PARSED_MESSAGE}"
fi

curl -s -X POST "https://api.telegram.org/bot${TG_TOKEN}/sendMessage" \
  -d chat_id="${TG_CHAT}" -d text="${MSG}"

В Zabbix у нас отдельный шаблон Duplicati: проверяет дату последнего успешного запуска через сервисный лог, размер последнего бэкапа (если внезапно упал в 10 раз — алерт), процент дедупликации (если упал ниже 50 % — что-то странное в данных), количество предупреждений в логе.

Грабли, на которые наступали я и мои клиенты

Список того, что не описано в документации Duplicati, но болит в продакшене:

• Пароль шифрования = смерть бэкапа. Потеряли пароль — потеряли все бэкапы, восстановление невозможно. Я лично теряю клиентам после установки распечатку с паролями в трёх копиях, плюс храню в Bitwarden Premium с двухфакторкой.
• Slow first backup. Первый полный бэкап 4 ТБ в облако через канал 100 Мбит/с уезжает 4–5 суток. Я делаю первичный бэкап локально на USB-диск, подключённый к серверу, потом физически переношу диск в офис и запускаю переключение бэкапа на S3 — Duplicati докачает только новые блоки.
• Compact фрагментирует. После года работы база метаданных (sqlite) Duplicati может разрастись до 5–10 ГБ. Раз в квартал делаю REINDEX через CLI, чтобы скорость не деградировала.
• S3 lifecycle policies. Если в Yandex Object Storage включено «удалять объекты старше 30 дней», вы потеряете глубокие бэкапы. Я отключаю lifecycle на бакете Duplicati — ротацию делает сам Duplicati по retention policy.
• VSS-квоты на Windows. Без расширения квоты теневых копий до 30 % бэкап Outlook PST-файлов и баз 1С падает с ошибкой «Object replaced by writer in flight».
• Multipart upload и большие файлы. Файл 50+ ГБ нужно разрезать через chunk size в Duplicati (обычно 50–100 МБ) — иначе при разрыве сети начнётся загрузка с нуля.

FAQ — что чаще всего спрашивают по бэкапам

В какое облако безопасно складывать бэкапы из России в 2026 году?

С учётом санкций и блокировок мы рекомендуем Yandex Object Storage, Selectel S3 и VK Cloud. Для гибридной схемы — собственный MinIO во второй локации. Зарубежные сервисы (B2, Wasabi) работают, но требуют резервного канала.

Стоит ли шифровать бэкапы, если облако и так шифрует диски?

Обязательно. Шифрование на стороне клиента (AES-256) защищает не только от утечки в облаке, но и от компрометации учётных данных самого облачного аккаунта. Без него любой, кто получит S3-ключ, скачает все ваши данные.

Чем Duplicati лучше Veeam Agent или Acronis?

Бесплатный, кроссплатформенный (Windows, Linux, macOS), работает с любым S3-совместимым облаком. Veeam и Acronis удобнее для образов системы, Duplicati — для пофайловых бэкапов с дедупликацией.

Сколько стоит развернуть в офисе?

В АйТи Фреш базовая установка Duplicati на сервер с настройкой расписания, шифрования, мониторинга и тестового восстановления — 18 000–28 000 руб. Дополнительный сервер +6 000 руб.

Как часто проверять восстановление?

Минимум раз в квартал — полное тестовое восстановление произвольного файла из бэкапа недельной давности. Раз в полгода — восстановление образа базы 1С на тестовый стенд. Без этого ваши бэкапы — иллюзия.