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

MAATRIX

Duplicacy рекламируют как лёгкий инструмент бэкапа — кросс-платформенный, с дедупликацией на уровне chunks и без блокировок репозитория. На практике это правда лишь наполовину: сам движок действительно экономен, но реальный расход памяти сильно зависит от того, сколько потоков вы указали флагом -threads, каким чанком режете данные при инициализации и сколько файлов лежит под бэкапом. Разберём, из чего складывается RAM-профиль Duplicacy, и подберём цифру, которая не подведёт на боевом сервере.

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

Точной универсальной цифры нет — Duplicacy официально не публикует требования к памяти, только рекомендует «достаточно оперативки для вашего объёма данных». Ниже — ориентир по архитектуре инструмента и типичным сценариям, не измеренный бенчмарк:

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

Почему Duplicacy архитектурно экономнее многих аналогов

Ключевая особенность Duplicacy — lock-free дедупликация. В отличие от restic или BorgBackup, которые держат в репозитории общий индекс и требуют аккуратной синхронизации доступа (обычно один активный writer на репозиторий, иначе риск гонки при prune), Duplicacy вычисляет ID каждого чанка детерминированно — по хешу содержимого — и не нуждается в централизованном списке "что уже есть", который нужно целиком тянуть в память перед началом работы.

Это даёт два практических следствия:

• Несколько машин могут бэкапиться в одно хранилище одновременно без файла-блокировки — Duplicacy справляется с конфликтами через двухшаговый сбор "fossil" при prune, а не через lock. Полезно, если вы бэкапите несколько VPS в один S3/B2-бакет.
• Backup не грузит в память индекс всего репозитория, как это делает restic. Duplicacy работает потоково: читает файл, режет на чанки скользящим окном (rolling hash, похоже на подход restic и Borg), для каждого чанка считает хеш, сравнивает с локальным кэшем ранее увиденных чанков и либо пропускает (дубликат), либо шифрует и заливает.

Именно поэтому duplicacy backup на сервере с 1-2 ГБ RAM обычно не создаёт проблем — узкое место возникает не от объёма данных под бэкапом, а от числа параллельных потоков и количества файлов в дереве.

Threads: главный рычаг потребления памяти

Флаг -threads — то, что реальнее всего двигает RAM вверх или вниз. Каждый поток Duplicacy держит в памяти буфер под чанк, который сейчас обрабатывает: читает данные из файла, режет на chunk, сжимает, шифрует и параллельно заливает в хранилище. Пока чанк "в полёте" — под него занята память, причём на нескольких стадиях конвейера может существовать одновременно несколько копий (сырые данные → сжатые → зашифрованные).

# один поток — минимальный расход памяти, медленнее на быстром канале
duplicacy backup -threads 1

# несколько потоков — быстрее заливка, но каждый держит свой буфер чанка
duplicacy backup -threads 8

Грубая прикидка: если средний чанк — 4 МБ (значение по умолчанию), а на каждом потоке в моменте может лежать 2-3 копии чанка на разных стадиях конвейера, то один поток — это условно 10-15 МБ рабочей памяти сверх базового потребления процесса (обычно десятки МБ на сам Duplicacy). При -threads 8 это уже может доходить до 100-150 МБ только под чанковые буферы, плюс базовые накладные расходы Go-рантайма (сборщик мусора Go резервирует память с запасом, реальный RSS обычно выше "теоретического" расчёта).

Практический вывод: не ставьте -threads "с запасом на будущее" на маленьком VPS. Если канал до хранилища и так не узкое место (например, локальный SFTP в том же дата-центре), 2-4 потока обычно достаточно и почти не заметны по памяти. Загонять 16-32 потока имеет смысл только на сервере с большим количеством RAM и быстрым каналом до S3/B2.

Средний размер чанка: цена настройки при `duplicacy init`

Размер чанка задаётся один раз при инициализации репозитория и потом не меняется без пересоздания хранилища:

# средний чанк 4 МБ (по умолчанию) — баланс между дедупликацией и накладными расходами
duplicacy init -c 4M repo_id /path/to/storage

# крупный чанк 16 МБ — меньше метаданных и меньше нагрузка на RAM/CPU,
# но хуже дедупликация: изменение одного байта в файле "портит" больший кусок
duplicacy init -c 16M repo_id /path/to/storage

# мелкий чанк 1 МБ — точнее дедупликация (полезно для баз данных, VM-образов),
# но больше чанков, больше метаданных, выше расход памяти на буферы и кэш
duplicacy init -c 1M repo_id /path/to/storage

По умолчанию Duplicacy держит границы чанка в диапазоне примерно от четверти до четырёх от заданного среднего размера — то есть при -c 4M реальные чанки колеблются грубо между 1 и 16 МБ. Это значит, что при большом среднем размере пиковый буфер на поток может быть заметно больше среднего — учитывайте это при расчёте -threads вместе с -c.

Практическое правило: для типового веб-проекта (код, статика, редко изменяемые файлы) значение по умолчанию 4M — разумный компромисс. Для бэкапа образов виртуальных машин или больших дампов баз, где меняется небольшая часть большого файла, имеет смысл уменьшать средний размер чанка — так дедупликация будет точнее и объём хранилища меньше, но ценой немного большего расхода RAM на метаданные и буферы.

Локальный кэш чанков и метаданные снапшота

У Duplicacy есть локальный кэш в каталоге .duplicacy/cache — там хранятся уже загруженные или проверенные чанки и метаданные снапшотов, чтобы не ходить в удалённое хранилище повторно. Этот кэш в основном живёт на диске, а не в оперативной памяти, но при построении дерева снапшота (duplicacy backup, duplicacy list, duplicacy check) Duplicacy держит в памяти список файлов текущего дерева — путь, размер, атрибуты, список ID чанков файла.

Для большинства проектов это несущественно: список из десятков-сотен тысяч файлов — это единицы-десятки МБ памяти. Проблема начинает ощущаться на деревьях с миллионами файлов (например, каталоги с логами, кэшем npm/pip, почтовые ящики Maildir) — там сама структура дерева в памяти может стать заметной статьёй расхода ещё до учёта чанковых буферов.

Если у вас именно такой случай, два рабочих способа снизить нагрузку:

• Исключить лишнее через .duplicacy/filters — не бэкапить кэши сборки, node_modules, временные файлы. Это снижает не только объём хранилища, но и размер дерева снапшота в памяти.
• Разнести один большой каталог на несколько отдельных репозиториев (duplicacy init в разных подпапках) — тогда каждый backup работает с меньшим деревом файлов за раз.

Команды check и prune -exhaustive дополнительно запрашивают у хранилища список всех существующих чанков — на репозитории с многолетней историей и множеством ревизий список может вырасти до сотен тысяч записей, но сами записи компактны (ID чанка — это хеш, не путь к файлу), так что по памяти это обычно легче, чем полный индекс блобов у restic на сопоставимом объёме данных.

Duplicacy Web GUI: сколько добавляет память сверху CLI

Бесплатный Duplicacy — это CLI-бинарник, который завершает работу после каждой операции и не держит фоновый процесс. Платная Duplicacy Web Edition — это постоянно работающий демон с планировщиком, веб-интерфейсом и локальной базой для хранения настроек задач. Она добавляет к расходу CLI-операций свою базовую нагрузку:

• фоновый веб-сервер и планировщик — держится в памяти постоянно, даже когда бэкапы не запущены;
• при запуске задачи Web GUI фактически вызывает тот же CLI-движок под капотом, так что пик памяти во время самого backup/check складывается по тем же правилам threads/chunk size, что описаны выше;
• если запускаете несколько задач параллельно (разные репозитории по расписанию), считайте память по формуле "база GUI + сумма пиков всех одновременно идущих заданий", а не по одному максимальному.

Если сервер выполняет только бэкап и больше ничего, разница между CLI и Web GUI по базовому потреблению обычно не критична для VPS от 1 ГБ. Но если на той же машине крутится сам сервис, который вы бэкапите (веб-приложение, база данных), закладывайте память отдельно и не полагайтесь на "усреднённую" загрузку — пик backup и пик нагрузки от приложения могут совпасть по времени (ночное окно бэкапа часто пересекается с фоновыми задачами cron).

Для расчёта под конкретный проект пригодится статья о том, что делать при нехватке RAM — там разобраны способы диагностики через dmesg и free, а также быстрые меры вроде swap-файла как страховки на время миграции на тариф побольше.

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