UrBackup в Docker Compose: готовый файл

MAATRIX

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

Чем UrBackup отличается от restic и BorgBackup

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

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

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

Расплата — сам сервис тяжелее одного бинарника: нужна база, нужен отдельный диск под хранилище, нужно продумать сеть. Если у вас один сервер и его нужно бэкапить самого себя — restic или Borg проще и легче. Если у вас парк из десятка машин (в том числе на разных локациях — Россия, США, Великобритания) и хочется одну точку контроля — UrBackup окупает свою тяжеловесность.

Готовый docker-compose.yml

Официальный образ поддерживает сам автор проекта, uroni/urbackup-server. Конфигурация и база живут в одном томе, тело бэкапов — в другом, отдельном от системного диска:

services:
  urbackup:
    image: uroni/urbackup-server:latest
    container_name: urbackup-server
    restart: unless-stopped
    ports:
      - "55414:55414"        # веб-интерфейс, HTTP
      - "55415:55415"        # веб-интерфейс, служебный порт
      - "55413:55413"        # приём бэкапов от клиентов
      - "35623:35623/udp"    # автообнаружение клиентов в локальной сети
    volumes:
      - ./urbackup-config:/var/urbackup
      - /mnt/backup-storage:/backups
      - /etc/localtime:/etc/localtime:ro
    environment:
      - TZ=Europe/Moscow

/mnt/backup-storage — это отдельный смонтированный диск, а не подкаталог на системном разделе: хранилище бэкапов растёт быстро и непредсказуемо, и вы не хотите, чтобы забитый диск уронил заодно и веб-панель. Проверьте актуальный тег образа на Docker Hub перед разворачиванием — версию сервера в latest я вам называть не буду, чтобы не соврать: к моменту, когда вы это читаете, она наверняка уже другая.

Поднимаете так же, как любой другой стек:

mkdir -p urbackup-config
docker compose up -d
docker compose logs -f urbackup

После первого запуска панель открывается на http://<IP-сервера>:55414. Первым делом — учётная запись администратора с нормальным паролем: по умолчанию доступ может быть вообще без пароля, и оставлять так даже на пять минут не стоит.

Порты и сеть: локальная автодискавери vs Internet Mode

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

Для этого сценария в UrBackup есть режим Internet Mode: клиент не ждёт, пока его найдут по broadcast, а сам инициирует шифрованное соединение на сервер по TCP 55413 с аутентификацией по ключу. Это ровно то, что нужно, когда сервер бэкапов стоит на арендованном VPS, а бэкапить нужно машины в разных офисах или на разных площадках.

Включается так:

1. В веб-панели: Settings → Internet Mode/Internet Clients — включить Internet Mode.
2. Там же добавить клиента, задать ему имя и сгенерировать authentication key — уникальный секрет для этой машины.
3. При установке агента на удалённой машине указать адрес сервера, порт 55413 и этот ключ.

Порт 55414/55415 (веб-панель) наружу лучше не светить всему интернету без дополнительной защиты — ниже отдельно про это.

Подключение клиентов: Windows и Linux

На Windows агент ставится обычным инсталлятором с сайта проекта — в мастере установки указываете «Internet/active mode», вбиваете адрес сервера и ключ из панели. После этого клиент появится в списке на сервере со статусом онлайн, и по расписанию начнёт стучаться сам.

На Linux (Debian/Ubuntu) — через официальный репозиторий проекта:

wget -O - https://hndl.urbackup.org/Client/Add-Repo/urbackup.gpg.key | gpg --dearmor -o /usr/share/keyrings/urbackup.gpg
echo "deb [signed-by=/usr/share/keyrings/urbackup.gpg] https://hndl.urbackup.org/Client/Add-Repo/ /" | tee /etc/apt/sources.list.d/urbackup.list
apt update && apt install urbackup-client

После установки Internet Mode на клиенте настраивается через urbackupclientctl или конфиг-файл клиента (точный путь и синтаксис уточните для установленной у вас версии командой man urbackupclientctl — между релизами он немного менялся). Логика та же: адрес сервера, порт 55413, ключ.

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

Хранилище: диск, дедупликация, расписания

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

Что можно контролировать:

• Файловая система тома с бэкапами. UrBackup умеет использовать снапшоты и reflink-копии на BTRFS и ZFS — это резко снижает расход места на инкрементальные копии по сравнению с обычным ext4, где дедупликация делается через хардлинки на уровне приложения. Если ожидаете большой парк клиентов — закладывайте BTRFS или ZFS под том с бэкапами сразу, менять ФС «на живую» под растущим хранилищем неприятно.
• Группы клиентов и расписания. В Settings по умолчанию задаётся, как часто снимать инкрементальные и полные копии и сколько версий хранить. Разумно завести отдельные группы для «критичных серверов» (чаще, больше версий) и «рабочих станций» (реже, меньше версий) — конфигурация на сервере, а не на каждом клиенте.
• Полосу пропускания. Первый бэкап каждого клиента — полный, и он может быть увесистым. Если сервер бэкапов и бэкапируемые машины стоят в разных странах, это трафик через границу с соответствующей задержкой и стоимостью. Логичный вариант — держать сервер бэкапов в той же локации, что и основной парк серверов (например, свой сервер бэкапов в России под российский парк, отдельный в США под американский), а не гонять полные копии через океан каждую ночь.

Восстановление: файлы и целые образы

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

Восстановление образа диска — процедура посерьёзнее. UrBackup генерирует загрузочный Restore CD/USB (ISO-образ, который вы записываете на флешку). Машину, которую нужно восстановить, загружают с этой флешки, Restore-среда находит сервер бэкапов по сети (в локальной сети — автоматически, из другой сети — по указанному вручную адресу и порту 55413), показывает список доступных образов клиента, и вы выбираете, какой раскатать. Это по сути full bare-metal restore — работает и когда сама ОС на машине не грузится вовсе.

Отдельно стоит хотя бы раз — не дожидаясь реальной аварии — прогнать тестовое восстановление на запасной машине или в виртуалке. Разница между «бэкапы вроде идут зелёным» и «бэкапы реально восстанавливаются» выясняется обычно в худший момент.

Безопасность и офсайт-копия хранилища

Несколько вещей, которые стоит закрыть сразу после разворачивания:

• Смените пароль администратора веб-панели в первую же минуту после старта — это первое, что проверяют боты сканирования при появлении нового порта в интернете.
• Не открывайте 55414/55415 всему миру без необходимости. Разумные варианты: ограничить доступ фаерволом по списку ваших IP, повесить веб-панель за nginx как reverse proxy с TLS и дополнительной базовой аутентификацией, либо вообще держать панель доступной только через VPN.
• Порт 55413 (приём бэкапов) держите открытым — это рабочий канал для Internet Mode клиентов, ограничивать его списком IP смысла обычно нет, поскольку клиенты сами по себе аутентифицируются ключом.

И главное: сервер с UrBackup сам становится единой точкой отказа для всего парка бэкапов. Если сгорит диск именно этого сервера — вы потеряете не только текущие данные клиентов, но и всю их историю бэкапов разом. Реплицируйте содержимое /backups на внешнее хранилище — например, регулярным rclone sync в S3-совместимое хранилище (готовый rclone в Docker Compose под эту задачу), либо в MinIO на отдельном сервере. Да, бэкап бэкапов звучит избыточно, пока не станет единственным, что у вас осталось.

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

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