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

Привет! Меня зовут Евгений Сергеевич Семёнов, и я директор ITFresh. За 15 лет в профессии я чего только не насмотрелся: как серверы сгорали дотла, а шифровальщики в один миг стирали базы 1С у компаний с миллиардными оборотами. Помню, как 'надёжный' NAS падал вместе со всем офисом, который его арендовал! Любой опытный сисадмин подтвердит: единственная по-настоящему надёжная страховка — это независимая копия данных, которая хранится в облаке, и её никак невозможно удалить прямо из офиса. В этой статье я расскажу, как мы в ITFresh помогаем нашим клиентам в Москве по-настоящему спать спокойно, просто устанавливая им 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 как системную службу. Это не просто важно — это критически важно! Ведь без неё 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}"

Мы в ITFresh не доверяем случайностям. Специально для Duplicati у нас разработан отдельный шаблон в Zabbix. Что он делает? Шаблон проверяет дату последнего успешного запуска – данные берет прямо из сервисного лога. Мы также отслеживаем размер последнего бэкапа: если он вдруг упал в десять раз, система сразу бьет тревогу. А еще — процент дедупликации. Если этот показатель вдруг опускается ниже 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С на тестовый стенд. Без этого ваши бэкапы — иллюзия.