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

MAATRIX

Kopia выбирают за то, что это не голая утилита в консоли, а бэкап с собственным веб-UI, встроенным планировщиком и внятной дедупликацией — разумная альтернатива restic и Borg, когда хочется меньше возиться с cron и текстовым выводом. Вопрос про RAM всплывает на этапе выбора тарифа: документация Kopia честно говорит, что память съедают не гигабайты бэкапящихся данных, а количество файлов, число параллельных воркеров и параметры кэша. Разберём, что конкретно грузит память в Kopia, как прикинуть свою цифру и что настроить, если сервер небольшой.

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

Цифры ориентировочные — Kopia не публикует жёстких требований к памяти, а сама архитектура специально спроектирована так, чтобы не держать весь индекс репозитория в оперативке (в отличие от restic). Но это не значит, что памяти нужно ноль: параллелизм, число файлов в снапшоте и полная компакция при обслуживании репозитория съедают её вполне ощутимо.

Как Kopia использует память: кэш вместо индекса в RAM

Kopia режет файлы на блоки переменного размера (content-defined chunking с полиномиальным rolling hash, как у restic и Borg), считает хеш каждого блока и решает, есть ли такой контент уже в репозитории. Ключевое архитектурное отличие от restic: индекс репозитория (список content ID → расположение в pack-файле) Kopia не обязана держать целиком в оперативной памяти на всё время операции. Вместо этого используется локальный дисковый кэш — три отдельных кэша под директорией --cache-directory (по умолчанию ~/.cache/kopia на Linux):

• content cache — уже скачанные и распакованные data-блоки, чтобы не тянуть их из хранилища повторно при повторяющихся операциях;
• metadata cache — блоки метаданных (структура дерева каталогов, манифесты снапшотов);
• index cache — сами index-блобы репозитория, подгружаются и кэшируются на диск, а не разворачиваются целиком в RAM.

Посмотреть текущее состояние кэшей и их лимиты:

kopia cache info

Это снижает пиковую память по сравнению с restic на больших репозиториях, но не убирает расход RAM совсем — диск и сеть под кэш всё равно проходят через оперативную память процесса, плюс поверх кэша работают буферы хеширования, сжатия (Kopia использует zstd по умолчанию) и сборки дерева снапшота.

Что сильнее всего двигает потребление: файлы, parallel, maintenance

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

Параллелизм загрузки. Каждый воркер snapshot create держит собственные буферы: кусок файла на хеширование, буфер под сжатие, буфер под отправку в хранилище. Число воркеров задаётся флагом:

kopia snapshot create /var/www --parallel=4

По умолчанию Kopia сама подбирает параллелизм исходя из числа CPU — на VPS с 4+ vCPU это может означать 4 и больше одновременных воркеров без явного запроса. На маленьком тарифе с 1–2 vCPU и 1 ГБ RAM стоит явно прибить --parallel к 1–2, а не полагаться на автоопределение.

kopia maintenance run --full. Плановое обслуживание репозитория — компакция мелких pack-файлов в крупные и сборка мусора (удаление блоков, на которые больше не ссылается ни один снапшот). Быстрое обслуживание (--full не указан) лёгкое по памяти, полное — обрабатывает и переупаковывает содержимое пачками, и на репозитории в сотни гигабайт — тысячи мелких файлов это ощутимый временный всплеск RAM и I/O. Полное обслуживание запускается по расписанию автоматически (раз в сутки по умолчанию для владельца репозитория), и это стоит учитывать при выборе тарифа — пик придётся не на момент бэкапа, а на плановое окно maintenance.

kopia server с веб-UI. Сам процесс сервера лёгкий (десятки МБ на простое), но при активной работе через UI — просмотр дерева снапшота, восстановление файлов через браузер — сервер держит в памяти результаты последних запросов и кэш листингов каталогов. На постоянно включённом сервере с несколькими репозиториями закладывайте отдельный запас поверх обычного бэкапа.

Настройка кэшей, лимитов и parallel-воркеров

Лимиты кэша задаются один раз при подключении к репозиторию и меняются командой kopia cache set без переподключения:

kopia cache set \
  --content-cache-size-limit-mb=1000 \
  --metadata-cache-size-limit-mb=500 \
  --cache-directory=/var/lib/kopia-cache

Это лимиты дискового кэша, не RAM напрямую — но косвенно они влияют на память: чем меньше кэш, тем чаще Kopia перечитывает и переразворачивает блоки из хранилища заново, а каждое такое обращение проходит через оперативные буферы процесса. На слабом VPS с медленным диском разумнее держать кэш небольшим (200–500 МБ) и смириться с чуть более медленными повторными операциями, чем гнаться за скоростью ценой памяти.

Параллелизм фиксируйте явно в политике, чтобы не зависеть от автоопределения по CPU:

kopia policy set /var/www --parallel=2
kopia policy set --global --compression=zstd

Точные имена флагов и подкоманд слегка отличаются между версиями Kopia — перед боевой настройкой сверьтесь с kopia policy set --help и kopia cache set --help в установленной у вас версии.

Для полного обслуживания на маленьком сервере имеет смысл вынести его из автоматики в ручное окно с низкой нагрузкой:

kopia maintenance set --owner=none
# и запускать вручную по cron ночью:
0 3 * * 0 root /usr/bin/kopia maintenance run --full

Kopia на слабом VPS и что делать при OOM

Если сервер падает в OOM именно на Kopia, а не на соседнем процессе — три рабочих шага по порядку приоритета:

1. Снизить --parallel до 1–2 в политике источника. Это первое, что стоит попробовать: параллелизм линейно множит буферы на число воркеров, и на 1 ГБ RAM разница между --parallel=1 и автоопределением на 4 vCPU может быть решающей.
2. Уменьшить лимиты кэша через kopia cache set, особенно если кэш живёт на том же медленном диске, что и система — держите content-cache в разумных 300–500 МБ на маленьком тарифе.
3. Не совмещать kopia server (веб-UI) с тяжёлым maintenance run --full на одном небольшом сервере одновременно — разнесите по времени через cron, а не полагайтесь на встроенный планировщик, который выберет момент сам.

Своп как страховка на случай разового всплеска — дёшево и не помешает:

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

Как и с расчётом памяти под restic, своп не решает системную нехватку RAM для регулярной тяжёлой операции — только сглаживает редкий пик. Если maintenance run --full или снапшот с миллионами файлов падает по OOM каждую неделю, это сигнал брать тариф с большим запасом, а не жить на свопе постоянно.

Диагностика виновника — стандартная для любого Go-процесса на Linux:

dmesg -T | grep -i "killed process"
/usr/bin/time -v kopia snapshot create /var/www 2>&1 | grep -i "maximum resident"

Если Kopia запущена как systemd-юнит, пиковую память конкретного запуска удобно смотреть через cgroup:

systemctl status kopia-server.service
cat /sys/fs/cgroup/system.slice/kopia-server.service/memory.peak

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

Минимум для персонального бэкапа: 1 vCPU, 1 ГБ RAM. Подходит, если Kopia запускается по расписанию через cron без постоянно висящего веб-UI, --parallel явно ограничен 1–2, объём — до нескольких сотен гигабайт. Полное maintenance — вручную, ночью, не по автоматическому расписанию.

Рабочий вариант: 2 vCPU, 2 ГБ RAM. Веб-UI работает постоянно, репозиторий до 1–2 ТБ, автоматическое обслуживание по умолчанию не пугает. Это конфигурация, которую разумно брать для отдельного сервера под бэкапы одного-двух источников — сравнимо с тем, что мы советуем и для borgbackup на VPS.

Для нескольких источников или деревьев с миллионами мелких файлов: 4 vCPU, 4 ГБ RAM и больше, с NVMe под кэш и сам репозиторий — компакция и GC на таких деревьях заметно чувствительнее к диску, чем к CPU.

Общий подход к выбору ресурсов под бэкап-сервер, включая диск и сеть, разобран в материале VPS для бэкапов и архива: что выбрать и как настроить; если своп на серверe ещё не настроен — см. правильный размер swap для VPS.

Сервер под Kopia на MAATRIX разворачивается за несколько минут, конфигурацию подбираем под объём вашего репозитория и режим работы (разовый cron или постоянный веб-UI). Оплата — картой российского банка, по СБП, криптовалютой или токеном MAAT, без иностранной карты даже для площадок в США и Великобритании.

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