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

MAATRIX

Dashy — не просто список ссылок: под капотом у него статус-мониторинг десятков подключённых сервисов, виджеты с живыми данными и, часто, конфиг, который правился неделями через встроенный UI-редактор, а не руками в YAML. Именно поэтому его потеря особенно обидна — восстановить по памяти, какие URL стояли в проверках статуса и какие API-ключи были в виджетах погоды или курса валют, объективно тяжелее, чем воссоздать простой список закладок. Ниже — рабочая схема бэкапа и восстановления Dashy: что копировать, как автоматизировать и на что обратить внимание именно из-за статус-чеков и виджетов.

Что нужно бэкапить в Dashy

Основа конфигурации Dashy — файл conf.yml. В зависимости от версии образа и того, как вы разворачивали контейнер, он может лежать по пути /app/public/conf.yml или, в более новых сборках, в каталоге /app/user-data/conf.yml — сверьтесь со своим docker-compose.yml, чтобы знать точный путь на хосте. Вокруг него обычно есть ещё несколько важных объектов:

dashy-data/
├── conf.yml            # секции, элементы (items), статус-чеки, виджеты
├── pages/               # доп. страницы, если используете multi-page
│   ├── work.yml
│   └── home.yml
├── users.yml             # список пользователей и хеши паролей (если включена auth)
├── item-icons/            # локально загруженные кастомные иконки
├── custom.css              # кастомные стили
└── custom.js                # кастомный JS (если используете)

Отдельная особенность Dashy — встроенный редактор конфигурации прямо в интерфейсе: изменения, сделанные через UI (добавили карточку, поправили виджет), записываются обратно в conf.yml на диске, а не только в памяти браузера. Это удобно, но означает, что конфиг может измениться в любой момент без вашего явного git commit — бэкап «руками, когда вспомнил» здесь работает хуже, чем регулярный автоматический.

Секретов в конфиге Dashy обычно больше, чем в статичных дашбордах: API-ключи погодных и курсовых виджетов (apiKey в блоке widgets), заголовки авторизации для статус-чеков внутренних сервисов (statusCheckHeaders), иногда — токены для приватных Docker-реестров, если используете виджет docker-stats. Хеши паролей из users.yml тоже не должны лежать в открытом доступе. Всё это — повод либо шифровать бэкап, либо держать его в приватном хранилище с ограниченным доступом.

Ручной бэкап конфигурации

Быстрее всего — обычный tar каталога с данными:

mkdir -p /opt/backups/dashy
tar -czf /opt/backups/dashy/dashy-config-$(date +%Y%m%d-%H%M%S).tar.gz \
  -C /opt/dashy dashy-data

Проверка, что архив не пустой и читается:

tar -tzf /opt/backups/dashy/dashy-config-*.tar.gz | head -20

Для регулярности — задача в cron с ротацией последних 14 копий:

crontab -e

0 3 * * * /usr/bin/tar -czf /opt/backups/dashy/dashy-config-$(date +\%Y\%m\%d).tar.gz -C /opt/dashy dashy-data && find /opt/backups/dashy -name '*.tar.gz' -mtime +14 -delete

Такой бэкап решает основной сценарий — сломали конфиг правкой или удалили карточку по ошибке. Но если он лежит на том же диске, что и сам сервер, отказ диска убьёт и оригинал, и копию. Доставку наружу можно решить через rclone в объектное хранилище или rsync на второй сервер — либо через отдельный механизм restic ниже.

Отдельно стоит знать, что у Dashy есть встроенная функция облачного бэкапа в настройках интерфейса (Settings → Config → Cloud Backup): конфиг шифруется на стороне клиента и сохраняется на стороннем сервисе разработчика по сгенерированным ID и паролю, откуда его можно потом восстановить на любой установке. Это удобно для быстрого переноса между машинами, но полагаться на неё как на единственный бэкап не стоит — сервис вне вашего контроля, и для продакшн-сценария нужна независимая копия на своей инфраструктуре.

Автоматический бэкап через restic

Из-за API-ключей виджетов и заголовков авторизации статус-чеков конфиг Dashy стоит бэкапить с шифрованием, даже если он занимает пару мегабайт. Если restic уже развёрнут для других сервисов — просто добавьте каталог Dashy в общий репозиторий; если ещё нет, у нас есть отдельный разбор — как установить и настроить restic на VPS с инициализацией репозитория и первым бэкапом.

Бэкап с тегом для удобного поиска снапшотов:

export RESTIC_PASSWORD='ваш-пароль-репозитория'
restic backup /opt/dashy/dashy-data \
  --repo /mnt/backup-storage/restic-repo \
  --tag dashy

Политика хранения — например, 7 дневных, 4 недельных, 6 месячных снапшотов:

restic forget --repo /mnt/backup-storage/restic-repo \
  --tag dashy \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6 \
  --prune

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

Бэкап при развёртывании через Docker Compose

Типовой docker-compose.yml для Dashy монтирует каталог с данными как volume — это и есть точка входа для бэкапа:

services:
  dashy:
    image: lissy93/dashy:latest
    container_name: dashy
    ports:
      - 4000:8080
    volumes:
      - ./dashy-data:/app/user-data
    environment:
      - NODE_ENV=production
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "node", "/app/services/healthcheck"]
      interval: 60s

Здесь ./dashy-data — обычная директория на хосте, и бэкапить её можно теми же средствами, что и любой другой конфиг: tar, restic, rsync. Специфика есть только в одном: официальный образ Dashy обычно работает не от root внутри контейнера, поэтому после восстановления файлов из tar-архива (где владелец часто становится root) встроенный UI-редактор может потерять возможность сохранять изменения на диск. Если после восстановления интерфейс открывается, но правки через редактор не сохраняются — проверьте владельца файлов в dashy-data и приведите его в соответствие с пользователем, под которым запущен процесс в образе (актуальный UID проще всего посмотреть через docker exec dashy id).

Как и с другими самостоятельно развёрнутыми сервисами, не бэкапьте контейнер целиком через docker commit — это раздувает образ и не даёт нормально версионировать изменения конфига. Обновление образа и бэкап данных — разные операции: docker compose pull && docker compose up -d для образа, копирование dashy-data для конфигурации.

Восстановление из бэкапа

Из tar-архива, на том же сервере после сбоя:

cd /opt/dashy
docker compose down
mv dashy-data dashy-data.broken-$(date +%Y%m%d)
tar -xzf /opt/backups/dashy/dashy-config-20260830.tar.gz
docker compose up -d

Контейнер стоит останавливать перед заменой файлов — Dashy кеширует часть конфигурации в рантайме, и подмена conf.yml «на живую» иногда приводит к рассинхрону между тем, что видно в браузере, и тем, что реально лежит на диске, до перезапуска.

Из restic:

export RESTIC_PASSWORD='ваш-пароль-репозитория'
restic restore latest --repo /mnt/backup-storage/restic-repo \
  --tag dashy \
  --target /opt/dashy-restored

Restic сохраняет полный исходный путь, поэтому файлы окажутся в /opt/dashy-restored/opt/dashy/dashy-data — остаётся скопировать содержимое на место и перезапустить контейнер:

cp -r /opt/dashy-restored/opt/dashy/dashy-data/* /opt/dashy/dashy-data/
docker compose restart dashy

Перенос на новый сервер: помимо самих файлов проверьте отдельно три вещи. Во-первых, DNS и reverse proxy, если Dashy смотрит наружу через домен (см. Traefik как reverse proxy для Docker) — без этого статус-чеки внешних сервисов будут выполняться, но сам дашборд будет недоступен по привычному адресу. Во-вторых, сетевую доступность целей статус-мониторинга: если statusCheckUrl указывают на внутренние адреса вида http://10.x.x.x:port или на имена контейнеров в другой Docker-сети, на новом сервере эти адреса нужно будет привести в соответствие с новой топологией. В-третьих, если у вас параллельно настроен более полноценный мониторинг доступности — например, Uptime Kuma — сверьте, что оба инструмента после переезда смотрят на одни и те же актуальные адреса, а не на устаревшие из старой инфраструктуры.

После запуска не пугайтесь, если все статус-индикаторы первые секунды или минуты показывают «checking...» или серый цвет вместо зелёного/красного — это штатное поведение: Dashy не хранит историю статусов между перезапусками, каждый чек выполняется заново по расписанию из statusCheckInterval, и первый результат появится только после первого цикла опроса.

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

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