Бэкап и восстановление UrBackup

MAATRIX

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

Что такое UrBackup и когда он нужен

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

Ключевая особенность — два независимых уровня бэкапа одновременно:

• Файловый уровень — инкрементальные снапшоты каталогов с быстрым восстановлением отдельных файлов и папок из веб-интерфейса, без разворачивания всего бэкапа;
• Образы дисков — полные блочные копии разделов (для Windows — через VSS), из которых можно поднять машину с нуля после отказа диска или полной потери сервера.

Это отличает UrBackup от инструментов вроде restic или BorgBackup, которые закрывают только файловый уровень, но зато делают это со сквозным клиентским шифрованием — сравнение подходов есть в статье про бэкап и восстановление restic. UrBackup имеет смысл ставить, когда бэкапить нужно не один сервер, а десяток-другой машин (виртуалок, физических серверов, рабочих ПК), и вы хотите централизованный обзор состояния бэкапов, а не набор разрозненных cron-задач.

Установка сервера

Сервер UrBackup ставится на выделенную машину — сюда стекаются все бэкапы, поэтому диск и сеть тут важнее CPU. Официальный способ установки на Debian/Ubuntu — самораспаковывающийся .sh-инсталлятор со страницы загрузок проекта (не пакет из стандартного репозитория дистрибутива — версия там обычно старая):

wget -O urbackup-server.sh "<ссылка с текущей версией со страницы Downloads на urbackup.org>"
chmod +x urbackup-server.sh
./urbackup-server.sh

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

После установки сервис поднимается как systemd-юнит:

systemctl status urbackupsrv
systemctl enable --now urbackupsrv

Веб-интерфейс сервера слушает по умолчанию на TCP-порту 55414 (HTTP), а сам обмен бэкапами между клиентами и сервером идёт по TCP 55413. Откройте оба порта в файрволе для сети, из которой будут подключаться клиенты:

ufw allow 55413/tcp
ufw allow 55414/tcp

Если сервер стоит на VPS с публичным IP и клиенты будут подключаться через интернет, а не из локальной сети, есть смысл сразу ограничить доступ к порту 55414 конкретными IP или спрятать веб-интерфейс за обратный прокси с HTTPS — сам UrBackup веб-сервер по умолчанию поднимает обычный HTTP. Требования к диску и сети под такую роль в целом такие же, как для любого бэкап-сервера — они разобраны в статье про подбор ресурсов VPS под бэкапы и архив.

Подключение клиентов: LAN и интернет

На защищаемых машинах ставится клиент — тоже отдельным инсталлятором, для Windows это .exe, для Linux — свой .sh или deb/rpm пакет, в зависимости от дистрибутива. После установки в Linux клиент работает как сервис urbackupclientbackend:

systemctl status urbackupclientbackend

Дальше есть два режима привязки клиента к серверу:

В одной локальной сети — самый простой случай. Клиент рассылает широковещательные UDP-пакеты, сервер их видит и сам предлагает добавить машину в веб-интерфейсе (раздел Status → Discovered). Дополнительная настройка сети не нужна, если между клиентом и сервером нет фильтрации broadcast-трафика.

Через интернет (клиент вне LAN сервера) — актуальный случай, когда сервер бэкапов вынесен на отдельный VPS, а защищаемые машины разбросаны географически. Тут автообнаружение не работает, поэтому клиента настраивают вручную: в веб-интерфейсе сервера создаётся запись клиента с "Internet-режимом" и генерируется ключ авторизации, который затем прописывается в настройках клиента вместе с адресом сервера. Это тот сценарий, где полезно держать сервер бэкапов физически в другой локации от защищаемых машин — если у вас серверы в России, а архив бэкапов вы хотите вынести за рубеж (или наоборот), стоит сверить требования с обзором лучших VPS под бэкапы в России и аналогичными подборками по другим локациям.

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

Файловый бэкап: инкременты и дедупликация

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

Для определения, что изменилось, клиент по возможности использует journal-based отслеживание изменений файловой системы (на Windows — через USN Journal NTFS), а не сравнение по времени модификации каждого файла — это заметно ускоряет обход больших деревьев файлов на последующих бэкапах. На Linux-клиентах, где такого журнала нет, используется побайтовое/похэшевое сравнение, что делает первый и последующие обходы больших файловых деревьев ощутимо медленнее, чем на Windows-клиентах с NTFS.

Требование к хранилищу на сервере — файловая система с полноценной поддержкой хардлинков (ext4, XFS, ZFS, Btrfs подходят; сетевые шары через SMB часто хардлинки не поддерживают или поддерживают с оговорками, это стоит проверить заранее). Указать список каталогов для бэкапа и исключения можно прямо в веб-интерфейсе на вкладке настроек клиента:

Backup paths: /etc; /home; /var/www; /var/lib/mysql
Excluded paths: */node_modules; *.tmp; */cache/*

Базы данных бэкапить "сырыми" файлами на живом сервере рискованно — можно получить несогласованный снапшот при активной записи. Правильный паттерн — logical dump перед файловым бэкапом (mysqldump/pg_dump в файл, который потом попадает в список путей UrBackup), а не расчёт на то, что снапшот файловой системы сам разрулит консистентность.

Образы дисков и восстановление системы

Помимо файлового уровня, UrBackup умеет снимать полные блочные образы разделов — это тот случай, когда нужен не отдельный файл конфига, а вся система целиком после отказа диска или замены сервера. На Windows образ снимается через штатный Volume Shadow Copy Service, поэтому бэкап идёт без остановки сервисов и без блокировки открытых файлов. На Linux-клиентах образ снимается через LVM-снапшот, если раздел лежит на LVM — если тома не в LVM, образный бэкап на Linux ограничен или недоступен, это стоит проверить в документации под конкретную версию клиента перед тем, как полагаться на образы для Linux-машин.

Образы хранятся в собственном формате .vhd/.vhdz сервера, инкрементально — как и с файлами, повторный образ дописывает только изменившиеся блоки, а не пересохраняет диск целиком.

Восстановление образа — отдельная утилита, а не просто "распаковать файл":

• Windows — официальный "UrBackup Restore CD", загрузочный образ на базе Linux, который можно записать на USB или отдать по PXE в сети. Машина загружается с него, подключается к серверу бэкапов и разворачивает выбранный образ прямо на диск — актуально при полной потере системы, когда ОС физически не грузится;
• Точечный доступ к содержимому образа — .vhd/.vhdz можно смонтировать средствами Windows (Disk Management → Attach VHD) или через qemu-nbd/ntfs-3g на Linux, если нужен один файл из образа, а не восстановление всей машины.

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

Хранилище, ретеншн и мониторинг статуса

Без политики хранения бэкапы на сервере будут расти, пока не кончится место. Ретеншн настраивается в веб-интерфейсе отдельно для файловых бэкапов и отдельно для образов — количество хранимых полных/инкрементальных копий и порог свободного места, при достижении которого сервер сам подчищает самые старые снапшоты (Settings → General → Cleanup). Это удобнее ручных find … -mtime +N -delete, но требует того же самого дисциплинарного правила: заложить запас места заранее, а не реагировать постфактум, когда диск уже заполнен под ноль.

Статус каждого клиента виден на главной странице веб-интерфейса цветовой индикацией (успешно / есть проблема / давно не выходил на связь), плюс можно настроить SMTP и получать уведомления на почту при сбое бэкапа конкретного клиента. Если у вас уже есть отдельная система мониторинга инфраструктуры, полезнее не полагаться только на встроенные письма UrBackup, а завести отдельную проверку — например, через SNMP/агент Zabbix на VPS, которая дёргает статус клиентов и алертит, если бэкап конкретной машины не выполнялся дольше ожидаемого интервала. Отдельно стоит следить за местом на самом диске хранилища сервера — типовые грабли с заполнением диска разобраны в статье про мониторинг диска на сервере.

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