Бэкап и восстановление Pi-hole

MAATRIX

Pi-hole ставят на сервер один раз, а потом забывают — работает и работает, режет рекламу и трекеры на уровне DNS для всей сети. Ровно до того момента, пока сервер не упадёт, диск не забьётся или вы не решите перенести Pi-hole на новый VPS. Если бэкапа нет, придётся заново собирать сотни строк в чёрных и белых списках, DHCP-резервации и локальные DNS-записи руками, вспоминая, что вы туда добавляли последние два года. Ниже — рабочая схема, что именно бэкапить, как это автоматизировать и как поднять Pi-hole с нуля из архива без сюрпризов.

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

Pi-hole — это не один файл настроек, а несколько компонентов, и терять можно любой из них по отдельности:

• gravity.db — SQLite-база со списками блокировки (adlists), доменами в чёрном и белом списке, группами клиентов и регулярными выражениями. Пересобирается из adlists автоматически, но ваши ручные правки и группы — нет.
• pihole-FTL.db — база статистики запросов (кто, что и когда спрашивал). Не критична для работы, но жалко терять историю, если вы на неё смотрите.
• pihole.toml (в Pi-hole 6.x) или setupVars.conf (в старых версиях 5.x) — основной конфиг: какой интерфейс слушать, upstream DNS, включён ли DHCP-сервер.
• /etc/dnsmasq.d/ — дополнительные конфиги dnsmasq, если вы что-то туда дописывали руками (в 6.x многое перенесено в pihole.toml, но кастомные фрагменты могут оставаться).
• DHCP-резервации и лизы, если Pi-hole у вас ещё и DHCP-сервер для сети — это отдельная головная боль при потере: устройства могут переехать на другие IP.

Если Pi-hole крутится в Docker (частый вариант на VPS), почти всё это лежит в volume /etc/pihole и /etc/dnsmasq.d — их и нужно бэкапить, а не «settings» внутри контейнера, которые исчезают вместе с ним.

Teleporter: встроенный экспорт и импорт настроек

У Pi-hole есть штатный механизм экспорта — Teleporter. Он живёт в веб-интерфейсе: Settings → Teleporter (в версии 6.x раздел иногда называется просто «Backup» внутри Settings, интерфейс за последний год менялся). Кнопка Export собирает архив .zip с настройками, списками и группами и отдаёт на скачивание браузеру.

Что стоит знать про Teleporter:

• Он переносит конфигурацию, а не полную статистику запросов — историю трафика архив, как правило, не включает.
• Формат архива у Pi-hole 5.x и 6.x различается (в 6.x внутри лежит pihole.toml вместо setupVars.conf), так что архив от старой версии не всегда корректно импортируется в новую — при апгрейде мажорной версии сначала обновите Pi-hole, потом делайте свежий экспорт.
• Импорт делается там же — Settings → Teleporter → Import, загружаете .zip, Pi-hole сам раскладывает файлы и предлагает перезапустить FTL.

Минус ручного Teleporter один: про него легко забыть. Он отлично годится как разовый снимок перед экспериментами («сохранил перед тем как чистить группы»), но как единственная стратегия бэкапа не работает — нужен автоматический вариант ниже.

Если Pi-hole стоит именно ради того, чтобы иметь доступ к веб-интерфейсу из любой точки, разумно поднять к нему рядом WireGuard — заходить в админку и дёргать Teleporter только через свой VPN, а не открывать порт 80/443 в интернет.

Бэкап на уровне файлов и Docker-томов — более надёжный вариант

Для полноценного восстановления системы, а не только настроек, надёжнее бэкапить каталоги целиком.

Если Pi-hole установлен нативно (bare-metal или в LXC):

tar -czf /root/pihole-backup-$(date +%F).tar.gz \
  /etc/pihole \
  /etc/dnsmasq.d \
  /etc/cron.d/pihole

Если Pi-hole в Docker — останавливать контейнер необязательно (SQLite переживает бэкап «на лету» лучше, чем кажется, но при возможности лучше сделать снимок в тихий момент, например ночью через cron):

docker compose stop pihole
tar -czf /root/pihole-backup-$(date +%F).tar.gz \
  -C /opt/pihole etc-pihole etc-dnsmasq.d
docker compose start pihole

Пути etc-pihole и etc-dnsmasq.d — это то, что обычно монтируется как volume в docker-compose.yml:

services:
  pihole:
    image: pihole/pihole:latest
    volumes:
      - './etc-pihole:/etc/pihole'
      - './etc-dnsmasq.d:/etc/dnsmasq.d'
    environment:
      TZ: 'Europe/Moscow'
      FTLCONF_webserver_api_password: 'ваш-пароль'
    ports:
      - '53:53/tcp'
      - '53:53/udp'
      - '80:80/tcp'

Такой tar-архив содержит абсолютно всё: gravity.db, статистику, конфиги, DHCP-лизы. Восстановление — просто распаковать архив обратно на то же место и перезапустить контейнер или FTL-сервис. Это проще и надёжнее, чем Teleporter, если вы переносите Pi-hole целиком на новый сервер той же версии.

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

Бэкап, который лежит на том же диске, что и оригинал, — не бэкап. Если сервер отвалится целиком (диск, провайдер, случайный rm -rf), локальный архив пропадёт вместе с Pi-hole. Минимальная рабочая схема — cron-скрипт, который архивирует конфиги и сразу же увозит архив на другой сервер или в объектное хранилище.

Простой скрипт /usr/local/bin/pihole-backup.sh:

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

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

docker compose -f "$SRC_DIR/docker-compose.yml" stop pihole
tar -czf "$DEST" -C "$SRC_DIR" etc-pihole etc-dnsmasq.d
docker compose -f "$SRC_DIR/docker-compose.yml" start pihole

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

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

Добавляете в cron раз в сутки, ночью:

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

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

Важно: держите минимум одну копию вне сервера, где крутится сам Pi-hole. Если DNS для всей сети лежит на том же VPS, что и бэкап, при падении сервера вы теряете и рабочий DNS, и способ его быстро восстановить.

Восстановление Pi-hole на новом сервере

Порядок действий, если старый сервер недоступен и Pi-hole нужно поднять с нуля на новом VPS:

1. Разверните новый сервер и поставьте Docker, если используете контейнерный вариант — быстрее всего через готовый скрипт с нуля до рабочего Docker.
2. Заберите архив из хранилища: rclone copy remote:pihole-backups/pihole-backup-2026-08-30.tar.gz .
3. Создайте структуру каталогов, идентичную исходной (etc-pihole, etc-dnsmasq.d рядом с docker-compose.yml), и распакуйте архив на место:

   mkdir -p /opt/pihole && cd /opt/pihole
   tar -xzf ~/pihole-backup-2026-08-30.tar.gz

1. Поднимите тот же docker-compose.yml, что был на старом сервере (его тоже стоит держать в бэкапе или в приватном git-репозитории) — docker compose up -d.
2. Проверьте, что FTL подхватил конфиг: docker logs pihole не должен ругаться на повреждённую базу; в веб-интерфейсе списки блокировки и группы должны быть на месте.
3. Обновите upstream на роутере или DHCP-сервере сети — новый Pi-hole почти наверняка получит другой IP, и все клиенты нужно перенаправить на него (или заранее выделить серверу статический/зарезервированный адрес, чтобы IP не менялся при переезде).
4. Если DHCP держал сам Pi-hole — проверьте резервации отдельно, они восстанавливаются вместе с конфигом, но стоит свериться руками хотя бы по паре устройств.

Если вы восстанавливались через Teleporter, а не через файловый бэкап: сначала ставите чистый Pi-hole нужной версии, потом Settings → Teleporter → Import с вашим архивом, и уже поверх — донастраиваете то, что архив мог не унести (например, DHCP, если функция была выключена на момент экспорта).

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

• Восстановили архив от Pi-hole 5.x в свежепоставленный 6.x — конфиг не подхватился. Формат конфигурации изменился между мажорными версиями (setupVars.conf → pihole.toml). Обновляйте версию отдельно от восстановления конфига: сначала апгрейд на старом сервере до актуальной версии, потом свежий бэкап.
• Архив сделан «на живую» без остановки контейнера, и gravity.db оказалась повреждена. SQLite обычно переживает копирование во время работы, но не гарантированно — если после восстановления Pi-hole не стартует или список доменов пустой, лучше сразу перейти на схему с кратким docker compose stop перед архивацией, как в примере выше.
• Бэкапится только gravity.db, а pihole.toml/setupVars.conf забыли. Список доменов восстановился, но пропали настройки upstream DNS и интерфейса — Pi-hole поднимается «пустым» по конфигу. Бэкапьте каталог целиком, а не отдельные файлы, которые кажутся важными.
• DHCP-лизы не перенесли, и после переезда часть устройств получила новые IP. Если Pi-hole — единственный DHCP в сети, добавьте в бэкап dhcp.leases (или сверьтесь, что весь /etc/pihole уехал целиком).
• Бэкап лежит на том же VPS. Самая частая ошибка вообще в теме бэкапов, не только для Pi-hole — при потере сервера теряется и архив. rclone/scp на второй сервер решает это за десять строк в cron-скрипте.

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