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

MAATRIX

UrBackup — удобный способ собрать бэкапы десятков и сотен машин в одном месте: образы дисков, файловые снимки, восстановление вплоть до отдельного файла через веб-интерфейс. Проблема начинается, когда сервер с 4 ГБ памяти, который отлично тянул 10 клиентов, начинает захлёбываться на 40-м — задания встают в очередь, веб-интерфейс тормозит, а free -h показывает, что своп забит под завязку. Разберёмся, откуда растёт аппетит UrBackup к памяти и как посчитать, сколько RAM закладывать заранее.

Как UrBackup использует память: сервер и клиенты

Архитектура UrBackup — классический клиент-сервер. На каждой защищаемой машине стоит лёгкий агент (клиент), который почти не потребляет ресурсов в простое — это не та часть, о которой стоит беспокоиться. Вся нагрузка на память ложится на сервер, и складывается она из нескольких независимых источников:

• Активные задания бэкапа — на каждое одновременное файловое или образное задание сервер держит буферы чтения/записи, состояние хеширования и сетевые сокеты.
• База данных — метаданные о клиентах, файлах, версиях, хешах для дедупликации.
• Веб-интерфейс — сам по себе лёгкий, но параллельные сессии администраторов и API-запросы (например, от систем мониторинга) добавляют нагрузку.
• Файловая система хранилища — если бэкапы лежат на ZFS или BTRFS с включённой дедупликацией на уровне ФС, именно этот слой обычно съедает больше всего памяти, а не сам UrBackup.

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

Из чего складывается потребление RAM на сервере

Если смотреть на процесс urbackupsrv через htop или docker stats (если сервер развёрнут в контейнере), резидентная память растёт пропорционально трём вещам:

1. Число одновременных активных заданий (не общее число клиентов, а именно сколько бэкапов идёт прямо сейчас). Настраивается в веб-интерфейсе: *Settings → General → Number of simultaneous file backups / image backups*. Это самый прямой рычаг управления пиковым потреблением памяти.
2. Размер и активность базы данных. По умолчанию UrBackup хранит метаданные в SQLite — файл растёт с числом клиентов, версий файлов и глубиной хранения истории. При больших базах (десятки гигабайт) операции обслуживания (VACUUM, индексация) заметно едят память и I/O.
3. Тип бэкапа. Образные бэкапы (image backups) работают с крупными блоками и часто используют сжатие на лету (LZ4) — каждое такое задание держит буферы порядка десятков-сотен мегабайт, в зависимости от размера тома и настроек. Файловые бэкапы легче по памяти, но чаще создают много мелких операций с БД.

Проверить, что реально происходит на сервере, проще всего так:

free -h
htop -u urbackup
du -sh /var/urbackup/backup_server_db.db 2>/dev/null || find / -iname "backup_server_db.db" 2>/dev/null
watch -n2 'ps aux | grep urbackupsrv | grep -v grep'

Если сервер запущен в Docker (частый вариант деплоя):

docker stats urbackup-server
docker exec -it urbackup-server du -sh /var/urbackup

Дедупликация и файловая система: где память расходуется по-настоящему

Это ключевой момент, который часто путают. Есть два разных механизма дедупликации, и они по-разному влияют на RAM:

Дедупликация UrBackup (на уровне приложения). Сервер сравнивает хеши файлов между клиентами и версиями, храня таблицу соответствий в своей базе данных. Это не требует держать хеш-таблицу целиком в оперативной памяти — она живёт на диске в БД с индексами, и нагрузка на RAM здесь умеренная даже при больших объёмах.

Дедупликация файловой системы (ZFS/BTRFS). Если вы кладёте хранилище UrBackup на ZFS с включённым dedup=on, это уже совсем другая история: ZFS dedup общеизвестно прожорлив по памяти — ориентировочно счёт идёт на гигабайты RAM на каждый терабайт уникальных данных, и это отдельно от нужд самого UrBackup. Поскольку UrBackup и так дедуплицирует файлы на своём уровне, включать ZFS dedup поверх хранилища UrBackup в большинстве случаев избыточно — вы платите памятью дважды за один и тот же эффект.

Практический вывод: держите backup-хранилище UrBackup на обычной ФС (ext4, XFS, BTRFS без dedup) или на ZFS с dedup=off, но с включённым сжатием (compression=lz4) — оно почти не требует RAM и всё равно экономит место:

zfs create -o compression=lz4 -o dedup=off tank/urbackup-storage

Если используете BTRFS для образных бэкапов ради reflink-снапшотов — это тоже не требует держать хеш-таблицы в памяти, в отличие от ZFS dedup.

Расчёт RAM по числу клиентов и типу бэкапов

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

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

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

База данных: SQLite и её пределы

UrBackup по умолчанию использует SQLite для хранения метаданных — простое и надёжное решение для небольших и средних инсталляций, но у него есть потолок. SQLite — однопоточная по записи база: при высокой параллельности заданий (много клиентов одновременно пишут метаданные) она может стать узким местом раньше, чем закончится память. Симптомы: веб-интерфейс подвисает при открытии списка клиентов, задания дольше обычного находятся в статусе "queued".

Что стоит проверить, если база разрослась:

sqlite3 /var/urbackup/backup_server_db.db "PRAGMA integrity_check;"
sqlite3 /var/urbackup/backup_server_db.db "VACUUM;"

VACUUM пересобирает файл базы и может временно требовать свободного места и памяти сопоставимого с текущим размером базы — на боевом сервере с большой историей это стоит делать в окне обслуживания, а не в рабочее время. Путь к файлу базы зависит от способа установки (пакет, исходники, Docker-образ) — уточните его в конфигурации вашего инстанса, если стандартный /var/urbackup/ не подходит.

Если база стабильно занимает заметную долю диска и операции с ней ощутимо нагружают процессор и память, есть смысл сократить глубину хранения версий (retention) в настройках клиентских групп — меньше версий файлов означает меньше строк в таблицах метаданных и более лёгкие операции обслуживания.

Практическая настройка: как снизить потребление памяти

Если сервер уже упирается в лимиты, а расширять RAM пока не вариант, есть несколько рычагов без замены железа:

• Ограничьте параллелизм. *Settings → General* — снизьте число одновременных файловых и особенно образных заданий. Это самый быстрый способ срезать пиковое потребление памяти.
• Разнесите расписания. Не запускайте бэкап всех клиентов в одно окно — растяните по ночи, чтобы очередь заданий сглаживала нагрузку, а не создавала пик.
• Отключите dedup на файловой системе, если он включён поверх хранилища UrBackup — оставьте только сжатие, как показано выше.
• Настройте swap как страховку, а не как рабочий режим. Немного свопа на быстром NVMe спасёт от OOM-килла при случайном пике, но система, которая постоянно свопится, будет заметно медленнее выполнять бэкапы — это сигнал наращивать RAM, а не решение.
• Вынесите базу данных на отдельный быстрый диск (NVMe), если хранилище бэкапов лежит на HDD или сетевом сторадже — так операции с БД не конкурируют за I/O с записью самих бэкапов.
• Мониторьте тренд, а не разовые цифры. Разовый скачок free -h во время образного бэкапа — норма. Стабильный рост базового потребления от недели к неделе — повод пересчитать лимиты.

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

Если UrBackup — не единственный инструмент в вашем арсенале и вы присматриваетесь к альтернативам для части сценариев (например, для бэкапа конфигов отдельных серверов без централизованной консоли), стоит сравнить требования к памяти с другими инструментами — у BorgBackup и Restic модель дедупликации устроена иначе и по-другому масштабируется с объёмом данных.

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