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

MAATRIX

Navidrome превращает папку с музыкой в личный Spotify: плейлисты, обложки, статистика прослушиваний, доступ с телефона и колонки через любой Subsonic-клиент. Проблема в том, что почти всё это живёт не в mp3-файлах, а в одной SQLite-базе — и если она повреждается или диск сервера умирает, вы теряете не музыку (её можно перекачать), а годы плейлистов, лайков и истории прослушивания. Разберём, что именно бэкапить, как сделать это автоматически и как поднять Navidrome заново на чистом сервере за 10 минут.

Что на самом деле нужно бэкапить

У Navidrome три категории данных, и они по-разному критичны.

База данных (navidrome.db, SQLite) — самое важное. В ней хранятся:

• пользователи и пароли (хэши);
• плейлисты и умные плейлисты;
• избранное, рейтинги, счётчики прослушиваний;
• закладки (позиции в аудиокнигах/подкастах);
• кэш метаданных — но его Navidrome пересоберёт из тегов сам.

Если база потеряна, вы не потеряете музыку, но потеряете всю историю и плейлисты — их придётся собирать заново вручную.

Файл конфигурации (navidrome.toml или переменные окружения) — без него легко восстановить сервис, но неудобно: пароли к прокси, пути, кастомные настройки транскодирования снова придётся вводить руками.

Сама музыкальная библиотека — обычно самая большая по объёму, но и самая легко восстановимая: это ваши исходные файлы, которые чаще всего лежат ещё где-то (NAS, внешний диск, облако). Полный бэкап библиотеки нужен только если сервер — единственное место хранения музыки, что на практике бывает редко.

Отдельно: обложки альбомов, которые Navidrome сам вытащил из тегов или скачал, лежат в кэше (data/cache) — их можно не бэкапить, они пересоздаются автоматически при следующем сканировании.

Где лежат данные в разных вариантах установки

Расположение файлов зависит от способа запуска — это первое, что нужно проверить перед настройкой бэкапа.

Если вы разворачивали через docker-compose.yml, посмотрите, что смонтировано в /data:

services:
  navidrome:
    image: deluan/navidrome:latest
    ports:
      - "4533:4533"
    volumes:
      - ./navidrome-data:/data
      - /path/to/music:/music:ro
    environment:
      ND_SCANSCHEDULE: 1h
      ND_LOGLEVEL: info
      ND_SESSIONTIMEOUT: 24h
      ND_BASEURL: ""

Если вместо ./navidrome-data:/data у вас именованный volume (navidrome_data:/data), найдите его физический путь:

docker volume inspect navidrome_data | grep Mountpoint
# "Mountpoint": "/var/lib/docker/volumes/navidrome_data/_data"

Это и есть каталог, который нужно бэкапить.

Бэкап базы данных SQLite (правильный способ)

Копировать navidrome.db простым cp во время работы сервиса — плохая идея: SQLite может писать в файл в момент копирования, и вы получите повреждённую копию (особенно если включён WAL-режим — тогда данные частично лежат в navidrome.db-wal). Есть два надёжных варианта.

Вариант 1 — остановить сервис на секунду. Проще всего и без рисков:

docker compose stop navidrome
cp /path/to/navidrome-data/navidrome.db /backup/navidrome-$(date +%F).db
docker compose start navidrome

Простой на музыку у пользователей — доли секунды, для домашнего сервера это некритично.

Вариант 2 — «горячий» бэкап через sqlite3 .backup. Если Navidrome должен работать без пауз (например, несколько человек слушают одновременно), используйте встроенную команду SQLite, которая безопасна для консистентности даже без остановки сервиса:

sqlite3 /path/to/navidrome-data/navidrome.db ".backup /backup/navidrome-$(date +%F).db"

Эта команда делает атомарный снимок базы через SQLite API, а не через файловую систему — WAL-файл учитывается корректно. Именно так и стоит бэкапить SQLite-приложения на постоянной основе.

Автоматизация: скрипт + cron

Собираем полный скрипт, который бэкапит базу, конфиг и обложки-кэш (по желанию), сжимает архив и чистит старые копии.

#!/usr/bin/env bash
# /opt/scripts/navidrome-backup.sh
set -euo pipefail

SRC_DIR="/opt/navidrome/navidrome-data"
DB_FILE="$SRC_DIR/navidrome.db"
BACKUP_DIR="/backup/navidrome"
DATE=$(date +%F_%H%M)
KEEP_DAYS=14

mkdir -p "$BACKUP_DIR"

# Горячий снимок базы без остановки сервиса
sqlite3 "$DB_FILE" ".backup '$BACKUP_DIR/navidrome-$DATE.db'"

# Конфиг (если хранится отдельным файлом)
[ -f "$SRC_DIR/navidrome.toml" ] && cp "$SRC_DIR/navidrome.toml" "$BACKUP_DIR/navidrome-$DATE.toml"

# Упаковываем базу+конфиг в один архив, чистим исходники
tar -czf "$BACKUP_DIR/navidrome-$DATE.tar.gz" \
  -C "$BACKUP_DIR" "navidrome-$DATE.db" $( [ -f "$SRC_DIR/navidrome.toml" ] && echo "navidrome-$DATE.toml" )
rm -f "$BACKUP_DIR/navidrome-$DATE.db" "$BACKUP_DIR/navidrome-$DATE.toml"

# Удаляем архивы старше KEEP_DAYS дней
find "$BACKUP_DIR" -name "navidrome-*.tar.gz" -mtime +$KEEP_DAYS -delete

echo "Бэкап Navidrome готов: $BACKUP_DIR/navidrome-$DATE.tar.gz"

Делаем исполняемым и ставим в cron на ежедневный запуск ночью:

chmod +x /opt/scripts/navidrome-backup.sh
crontab -e
# Каждый день в 4:15 утра
15 4 * * * /opt/scripts/navidrome-backup.sh >> /var/log/navidrome-backup.log 2>&1

Архив с базой обычно весит от пары мегабайт до пары десятков — даже с ежедневным хранением за 2 недели это несущественная нагрузка на диск. Если хотите более серьёзную схему хранения версий (retention с недельными/месячными срезами) и заодно бэкапить саму библиотеку, логичнее подключить restic — он умеет дедупликацию, шифрование и выгрузку во внешнее хранилище одной командой.

Выгрузка бэкапа за пределы сервера

Бэкап, который лежит на том же диске, что и рабочие данные, не спасает от отказа диска или сервера целиком — это база правил бэкапирования (правило 3-2-1: минимум 3 копии, минимум 2 разных носителя, минимум 1 копия вне сервера). Дешёвый способ дожать схему — синхронизировать каталог бэкапов на второй сервер или в объектное хранилище.

Через rclone в S3-совместимое хранилище (Backblaze B2, Selectel, свой MinIO):

rclone sync /backup/navidrome remote:navidrome-backups --transfers 4

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

Если у вас уже настроен общий бэкап сервера (например, автоматические бэкапы на Ubuntu 24.04), можно просто включить /opt/navidrome/navidrome-data в список каталогов общего скрипта — тогда отдельный планировщик для Navidrome не нужен, он поедет вместе со всем остальным.

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

Сценарий: старый сервер умер (или вы просто переезжаете на новый VPS), музыка лежит отдельно на NAS/облаке, есть только архив бэкапа базы.

Шаг 1. Поднимаем новый сервер и Docker.

curl -fsSL https://get.docker.com | sh
mkdir -p /opt/navidrome/navidrome-data

Шаг 2. Копируем архив бэкапа и распаковываем.

scp backup-server:/backup/navidrome/navidrome-2026-08-30_0415.tar.gz /tmp/
tar -xzf /tmp/navidrome-2026-08-30_0415.tar.gz -C /opt/navidrome/navidrome-data/
mv /opt/navidrome/navidrome-data/navidrome-2026-08-30_0415.db /opt/navidrome/navidrome-data/navidrome.db

Если бэкапился и navidrome.toml — переименуйте его аналогично, уберите дату из имени.

Шаг 3. Восстанавливаем (или заново монтируем) музыкальную библиотеку. Если файлы лежали на отдельном диске или NAS, просто примонтируйте тот же путь на новом сервере. Если библиотеки нет и её нужно восстанавливать из другого бэкапа — сделайте это до первого запуска Navidrome, чтобы сканирование сразу нашло все треки и правильно сопоставило их с записями из базы (Navidrome сверяет треки по пути и хэшу, поэтому важно, чтобы пути внутри контейнера совпадали с тем, что было раньше).

Шаг 4. Поднимаем docker-compose с теми же путями монтирования.

services:
  navidrome:
    image: deluan/navidrome:latest
    restart: unless-stopped
    ports:
      - "4533:4533"
    volumes:
      - ./navidrome-data:/data
      - /path/to/music:/music:ro

docker compose up -d
docker compose logs -f navidrome

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

Шаг 5. Проверка целостности. Зайдите в веб-интерфейс, откройте «Настройки → О программе» — версия и статистика библиотеки должны отобразиться. Затем откройте один из плейлистов, созданных до сбоя — если он на месте, восстановление прошло успешно.

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

• Пути к музыке не совпадают. Если раньше библиотека монтировалась как /music, а на новом сервере вы указали /media/music, Navidrome не найдёт файлы по путям из базы и пометит все треки как отсутствующие. Либо сохраняйте те же пути монтирования, либо (в новых версиях Navidrome) используйте настройку ND_MUSICFOLDER, а после переезда запустите полное пересканирование с очисткой — но это сотрёт привязку старых плейлистов к трекам, если хэши файлов изменились при копировании.
• Восстановили базу поверх уже работающего сервера с новыми данными. Перед восстановлением всегда останавливайте сервис (docker compose stop navidrome), иначе можно получить рассинхрон между тем, что Navidrome держит в памяти, и тем, что вы подменили на диске.
• Забыли про права доступа. Если контейнер запускается не от root (а в официальном образе Navidrome именно так), после tar -xzf файл navidrome.db может принадлежать не тому пользователю — сервис не сможет его открыть. Проверьте ls -la navidrome.db и при необходимости выполните chown под UID, под которым работает контейнер (обычно 1000, но зависит от вашего docker-compose.yml).
• Версия базы не совпадает с версией Navidrome. Откат на старую версию образа с новой базой может не запуститься из-за миграций схемы. Держите версию образа зафиксированной (deluan/navidrome:0.55.2, а не :latest), чтобы такого сюрприза не было.

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