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

MAATRIX

Restic на бэкапе выглядит бережливым: гигабайты данных утекают в репозиторий, а процесс держит десятки-сотни мегабайт. Память кончается не там — на restic prune или restic check через полгода эксплуатации, когда индекс репозитория разросся до сотен тысяч блобов и упёрся в потолок RAM тарифа. Разберём, что именно грузит память в restic, как посчитать свою цифру по количеству блобов и что сделать, если сервер маленький, а репозиторий растёт.

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

Цифры зависят не от объёма данных под бэкапом, а от размера репозитория и того, что вы с ним делаете.

Главное: restic не грузит в память данные, которые бэкапит. Он читает файлы потоково, режет на чанки и сразу пишет пакеты в репозиторий. Память ест другое — индекс: список хешей всех блобов репозитория, который restic держит целиком в оперативке при большинстве операций. Индекс растёт не с объёмом данных, а с количеством уникальных блобов, а значит быстрее всего пухнет там, где файлов много и они мелкие: почтовые ящики, git-репозитории, базы с миллионами маленьких строк.

Почему backup почти не грузит память

restic backup — самая безобидная команда с точки зрения RAM, и это заложено в архитектуру инструмента. Restic использует content-defined chunking (алгоритм на основе полиномов Rabin): файл режется на куски переменного размера (в среднем около 1 МБ), для каждого куска считается SHA-256, и если такой хеш уже есть в репозитории — кусок не передаётся повторно. Обработка идёт потоково: кусок прочитан, хеш посчитан, кусок сжат (начиная с restic 0.16 — Zstandard) и записан в пакет, память под него освобождена.

Что действительно занимает RAM во время backup:

• Индекс репозитория — список всех известных хешей блобов, чтобы понять, что уже есть, а что нужно закачать. Держится целиком в памяти на всё время операции.
• Буферы чтения и упаковки — несколько десятков-сотен мегабайт на параллельные потоки чтения и upload.
• Кэш метаданных файлов — список путей, размеров, времени изменения для дерева снапшота.

На практике backup каталога в 200 ГБ с уже существующим репозиторием на несколько сотен гигабайт стабильно укладывается в 300–600 МБ RSS:

/usr/bin/time -v restic backup /var/www 2>&1 | grep -i "maximum resident"
	Maximum resident set size (kbytes): 412884

Если backup всё же падает по памяти на маленьком сервере — почти всегда виноват не restic, а сам источник: mysqldump перед архивацией, распаковка временного tar-файла или процесс приложения, который бэкап случайно разбудил. Смотрите на реального виновника через dmesg -T | grep -i "killed process", а не на restic по умолчанию.

Индекс: где на самом деле кончается память

Индекс — единственная структура restic, которая масштабируется линейно с количеством блобов и грузится в RAM целиком при backup, check и особенно при prune. Устройство простое: на каждый блоб в репозитории — запись с ID (32 байта хеша SHA-256), позицией в pack-файле, размером и типом. Практическая оценка — порядка 200–250 байт памяти на один блоб с учётом накладных расходов структуры данных Go, но это ориентир, а не измеренная константа: конкретная цифра зависит от версии restic и от доли метаданных tree-объектов.

Дальше — арифметика. Средний размер блоба данных зависит от настройки --pack-size (раньше объединялись в паки по ~4–5 МБ, с restic 0.14 дефолт поднят до 16 МиБ, при этом сами блобы внутри пака остаются около мегабайта каждый). Отсюда простая прикидочная формула:

количество блобов ≈ объём репозитория (в МБ) / средний размер блоба (≈1 МБ)
память под индекс ≈ количество блобов × 200–250 байт

Для репозитория в 500 ГБ это примерно 500 000 блобов и 100–125 МБ памяти под сам индекс — немного. Но если в бэкапе много мелких файлов (почта в Maildir, node_modules, кэши), средний размер объекта падает, число блобов растёт непропорционально объёму, и индекс может занять на порядок больше при том же весе репозитория. У больших продакшн-репозиториев (несколько терабайт, годы истории снапшотов) индекс на практике доходит до единиц гигабайт; точные цифры отличаются от установки к установке, ориентируйтесь на собственный замер, а не на чужой репозиторий.

Посмотреть текущий размер индекса своего репозитория:

restic cat config
restic stats --mode raw-data
du -sh /path/to/repo/index/

Последняя команда для локального или SFTP-бэкенда даёт грубую оценку на диске — в памяти индекс распакован и обычно немного больше.

Prune и check: где RAM реально кончается

restic prune — самая тяжёлая по памяти операция, и вот почему. Prune должен решить, какие блобы больше не нужны ни одному снапшоту, и для этого строит в памяти полную карту: индекс репозитория плюс дерево всех сохранённых снапшотов со ссылками на блобы. На репозитории с длинной историей (ежедневные снапшоты за год-два, политика хранения --keep-daily 30 --keep-weekly 12 --keep-monthly 12) это дерево ощутимо крупнее самого индекса.

Типичная картина отказа на VPS с 1 ГБ:

restic prune
loading indexes...
[0:12] 100.00%  4 / 4 index files loaded
loading all snapshots...
finding data that is still in use for 187 snapshots
Killed

dmesg -T | grep -i "killed process"
[Thu Aug 27 03:14:02 2026] Out of memory: Killed process 8821 (restic) total-vm:2984512kB, anon-rss:967340kB

Процесс убит на этапе построения карты используемых данных — до записи чего-либо на диск, репозиторий при этом не повреждается: restic использует транзакционную блокировку и не оставляет промежуточных изменений при аварийном завершении. Упавший prune можно просто перезапустить после освобождения памяти или добавления swap.

restic check без флагов легче prune — держит индекс в памяти, но не строит карту использования блобов. restic check --read-data перечитывает и проверяет контрольные суммы всех пак-файлов репозитория: по памяти она ближе к обычному check, но по времени и нагрузке на диск/сеть (для S3 — это полное скачивание репозитория) на порядок дороже. Держите её для нечастых прогонов раз в месяц-квартал, а не в ежедневном cron.

Как снизить расход памяти без апгрейда тарифа

Несколько настроек, которые двигают именно потребление RAM, а не общую производительность:

Увеличить --pack-size. Меньше блобов на тот же объём данных — меньше записей в индексе:

restic backup --pack-size 32 /var/www

Компромисс честный: крупные паки хуже дедуплицируются при частично изменившихся файлах и чуть дольше передаются целиком при плохой сети, зато индекс кратно легче. Для бэкапов с преобладанием крупных редко меняющихся файлов (образы, архивы, дампы БД целиком) поднимать --pack-size до 32–64 МБ почти всегда оправдано.

Ограничить количество снапшотов перед prune. Чем длиннее история, тем тяжелее карта использования. Политика хранения, применённая заранее, снижает пик:

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

forget --prune в одной команде запускает prune сразу после forget — тот же тяжёлый по памяти проход, просто на уже сокращённом наборе снапшотов.

GOGC для агрессивной сборки мусора. Restic написан на Go, и стандартный трюк с GOGC работает так же, как для любого Go-бинарника:

GOGC=50 restic prune

Значение по умолчанию — 100 (сборщик срабатывает, когда куча выросла вдвое с прошлого прохода); GOGC=50 заставляет GC работать чаще и держать пиковую RSS ниже ценой более высокой загрузки CPU. На однократном ночном prune эта плата почти не заметна.

Своп как страховка, не как решение. Своп в 2 ГБ спасёт разовый prune, который не укладывается в лимит на несколько сотен мегабайт, но растянет операцию с минут до десятков минут — NVMe на порядки медленнее RAM. Для регулярного, предсказуемо тяжёлого prune это не замена памяти, а временный костыль:

sudo fallocate -l 2G /swapfile && sudo chmod 600 /swapfile
sudo mkswap /swapfile && sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Бэкенды и как измерить свои требования, не гадая

Тип бэкенда сам по себе почти не влияет на память индекса, зато влияет на то, как быстро вы упрётесь в неё через сетевые буферы.

Пик через /usr/bin/time — самый прямой способ для разовой команды:

/usr/bin/time -v restic prune 2>&1 | grep -E "Maximum resident|Elapsed"

cgroup, если restic запущен как systemd-юнит или в контейнере:

cat /sys/fs/cgroup/system.slice/restic-prune.service/memory.peak

Косвенная оценка по количеству объектов без запуска prune — restic stats --mode raw-data показывает число блобов, которое можно умножить на 200–250 байт для грубой нижней границы под индекс. Это ориентир для планирования, не гарантия: точный расход зависит от версии restic и параллелизма запуска, финальную цифру проверяйте прогоном prune на копии реального репозитория.

Правило по итогу замера: пик prune за неделю плюс 30–50% запаса — и это ваша цифра тарифа, а не объём бэкапящихся данных.

Какой сервер взять в MAATRIX под restic

Честный минимум: 1 vCPU, 1 ГБ RAM, диск под объём репозитория с запасом ×1,5–2. Подходит для персональных бэкапов и одного небольшого сайта: backup и restore работают уверенно, prune — раз в месяц, не в ежедневном cron, и лучше в окно с минимальной другой нагрузкой.

Рабочий вариант: 2 vCPU, 2 ГБ RAM. Репозиторий до 300–500 ГБ, регулярный forget --prune по расписанию без риска OOM, комфортный запас под индекс даже при мелких файлах в бэкапе. Это конфигурация, которую мы советуем чаще всего для отдельного сервера под бэкапы.

Для нескольких источников или большого архива: 4 vCPU, 4–8 ГБ RAM, объёмный NVMe или подключённое S3-совместимое хранилище. Несколько репозиториев на одном сервере, параллельные backup с разных источников, check --read-data без риска упереться в память на середине прохода.

Диск и локация. Под restic важнее не CPU, а диск и канал: локальный репозиторий требует места с запасом на паки до их упаковки и временные файлы prune, а S3-бэкенд — стабильного канала наружу. Для российских источников с бэкапом в Европу или США латентность на сам backup не критична — трафик идёт потоково, а не синхронными запросами.

Готовый сервер под restic можно развернуть на MAATRIX за несколько минут, конфигурацию подбираем под объём вашего репозитория и частоту prune. Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT, без иностранной карты даже для площадок в Лондоне и США.

Смежные материалы: бэкап с шифрованием на сервере — частые ошибки, сколько ресурсов нужно VPS для бэкапов и архива и VPS для бэкапов и архива: что выбрать и как настроить.

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