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

MAATRIX

BorgBackup — один из самых надёжных инструментов дедуплицирующего бэкапа на Linux, но у него есть особенность, которая ловит новичков врасплох: память под индексы растёт не от объёма данных, а от количества чанков и файлов. В итоге бэкап 50 ГБ мелких файлов может съесть больше RAM, чем бэкап 2 ТБ видеоархива. Разберём, откуда берётся этот расход, как его посчитать заранее по официальной формуле Borg и что делать, если сервер маловат.

Из чего складывается расход памяти у Borg

Когда Borg режет файлы на чанки контентно-зависимым чанкером (buzhash) и ищет среди них дубликаты, ему нужно держать в оперативной памяти три структуры:

• Индекс репозитория — таблица «ID чанка → где он лежит», нужна и на клиенте, и на стороне репозитория при операциях check, compact, prune.
• Chunks cache — локальный клиентский кэш известных чанков, чтобы не спрашивать репозиторий про каждый чанк при следующем бэкапе.
• Files cache — таблица «путь, размер, mtime, инод → список чанков», позволяющая пропускать файлы, которые не менялись с прошлого запуска, вообще не читая их заново.

Все три структуры — это хеш-таблицы, и Borg держит их целиком в памяти на время операции, а не подгружает частями с диска. Именно поэтому у Borg (в отличие от многих других бэкап-инструментов) RAM — реальный лимитирующий ресурс, а не диск или CPU.

Формула: считаем RAM по документации Borg

В официальной документации Borg (раздел про внутренние структуры данных) приведена прямая оценка:

mem_usage ≈ chunk_count * 164 + total_file_count * 240   (в байтах)

Это раскладывается так: около 40 байт на чанк уходит на индекс репозитория, около 44 байт на чанк — на chunks cache, ещё около 80 байт на чанк и 240 байт на файл — на files cache (40+44+80=164, плюс фиксированные 240 на файл). Число чанков оценивается как объём уникальных данных, делённый на средний размер чанка (по умолчанию у buzhash-чанкера это около 2 МиБ).

Возьмём пример из самой документации: 1 миллион файлов общим объёмом 1 ТиБ, чанкер по умолчанию. Число чанков ≈ 1 ТиБ / 2 МиБ ≈ 524 288. Подставляем:

524288 * 164 + 1000000 * 240 ≈ 86 МБ + 240 МБ ≈ 0.3 ГиБ

Важный нюанс: это оценка *используемой* памяти, а не фактически *выделенной*. Хеш-таблицы Borg работают с коэффициентом заполнения (load factor) от 0.25 до 0.75, и фактическое выделение памяти — это mem_usage / load_factor. То есть в худшем случае реальный RSS процесса может быть в 2-4 раза больше расчётного значения, а в момент роста таблицы (ресайза) — кратковременно ещё в 1.1-2 раза выше пикового. На практике это значит: к результату формулы стоит закладывать запас x2-x3, а не брать её как потолок.

Два расчёта, которые показывают разницу

Формула наглядно объясняет, почему природа данных важнее их объёма.

Крупные файлы, мало штук. Архив видео или бэкапов ВМ на 2 ТБ, всего 50 000 файлов: чанков ≈ 2 ТиБ / 2 МиБ ≈ 1 048 576. 1048576*164 + 50000*240 ≈ 172 МБ + 12 МБ ≈ 0.18 ГиБ использования — даже с запасом x3-x4 это меньше гигабайта.

Мелкие файлы, много штук. Почтовый сервер или дерево с node_modules, суммарно 500 ГБ, но 5 000 000 файлов, каждый заметно меньше среднего размера чанка (значит, число чанков близко к числу файлов): 5000000*164 + 5000000*240 = 5000000*404 ≈ 1.9 ГиБ использования, а с учётом load factor 0.25 реальное выделение может дойти до 6-8 ГБ. Это ориентировочная иллюстрация по формуле из документации, а не измеренный бенчмарк — точные цифры зависят от версии Borg и реального распределения размеров файлов, но порядок величины и сам эффект («файлов много — RAM много, даже если данных мало») реален.

Отсюда практический вывод: перед тем как выбирать тариф VPS под Borg, посчитайте не гигабайты, а количество файлов и ожидаемое число чанков.

Компрессия и размер чанков: что реально влияет на RAM

Компрессия (--compression lz4, zstd, zlib) в первую очередь нагружает CPU, а не RAM — буферы компрессии на поток небольшие по сравнению с индексами, так что для экономии памяти алгоритм компрессии почти не важен. Куда сильнее на RAM влияет --chunker-params.

По умолчанию Borg использует «крупнозернистый» профиль buzhash,19,23,21,4095 — целевой размер чанка около 2 МиБ (2^21), меньше чанков, меньше памяти, годится для больших объёмов на слабом сервере. Альтернатива — «мелкозернистый» buzhash,10,23,16,4095 с целевым размером около 64 КиБ (2^16): в десятки раз больше чанков на тот же объём данных и, соответственно, в десятки раз больше RAM на индексы, зато точнее дедупликация на файлах с частыми мелкими правками (базы данных, образы дисков ВМ). Для блочных устройств есть ещё режим fixed,4194304 — фиксированные чанки по 4 МиБ без контентного анализа, самый лёгкий по памяти вариант, но и без адаптивной дедупликации при сдвиге данных.

# крупные чанки, экономия RAM — по умолчанию
borg create --chunker-params=buzhash,19,23,21,4095 ...

# мелкие чанки, точнее дедупликация, больше RAM
borg create --chunker-params=buzhash,10,23,16,4095 ...

Правило простое: статичные крупные файлы (медиа, архивы, бэкапы-снапшоты) — можно смело увеличивать чанк и экономить память; активно меняющиеся файлы с мелкими правками внутри (СУБД, диски ВМ) — там мелкие чанки окупаются лучшей дедупликацией, но за счёт RAM.

Клиент, сервер и общий репозиторий — кому именно нужна память

Если вы бэкапитесь через SSH на отдельный сервер (borg create ssh://user@host/path::archive ...), память нужна по обе стороны, но по-разному:

• На клиенте — chunks cache и files cache, они привязаны к конкретной машине и её файлам.
• На стороне репозитория (процесс borg serve на удалённом хосте) — индекс репозитория, который нужен для операций записи, check, compact и prune. Он растёт с общим числом уникальных чанков *во всём репозитории*, а не только с объёмом данных одного клиента.

Это особенно важно, если вы держите один VPS как централизованную точку бэкапа для нескольких серверов сразу (fan-in): индекс на стороне репозитория считается по сумме всех архивов всех источников. Если память на таком узле впритык, разумнее развести источники по отдельным репозиториям (разные каталоги, разные borg init), чем складывать всё в один — тогда операции обслуживания (compact, check) каждый раз работают с меньшим индексом.

Сколько RAM закладывать: практические ориентиры

Ориентиры ниже — не гарантия, а отправная точка для выбора тарифа, с уже заложенным запасом на load factor:

Не забывайте, что это память под сам процесс Borg, а не под всю систему — сверху нужен запас на ОС, другие сервисы и файловый кэш. Если тариф пограничный, swap-раздел не заменит RAM для скорости, но спасёт от OOM killer в момент пикового индекса — процесс просто замедлится вместо падения. Общие принципы подбора памяти под сервер разобраны в статье про то, сколько оперативной памяти закладывать с запасом.

Как снизить расход памяти на слабом VPS

Если апгрейд тарифа пока не вариант, есть рабочие способы уменьшить аппетит Borg:

# отключить files cache — экономит RAM, но каждый прогон
# перечитывает и перехэширует все файлы заново (дороже по CPU/IO)
borg create --files-cache=disabled ...

• Исключайте мусор из бэкапа. node_modules, .venv, __pycache__, кэши Docker, .git в рабочих копиях — это тысячи файлов, которые не нужно бэкапить вообще. Флаг --exclude и --exclude-caches снижают число файлов, а значит и расход на files cache, ещё до чтения диска.
• Увеличивайте средний размер чанка через --chunker-params для крупных статичных данных — см. раздел выше.
• Дробите один большой репозиторий на несколько, если это данные разных проектов или машин — компактнее индекс на каждой отдельной операции обслуживания.
• Регулярно запускайте borg compact после prune, чтобы репозиторий (и, соответственно, индекс) не разрастался мусором от удалённых архивов.
• Мониторьте фактическое потребление во время бэкапа: ps -o rss,cmd -C borg или systemd-run --scope -p MemoryMax=... borg create ..., чтобы поймать проблему до того, как её поймает oom-killer — а его срабатывания видно в dmesg | grep -i oom. Если бэкап запускается по cron, полезно следить за самим фактом успешного завершения задачи — например, через healthchecks.io, чтобы падение из-за нехватки памяти не осталось незамеченным до момента, когда бэкап реально понадобится.
• Добавьте swap как страховку, а не как основной ресурс — короткий пик при ресайзе хеш-таблицы Borg переживёт своп, постоянная нехватка RAM — нет.

Если после всех оптимизаций память всё равно в притык, проще и надёжнее один раз посчитать нужный объём по формуле выше и взять сервер с соответствующим запасом RAM — тем более что под задачу бэкапа не нужны мощные CPU или диски NVMe, достаточно адекватной памяти и надёжного канала. Для сравнения с другим подходом к дедуплицирующему бэкапу можно посмотреть на настройку бэкапа с шифрованием через restic — там похожая логика с индексами, но другой набор компромиссов.

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