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

MAATRIX

Unbound почти всегда ставят один раз — как локальный рекурсивный резолвер рядом с Pi-hole или AdGuard Home, чтобы не зависеть от чужого DNS и получать честную валидацию DNSSEC. Конфиг после первой настройки почти не трогают, поэтому про бэкап забывают в первую очередь — до того момента, пока сервер не упадёт или вы не решите переехать на новый VPS. Восстановить Unbound «на глаз» несложно (это не база данных с гигабайтами состояния), но легко забыть один нюанс — от прав на файл DNSSEC-якоря до chroot-пути, унаследованного с другой ОС, — и получить резолвер, который не стартует или молча перестаёт проверять подписи. Ниже — что именно бэкапить, как это автоматизировать и как поднять Unbound с нуля так, чтобы DNSSEC и локальные зоны заработали сразу.

Что именно нужно бэкапить в Unbound

В отличие от Pi-hole или AdGuard Home, у Unbound нет базы со списками — весь смысл резолвера в конфигурации и нескольких служебных файлах:

• /etc/unbound/unbound.conf и **/etc/unbound/unbound.conf.d/*.conf — основной конфиг и все подключённые фрагменты: слушающие интерфейсы, access-control (кому разрешено слать запросы), forward-zone на случай, если часть доменов уходит на другой резолвер, и, самое ценное, ваши ручные local-zone/local-data** — локальные переопределения DNS для домашней сети или внутренних сервисов.
• /var/lib/unbound/root.key — файл автоматически обновляемого DNSSEC-якоря (trust anchor). Без него или при его повреждении Unbound либо не проверяет подписи, либо вовсе не стартует, если в конфиге включён auto-trust-anchor-file.
• unbound_control.pem / unbound_control.key / unbound_server.pem (обычно в /etc/unbound/) — TLS-ключи для unbound-control, если вы настраивали удалённое управление через unbound-control-setup.
• /var/lib/unbound/root.hints — список корневых серверов. Файл не критичен: его в любой момент можно перекачать заново с IANA, но если вы держите его локально и обновляете по расписанию, стоит включить в архив для скорости восстановления.
• Кэш резолвера бэкапить не нужно — он живёт в памяти процесса и пересобирается сам за первые минуты работы после старта.

Если Unbound крутится в Docker (образы вроде mvance/unbound или klutchell/unbound), всё перечисленное обычно лежит в одном смонтированном каталоге, например /opt/unbound/etc:/etc/unbound — бэкапить нужно именно host-каталог, а не то, что видно внутри контейнера.

Где искать файлы: разница между Ubuntu/Debian и Docker-установкой

На Ubuntu 24.04 и Debian 12 пакет unbound из репозитория раскладывает файлы предсказуемо:

/etc/unbound/unbound.conf                      # главный конфиг, обычно только include
/etc/unbound/unbound.conf.d/                    # рабочие фрагменты конфигурации
/var/lib/unbound/root.key                       # DNSSEC trust anchor, владелец — unbound:unbound
/var/lib/unbound/root.hints                      # корневые серверы (если скачивали руками)

Обновление root.key на Ubuntu/Debian делает systemd-таймер unbound-anchor.timer, который дёргает unbound-anchor -a /var/lib/unbound/root.key — проверьте systemctl list-timers | grep unbound, если таймера нет, обновление якоря придётся брать на себя через cron.

В Docker-варианте структура плоская — весь конфиг и root.key обычно лежат в одном примонтированном каталоге:

services:
  unbound:
    image: mvance/unbound:latest
    volumes:
      - './etc-unbound:/opt/unbound/etc/unbound'
    ports:
      - '53:53/tcp'
      - '53:53/udp'
    restart: unless-stopped

Здесь бэкапить нужно каталог ./etc-unbound целиком — в нём и конфиги, и root.key, и, если настраивали, control-ключи.

Ручной бэкап: полная копия конфигурации и DNSSEC-якоря

Для нативной установки (bare-metal или LXC) достаточно одного tar-архива, Unbound останавливать не обязательно — файлы небольшие и статичные, конфликтов при чтении практически не бывает:

tar -czf /root/unbound-backup-$(date +%F).tar.gz \
  /etc/unbound \
  /var/lib/unbound/root.key \
  /var/lib/unbound/root.hints 2>/dev/null

Флаг 2>/dev/null в конце — на случай, если root.hints у вас не скачан локально (Unbound по умолчанию использует встроенный список корневых серверов и без этого файла прекрасно работает).

Для Docker-варианта архивируйте примонтированный каталог с хоста, дополнительно ничего останавливать не нужно:

tar -czf /root/unbound-backup-$(date +%F).tar.gz \
  -C /opt/unbound etc-unbound

Если вы настраивали unbound-control для удалённого мониторинга или ручных unbound-control flush_zone, добавьте в архив ключи явно — они не всегда лежат в /etc/unbound, проверьте путь в самом конфиге по директиве control-key-file / control-cert-file:

grep -E 'control-(key|cert)-file' /etc/unbound/unbound.conf.d/*.conf

Готовый архив стоит сразу проверить на валидность синтаксиса конфига внутри — распакуйте во временную папку и прогоните через unbound-checkconf, не дожидаясь реального восстановления:

mkdir /tmp/unbound-check && tar -xzf unbound-backup-2026-08-30.tar.gz -C /tmp/unbound-check
unbound-checkconf /tmp/unbound-check/etc/unbound/unbound.conf

Автоматизация бэкапов по расписанию

Конфиг Unbound меняется редко, но именно поэтому про ручной бэкап забывают месяцами — cron-скрипт с отправкой архива на другой сервер закрывает вопрос раз и навсегда. Скрипт /usr/local/bin/unbound-backup.sh:

#!/usr/bin/env bash
set -euo pipefail

DATE=$(date +%F)
DEST="/root/unbound-backup-${DATE}.tar.gz"

tar -czf "$DEST" \
  /etc/unbound \
  /var/lib/unbound/root.key 2>/dev/null

# отправка на удалённое хранилище
rclone copy "$DEST" remote:unbound-backups/

# чистим локальные архивы старше 30 дней
find /root -name 'unbound-backup-*.tar.gz' -mtime +30 -delete

В cron — раз в неделю ночью достаточно, конфиг Unbound не меняется каждый день:

0 4 * * 0 /usr/local/bin/unbound-backup.sh >> /var/log/unbound-backup.log 2>&1

rclone увозит архив на S3-совместимое хранилище, Backblaze B2 или второй сервер по SFTP за одну команду. Если Unbound стоит рядом с Pi-hole или AdGuard Home на одном VPS (частый набор), логичнее бэкапить оба сервиса одним скриптом и, при желании версионирования вместо простой перезаписи, посмотреть в сторону BorgBackup — для крошечного конфига Unbound это избыточно само по себе, но если тот же job архивирует и другие сервисы сервера, единая система удобнее набора разрозненных tar-архивов. Общий подход к организации автоматических бэкапов на сервере — в статье про автоматические бэкапы с нуля.

Как и с любым бэкапом: минимум одна копия должна лежать не на том сервере, где крутится сам Unbound. Если резолвер и его архив на одном диске, при потере VPS вы теряете и рабочий DNS, и способ его быстро вернуть.

Восстановление Unbound на новом сервере

Порядок действий при переезде на новый VPS или после полной потери старого:

1. Поставьте пакет на новом сервере: apt install unbound (Ubuntu/Debian) — это создаст пользователя unbound и базовую структуру каталогов, поверх которой вы развернёте свой конфиг.
2. Остановите службу перед заменой файлов: systemctl stop unbound.
3. Заберите архив из хранилища: rclone copy remote:unbound-backups/unbound-backup-2026-08-30.tar.gz .
4. Распакуйте архив поверх системных путей, сохраняя структуру:

   tar -xzf unbound-backup-2026-08-30.tar.gz -C /

1. Восстановите права — это самый частый источник проблем после восстановления. Unbound работает от пользователя unbound, а tar при распаковке из-под root мог выставить владельцем root:

   chown -R unbound:unbound /var/lib/unbound
   chmod 644 /var/lib/unbound/root.key

1. Проверьте синтаксис перед стартом: unbound-checkconf — если в архиве был конфиг с другого дистрибутива, здесь чаще всего и всплывает разница в путях (например, директива chroot, которая на одних сборках указывает на /etc/unbound, а на других отключена пустой строкой — несовпадающий путь роняет запуск с ошибкой про недоступный каталог).
2. Запустите службу: systemctl start unbound и сразу проверьте лог: journalctl -u unbound -n 50.
3. Проверьте резолвинг и DNSSEC до того, как переключать на новый Unbound другие сервисы (Pi-hole, AdGuard Home, клиентов сети):

   dig @127.0.0.1 example.com
   dig +dnssec sigok.verteiltesysteme.net @127.0.0.1   # должен пройти, флаг ad в ответе
   dig +dnssec sigfail.verteiltesysteme.net @127.0.0.1  # должен вернуть SERVFAIL

Если оба теста ведут себя как ожидается — валидация DNSSEC работает, можно переключать upstream в Pi-hole/AdGuard Home на новый IP.

Если файла root.key в бэкапе не оказалось или он вызывает сомнения (давно не обновлялся, восстановлен с очень старого архива) — не тратьте время на разбирательство, проще пересоздать якорь заново штатной командой:

unbound-anchor -a /var/lib/unbound/root.key
chown unbound:unbound /var/lib/unbound/root.key

Она проверяет цепочку доверия через встроенный сертификат ICANN и создаёт корректный файл с нуля — это не хуже восстановленной копии, а иногда и надёжнее.

Частые проблемы при бэкапе и восстановлении

• После восстановления Unbound не стартует, в логе ошибка про chroot. Конфиг был перенесён с другого дистрибутива или другой версии пакета, где директива chroot: указывает на путь, которого нет на новом сервере. Проверьте chroot в unbound.conf — либо создайте нужный каталог, либо явно пропишите chroot: "", чтобы отключить chroot.
• root.key на месте, но DNSSEC не проверяется (флага ad нет в ответах). Чаще всего это неверные права — файл принадлежит root вместо unbound, и процесс не может его перечитать при обновлении. chown unbound:unbound /var/lib/unbound/root.key решает почти всегда.
• **Восстановили только unbound.conf, но забыли unbound.conf.d/*.conf.** Основной файл на Ubuntu/Debian обычно состоит из одного include, вся реальная конфигурация — во фрагментах. Бэкапьте каталог /etc/unbound целиком, а не отдельные файлы, которые кажутся главными.
• Local-zone правила пропали после переезда. Если ручные local-data лежали в отдельном файле вне /etc/unbound/unbound.conf.d/ (например, в домашней директории или произвольном пути), архив по стандартному пути его не захватит. Проверьте include: директивы в конфиге на предмет путей за пределами стандартной структуры.
• Резолвер стартовал, но клиенты получают REFUSED. Обычно это не связано с бэкапом напрямую — новый сервер получил другой IP, а access-control в конфиге разрешает запросы только с адресов старой сети. Проверьте и при необходимости расширьте access-control: под актуальную подсеть.

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