Сколько RAM нужно для Duplicati

MAATRIX

Duplicati в диспетчере задач выглядит безобидно: процесс висит на паре сотен мегабайт и почти не шевелится, веб-интерфейс на порту 8200 открывается мгновенно. А потом по расписанию стартует ночной backup файлового сервера с сотнями тысяч файлов — и память улетает за пределы тарифа, интерфейс перестаёт отвечать, а утром вместо готового архива вас ждёт зависший или прерванный job. У Duplicati, в отличие от большинства backup-утилит, нет одной цифры "минимум RAM": есть тихий простой и резкие пики на конкретных операциях. Разберём, откуда берётся расход и сколько закладывать под свой объём данных.

Короткий ответ: сколько RAM нужно для Duplicati

Официального минимума проект не публикует — в отличие, скажем, от СУБД или Gitea, у которых в документации есть конкретная цифра. Ориентиры ниже собраны из практики эксплуатации и обсуждений на форуме и GitHub проекта, поэтому считайте их отправной точкой, а не гарантией: у вас цифры сдвинутся в зависимости от числа файлов и настроек.

Как и у любого backup-инструмента, у Duplicati надо закладывать не одну цифру, а две. Фон — веб-сервер, планировщик, ожидание следующего запуска — держится в сотнях мегабайт и растёт медленно. Пик — сама операция backup, а ещё сильнее compact и восстановление базы после сбоя — может в разы превышать фон и длиться от минут до часов на большом объёме. Тариф считайте по пику, а не по тому, что free -h показывает в простое.

Из чего складывается расход: веб-сервер, SQLite и рантайм

Duplicati написан на C#: исторически ветка для Linux работала через Mono, актуальные сборки постепенно переходят на .NET — детали зависят от конкретного релиза, но принцип тот же: управляемая среда с собственным сборщиком мусора поверх процесса, а не голый бинарник. В простое, без активных job, сам процесс обычно укладывается в 150-250 МБ — это ориентир, у вас может отличаться в зависимости от версии и числа настроенных задач.

Веб-интерфейс (по умолчанию порт 8200, меняется флагом --webservice-port) сам по себе лёгкий, но держит открытое соединение для живого статуса job — если открыть вкладку и забыть, лишних мегабайт это не добавит, а вот десяток одновременных клиентов на слабом сервере уже заметны.

Основной несущий элемент — база SQLite, отдельная на каждый job. По умолчанию она лежит в ~/.config/Duplicati/<hash>.sqlite для пользователя, от имени которого запущен сервис (часто root, если ставили как systemd-юнит), либо в /config внутри Docker-образа. Путь к конкретной базе видно в веб-интерфейсе на странице job → Database. Там же есть кнопка Recreate — к ней вернёмся ниже, потому что это самая тяжёлая операция из всех.

# где искать базы на native-установке
ls -la ~/.config/Duplicati/*.sqlite

# сколько весит база конкретного job
du -h ~/.config/Duplicati/*.sqlite

База хранит список файлов, блоков и версий бэкапа — на архиве из миллионов файлов и десятков версий она вырастает до сотен мегабайт и больше на диске, а часть этого объёма Duplicati подгружает в память при построении плана backup и при compact.

Backup: почему память растёт вместе с числом файлов, а не с объёмом

Здесь главная ловушка: тариф выбирают по гигабайтам источника, а память у Duplicati в первую очередь реагирует на количество файлов и блоков, а не на суммарный объём. Duplicati режет каждый файл на блоки фиксированного размера — по умолчанию --blocksize=100kb — и хэширует их для дедупликации. Чем мельче блок, тем точнее дедупликация, но тем больше блоков нужно отследить одновременно: бэкап с миллионом мелких файлов (логи, кэш почты, node_modules) создаёт на порядки больше рабочих объектов, чем бэкап той же ёмкости из десятка видеофайлов.

Обработку блоков распараллеливают воркеры: --concurrency-block-hashers (по умолчанию 2) считают хэши, --concurrency-compressors (по умолчанию 2) сжимают перед отправкой. Каждый воркер держит буфер под текущий блок — при --blocksize=100kb это несущественно, но реальный источник пиков не сами буферы, а внутренние структуры для отслеживания состояния миллионов файлов и блоков за один проход сканирования.

Типичная картина на 1 ГБ VPS при первом полном backup крупного источника:

sudo dmesg -T | grep -i "killed process"
[Thu Aug 27 03:14:02 2026] Out of memory: Killed process 8842 (Duplicati.Server)

Убивают не веб-интерфейс, а именно процесс во время построения списка изменений. Лечится это не наращиванием concurrency-параметров вниз (хотя и это помогает на CPU), а увеличением blocksize для крупных источников:

--blocksize=1mb

Важный нюанс, о котором часто забывают: blocksize задаётся при создании job и не меняется задним числом — если увеличить его на уже существующем бэкапе, Duplicati фактически начнёт новую цепочку версий с нуля, потому что старые блоки нарезаны иначе. Поэтому размер блока стоит продумать заранее: для источников свыше 100-200 ГБ разумно сразу ставить 1 МБ и выше, а не оставлять дефолтные 100 КБ, рассчитанные на небольшие бэкапы.

Compact, verify и recreate — самые тяжёлые операции

Три сценария потребляют заметно больше памяти, чем обычный инкрементальный backup.

Compact. После того как ретеншен (--keep-versions или --retention-policy) удаляет старые версии, в удалённых dblock-файлах остаются "дыры" — данные, которые больше не нужны, но всё ещё занимают место. Когда доля такого мусора превышает порог (--threshold, по умолчанию 25%), Duplicati запускает compact: скачивает частично устаревшие dblock-файлы, перепаковывает их без удалённых данных и заливает обратно. На большом архиве это скачивание и репак десятков файлов сразу — заметный всплеск по памяти и трафику. Чтобы контролировать момент, а не ловить пик посреди рабочего дня:

--no-auto-compact=true

Тогда compact запускается только вручную, из веб-интерфейса или по отдельному расписанию в тихое окно.

Verify. После каждого backup Duplicati по умолчанию скачивает и проверяет случайную выборку удалённых файлов (--backup-test-samples, по умолчанию 1). Это не главный источник расхода, но при --full-remote-verification проверка становится глубже и требует индекс всего архива — на слабом сервере лучше не включать эту опцию без необходимости.

Recreate / Repair. Худший случай: локальная SQLite-база потеряна или повреждена — и Duplicati собирает её заново из того, что лежит на удалённом хранилище. В веб-интерфейсе это кнопка Database → Recreate. Процесс скачивает и обрабатывает все dlist- и dindex-файлы за всю историю job — на архиве с многолетней историей это часы, а не минуты, и нагрузка на память и диск заметно выше обычного backup. Реальная страховка — не рассчитывать, что recreate пройдёт быстро: держите резервную копию самой SQLite-базы (периодический cp в отдельное хранилище) или используйте кнопку Export в настройках job.

Как снизить расход и не упереться в тариф

Если сервер уже куплен и апгрейд откладывается, порядок действий такой:

• Поднимите blocksize для крупных источников — как описано выше, это снижает число блоков в разы и напрямую бьёт по памяти при сканировании и по размеру самой SQLite-базы.
• Разнесите job по расписанию. Если один сервер принимает бэкапы нескольких машин, не запускайте их одновременно (cron 0 2 * * * для всех job — плохая идея): каждый параллельный backup — это отдельный поток сканирования и своя нагрузка на базу. Разведите старты на 30-60 минут.
• Снизьте concurrency на слабом CPU/RAM: --concurrency-block-hashers=1 --concurrency-compressors=1 уменьшает пиковое потребление ценой скорости — на 1-2 ГБ VPS это разумный компромисс.
• Отложите compact флагом --no-auto-compact=true и запускайте его вручную по ночам, когда никто не ждёт готовый backup.
• В Docker ограничивайте контейнер осмысленно: --memory=1g --memory-swap=1g даст predictable OOM с перезапуском вместо того, чтобы утащить соседние контейнеры. Если лимит занижен и job падает регулярно — это сигнал повысить тариф, а не симптом, который лечится ещё одним ограничением.
• Своп на 1-2 ГБ как страховка от разового пика на compact или recreate: fallocate -l 2G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile, строка в /etc/fstab и vm.swappiness=10. NVMe медленнее памяти в разы — своп переживёт единичный всплеск, но не системную нехватку RAM на постоянной основе.

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

Как измерить своё потребление и не гадать

Общие цифры — только отправная точка, реальная нагрузка зависит от вашего набора файлов. Проверяйте так:

# общая картина по памяти и page cache
free -h

# сколько ест процесс Duplicati прямо сейчас
ps aux | grep -i duplicati

# если развёрнуто в Docker — живая статистика контейнера
docker stats duplicati

# для native-установки через systemd
cat /sys/fs/cgroup/system.slice/duplicati.service/memory.peak
journalctl -u duplicati --since yesterday | grep -iE "oom|exception"

# следы OOM killer в ядре
sudo dmesg -T | grep -i "killed process"

Отдельно загляните в собственный лог Duplicati — веб-интерфейс → About → Show log → уровень Verbose. Там System.OutOfMemoryException или обрыв job на этапе "Uploading files" честно покажет, где закончилась память, в отличие от системных логов, которые фиксируют только факт убийства процесса.

Практический порядок: разверните job на разумном стартовом тарифе, дайте отработать полный цикл backup и хотя бы один compact, снимите пиковое потребление за неделю и добавьте 20% запаса — это и есть ваша цифра. Для одного-двух источников до сотни гигабайт обычно достаточно 1-2 ГБ RAM; для сервера, принимающего бэкапы нескольких машин или считающего файлы миллионами, берите от 4 ГБ и NVMe с запасом под локальные базы и временные файлы (путь задаётся --tempdir, по умолчанию системный /tmp). Если бэкап уходит в S3-совместимое хранилище на соседнем сервере, заодно прикиньте память под него — например, в статье сколько RAM нужно для MinIO. Для оценки диска и сети под саму роль backup-сервера пригодится расчёт ресурсов VPS под бэкапы и архив.

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