UrBackup на сервере: частые ошибки и решения

MAATRIX

UrBackup — редкий случай, когда бесплатный инструмент реально закрывает задачу централизованного бэкапа десятков машин: сервер сам находит клиентов в сети, снимает образы дисков и файловые бэкапы, а восстановить один файл можно прямо из веб-интерфейса. Но именно из-за автоматизма — автообнаружение, инкременты, дедупликация — он ломается непредсказуемо: то клиент завис в «Currently working» на третьи сутки, то бэкап есть, а образ не грузится, то диск сервера забился под ноль за неделю. Разбираем восемь ошибок, с которыми сталкиваешься чаще всего, и как их закрыть без пересборки инсталляции с нуля.

Клиент не находится сервером в локальной сети

UrBackup Client должен сам «выстрелить» широковещательным UDP-пакетом на сервер и зарегистрироваться. Если в списке клиентов пусто или машина висит с прочерком в колонке «Статус» — почти всегда виноват firewall или разные подсети.

Проверьте порты на сервере — по умолчанию UrBackup слушает:

ufw allow 55413/tcp
ufw allow 55414/tcp
ufw allow 35623/udp   # UDP-broadcast для автообнаружения

Если сервер и клиенты в разных VLAN или за NAT (типичная ситуация, когда сервер бэкапов в облаке, а клиенты — в офисе), автообнаружение по UDP-broadcast работать не будет в принципе — пакет не проходит через маршрутизатор. Добавляйте клиента вручную по IP: Add new client → Internet client → хост и общий пароль (internet_authkey), который прописывается в urbackup/data/settings.cfg на клиенте.

Отдельно проверьте, что клиентская служба вообще запущена:

systemctl status urbackupclient
journalctl -u urbackupclient -n 50 --no-pager

На Windows-клиентах частая причина тишины — служба «UrBackupClientBackend» не подняла порт из-за конфликта с антивирусом, который блокирует локальный listener на 35623. Если у вас в парке есть и Windows-машины за VPN, полезно заранее свериться с портами клиентских протоколов — по аналогии с тем, как это разбирается для портов VPN-протоколов в Windows Firewall.

Бэкап зависает в статусе «Currently working» и не завершается

Самая раздражающая ситуация: задача стартовала, прогресс-бар остановился на каком-то проценте и не двигается часами. Причины обычно три.

Разрыв сети без таймаута. UrBackup использует собственный протокол поверх TCP и не всегда корректно ловит «мёртвое» соединение, если клиент ушёл в сон или сервер перезагрузился посреди передачи. Лечится настройкой таймаута в Settings → General, параметр Client timeout (по умолчанию 20 минут, для нестабильных каналов имеет смысл снизить до 5–10).

Файл-блокировка на клиенте. Файловый бэкап на Windows идёт через VSS (Volume Shadow Copy). Если снапшот VSS не может создаться (переполнен System Reserved, конфликт с другим ПО, которое тоже держит VSS-writer), задача виснет на моменте создания снимка. Проверка на клиенте:

vssadmin list writers

Если в выводе есть writer со статусом Failed — перезапустите соответствующую службу (для SQL/Exchange часто помогает net stop/net start службы БД) и повторите бэкап.

Слишком много параллельных задач. По умолчанию urbackup-server ограничивает число одновременных клиентских бэкапов, но при бэкапе большого парка машин на слабом сервере хвост из задач в очереди может создавать иллюзию зависания. Смотрите реальную загрузку:

top -o %CPU
iostat -x 2 5

Если диск сервера бэкапов упирается в 100% util при iostat, это не баг UrBackup, а физическое ограничение — либо переносите хранилище на SSD/NVMe, либо разносите расписание клиентов так, чтобы полные бэкапы не стартовали одновременно (Settings → Client → Backup window).

Диск сервера забивается быстрее, чем ожидалось

UrBackup хвалят за дедупликацию на уровне блоков — она реально экономит место при инкрементных образах. Но по умолчанию она включена не для всех типов хранения, и новички часто теряют на этом терабайты.

Дедупликация файлов работает только на файловых системах с поддержкой hardlink (ext4, xfs, btrfs, zfs — но не на большинстве сетевых шар через SMB/CIFS без специальных настроек). Если storage для бэкапов у вас смонтирован по NFS или SMB, проверьте, что монтирование сохраняет hardlink-семантику, иначе каждый инкремент будет храниться как полная копия.

Второе — ретеншен по умолчанию довольно щедрый. В Settings → General → Backup archival задаются интервалы хранения полных и инкрементных копий раздельно:

Если у вас 15-20 клиентов и хранение по умолчанию, за месяц-два набегает объём, кратно превышающий сырой объём данных. Считайте место заранее: (полный бэкап × число хранимых полных копий) + (средний размер инкремента × число инкрементов), закладывая запас х1.5-2 на рост. Общие принципы планирования места под бэкапы разбирали в статье про бэкап всего сервера целиком — логика применима и к серверу-хранилищу UrBackup.

Образ диска снят, но не грузится или не восстанавливается

Образы UrBackup хранятся в собственном формате .vhd/.vhdz (сжатый), и типовая ошибка — попытка смонтировать их напрямую без конвертации.

Чтобы проверить целостность образа перед восстановлением, используйте встроенный инструмент:

urbackup_cmd verify-hashes --backupid <ID>

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

Для восстановления образа на «голое железо» или в виртуалку UrBackup предлагает свой Live-CD/USB на базе Clonezilla-подобного окружения (Restore CD), который сам подключается к серверу и стягивает образ. Ручной способ через qemu-img, если нужно просто посмотреть содержимое:

qemu-img convert -f vhdx -O qcow2 image.vhdz image.qcow2
qemu-nbd --connect=/dev/nbd0 image.qcow2
mount /dev/nbd0p1 /mnt/restore

Важный нюанс: восстановление образа на другое железо (особенно с другим RAID-контроллером) часто упирается в отсутствие нужных драйверов в загрузчике Windows — держите набор драйверов storage-контроллера отдельно от бэкапа.

Веб-интерфейс UrBackup недоступен или падает под нагрузкой

Встроенный веб-сервер UrBackup (порт 55414 по умолчанию) — минималистичный, и на серверах с 50+ клиентами иногда подвисает при построении статистики за большой период.

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

free -h
df -h /var/urbackup
systemctl status urbackup-server

Частая причина деградации — база данных сервера (SQLite по умолчанию) разрастается и начинает тормозить на больших инсталляциях. Признак: в логе urbackup-server (journalctl -u urbackup-server) много строк про database is locked или долгие SELECT. Решение — переезд на отдельный процесс базы (в новых версиях можно указать внешний путь для базы на более быстром диске) либо периодическая очистка старых записей статистики через Settings → Advanced.

Если веб-интерфейс нужно выставить наружу для удалённого управления, не открывайте порт 55414 напрямую в интернет — поставьте перед ним nginx с TLS и Basic Auth или ограничьте доступ по IP через firewall. Базовые принципы настройки файрвола под такие сценарии описаны в статье про настройку UFW на сервере.

Инкрементные бэкапы «раздуваются» до размера полного

Иногда после нескольких недель работы видно, что инкрементный бэкап занимает почти столько же места, сколько полный — это симптом, а не норма.

Основных причин две. Первая — приложение на клиенте активно переписывает большие файлы целиком вместо точечных изменений (базы данных, VM-образы, файлы подкачки), из-за чего блочный diff почти не экономит место. Такие файлы лучше исключить из файлового бэкапа UrBackup и настроить для них отдельный инструмент — для баз MySQL/PostgreSQL логичнее делать дамп через mysqldump/pg_dump по расписанию, а не гонять сырые файлы через образный бэкап. Подробности — в статье про частые ошибки бэкапа MySQL на сервере.

Вторая причина — block size дедупликации выставлен слишком крупным. В Settings → Advanced есть параметр image_letters/размер блока для сравнения образов; чем крупнее блок, тем менее гранулярно UrBackup видит изменения и тем чаще считает блок «изменившимся» целиком из-за пары байт внутри. На SSD-хранилище сервера бэкапов можно смело уменьшать размер блока — прирост нагрузки на CPU для хэширования того стоит.

Клиент под Linux не снимает полный файловый бэкап (ошибка прав доступа)

На Linux-клиентах UrBackup Client работает от отдельного пользователя (urbackup), и если он не входит в нужные группы или ACL закрывают чтение — часть файлов просто пропускается без явной ошибки, только предупреждение в логах.

Проверьте лог клиента:

journalctl -u urbackupclient -n 200 --no-pager | grep -i "permission\|denied"

Быстрое, но грубое решение — добавить пользователя urbackup в группы владельцев нужных директорий:

usermod -aG www-data,docker urbackup
systemctl restart urbackupclient

Более аккуратный вариант для продакшена — не расширять группы, а настроить ACL точечно на конкретные каталоги:

setfacl -R -m u:urbackup:rX /var/www/app
setfacl -R -d -m u:urbackup:rX /var/www/app

Если бэкапите Docker-хосты с volume, учтите, что снимок «на лету» файлов внутри volume, который активно пишет контейнер, может дать несогласованное состояние — для контейнерных данных отдельно стоит посмотреть на подходы из статьи про бэкап Docker volume: частые ошибки и решения, где разобраны варианты со стоп-снимками и снапшотами тома.

Хранилище бэкапов не защищено от компрометации сервера

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

Минимальный набор мер:

• Держите сервер бэкапов на отдельной виртуалке, желательно в другом сегменте сети или у другого провайдера — так вы не теряете рабочие машины и бэкапы при одном инциденте.
• Настройте Settings → General → Server так, чтобы клиенты не могли удалять чужие бэкапы (по умолчанию клиент инициирует удаление только своих задач, но проверяйте права после каждого обновления UrBackup).
• Если бюджет позволяет — реплицируйте каталог с бэкапами ещё и на внешнее S3-совместимое хранилище через rclone по cron, отдельно от основного хранилища сервера. Разница между «бэкап есть» и «бэкап переживёт инцидент с самим сервером бэкапов» именно в этом шаге.

Если ставите UrBackup впервые под выделенный сервер — держите в уме отдельный том под /var/urbackup (не системный раздел) и запас по RAM: SQLite-база и хэширование дедупликации при парке 30+ машин заметно едят память при активных бэкапах.

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