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

MAATRIX

Ampache живёт долго — годами накапливает плейлисты, рейтинги, историю прослушиваний и десятки тысяч треков в каталоге. Один упавший диск, неудачное обновление PHP или случайный DROP DATABASE — и всё это исчезает за секунду, а музыкальные файлы без метаданных Ampache превращаются обратно в безымянную кучу mp3 и flac. Разберём, что именно нужно бэкапить в Ampache, как автоматизировать процесс и как восстановиться, не потеряв ни плейлист.

Что теряете, если бэкапа нет

Ampache — это не просто плеер поверх папки с музыкой. Он хранит состояние в нескольких местах, и потеря любого из них бьёт по-разному:

Ключевой вывод: база данных — это самое дорогое, что есть в вашей инсталляции Ampache. Сама медиатека (файлы) обычно физически лежит на отдельном томе или сетевом хранилище и требует отдельной стратегии — не обязательно той же, что для базы.

База данных: что и как бэкапить

Если Ampache установлен «руками» на сервер (LAMP-стек), дамп снимается стандартно через mysqldump. Узнать имя базы и пользователя можно прямо в конфиге:

grep -E "database_name|database_username" /var/www/ampache/config/ampache.cfg.php

Сам дамп с блокировкой на уровне транзакции (не кладёт таблицы InnoDB на время снятия):

mkdir -p /backup/ampache
mysqldump -u ampache_user -p \
  --single-transaction \
  --routines \
  --triggers \
  --default-character-set=utf8mb4 \
  ampache > /backup/ampache/ampache_db_$(date +%F).sql

Если Ampache запущен в Docker и база — в отдельном контейнере (типично для docker-compose с сервисами ampache и db), дамп снимается через docker exec, без установки клиента mysql на хост:

docker exec ampache-db mysqldump -u root -p"$MYSQL_ROOT_PASSWORD" \
  --single-transaction ampache > /backup/ampache/ampache_db_$(date +%F).sql

Дамп стоит сразу сжать — база с историей прослушиваний за пару лет может весить сотни мегабайт в текстовом виде:

gzip -9 /backup/ampache/ampache_db_$(date +%F).sql

Общие грабли mysqldump — блокировки на больших таблицах, обрыв соединения на объёмных базах, неверная кодировка при восстановлении — разобраны отдельно в статье про бэкап MySQL на сервере, туда стоит заглянуть, если дамп падает с ошибкой или восстановленная база выглядит битой.

Конфигурация и медиатека

Конфиг ampache.cfg.php (в Docker-варианте обычно смонтирован как /config/ampache.cfg.php или лежит в volume ampache_config) весит несколько килобайт — бэкапить его отдельно от базы:

cp /var/www/ampache/config/ampache.cfg.php /backup/ampache/ampache.cfg.php.$(date +%F)

В этом файле, помимо прочего, лежит соль для сессий и данные подключения к БД — храните бэкапы конфига так же аккуратно, как пароли, не в открытом публичном каталоге.

С медиатекой ситуация другая. Ampache не копирует ваши аудиофайлы к себе — он только индексирует путь, указанный в настройках каталога (Admin → Catalogs). Поэтому:

• если библиотека лежит на отдельном диске или NAS-шаре, смонтированной по NFS/SMB, — бэкап файлов делайте средствами хранилища (снапшоты ZFS, снапшоты NAS, репликация) отдельно от бэкапа Ampache;
• если библиотека физически на том же сервере — регулярный полный tar каждой ночью нецелесообразен при библиотеке в сотни гигабайт, разумнее инкрементальная синхронизация rsync на другой сервер или объектное хранилище;
• кэш превью и обложек (cache/, image_manager cache) можно смело исключать из бэкапа — он перегенерируется при следующем сканировании каталога.

Пример инкрементального бэкапа медиатеки через rsync на резервный сервер:

rsync -avz --delete \
  /mnt/music/ \
  backup-host:/storage/ampache-library/

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

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

Собираем дамп базы, конфиг и ротацию старых копий в один скрипт:

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

BACKUP_DIR="/backup/ampache"
DATE=$(date +%F_%H%M)
RETENTION_DAYS=14

mkdir -p "$BACKUP_DIR"

# дамп базы
mysqldump -u ampache_user -p"$AMPACHE_DB_PASSWORD" \
  --single-transaction --routines --triggers \
  ampache | gzip -9 > "$BACKUP_DIR/db_$DATE.sql.gz"

# конфиг
cp /var/www/ampache/config/ampache.cfg.php "$BACKUP_DIR/config_$DATE.cfg.php"

# ротация: удаляем всё старше RETENTION_DAYS
find "$BACKUP_DIR" -type f -mtime +"$RETENTION_DAYS" -delete

echo "Ampache backup done: $DATE"

Задача в cron (пароль вынесен в переменную окружения, а не в аргумент команды, чтобы не светился в ps aux):

# /etc/cron.d/ampache-backup
0 3 * * * root AMPACHE_DB_PASSWORD='ваш_пароль' /usr/local/bin/ampache-backup.sh >> /var/log/ampache-backup.log 2>&1

Хранить копии только на том же сервере — плохая идея: если умрёт диск, вы потеряете и продакшен, и бэкап одновременно. Дамп стоит дополнительно забирать на отдельный сервер или в объектное хранилище — rclone, restic или borg с шифрованием на стороне клиента подойдут одинаково хорошо, разница в основном в удобстве дедупликации и скорости на больших объёмах. Какой инструмент выбрать конкретно под ваш сценарий, разобрано в сравнении restic и borgbackup — для дампа базы в несколько сотен мегабайт разница между ними не критична, но если вы бэкапите ещё и медиатеку целиком, дедупликация начинает заметно экономить место.

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

Порядок действий при полном восстановлении — на новом сервере или после реинсталляции:

1. Разверните тот же стек (PHP + веб-сервер + MySQL/MariaDB), желательно версий, максимально близких к тем, что были на исходном сервере — Ampache чувствителен к версии PHP при апгрейдах, обратный откат может потребовать миграций.
2. Создайте базу и пользователя:

CREATE DATABASE ampache CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'ampache_user'@'localhost' IDENTIFIED BY 'новый_пароль';
GRANT ALL PRIVILEGES ON ampache.* TO 'ampache_user'@'localhost';
FLUSH PRIVILEGES;

1. Импортируйте дамп:

gunzip -c /backup/ampache/db_2026-08-20_0300.sql.gz | mysql -u ampache_user -p ampache

1. Восстановите конфиг и поправьте в нём пароль базы, если он изменился:

cp /backup/ampache/config_2026-08-20_0300.cfg.php /var/www/ampache/config/ampache.cfg.php
chown www-data:www-data /var/www/ampache/config/ampache.cfg.php

1. Верните на место медиатеку (или примонтируйте тот же сетевой каталог с тем же путём, что был указан в каталоге Ampache — пути должны совпасть, иначе Ampache не найдёт файлы).
2. Проверьте права на директории cache/, channel/, local/ — Ampache должен иметь право писать в них от имени пользователя веб-сервера:

chown -R www-data:www-data /var/www/ampache/cache /var/www/ampache/channel

1. Запустите обновление каталога через веб-интерфейс (Admin → Catalogs → Update/Verify) или, если в вашей версии есть CLI-инструмент, соответствующей командой — процедура и её название немного отличаются между релизами Ampache, точный синтаксис лучше свериться с документацией именно вашей версии.
2. Залогиньтесь под существующим пользователем и проверьте, что плейлисты и рейтинги на месте — это самый быстрый способ убедиться, что восстановилась именно база, а не только пустая структура.

Если после восстановления треки в каталоге числятся, но не проигрываются — почти всегда это несовпадение пути к медиатеке в базе (сохранён старый путь) с реальным путём на новом сервере. Правится либо через переопределение пути каталога в интерфейсе, либо прямым UPDATE в таблице catalog_local — второе делать только по прямому пониманию структуры базы и с предварительным дампом на всякий случай.

Ampache в Docker: нюансы бэкапа

При развёртывании через docker-compose данные Ampache обычно разнесены по нескольким volume — конфиг, база и (опционально) сама медиатека как bind mount с хоста. Типичная структура сервисов:

services:
  ampache:
    image: ampache/ampache:latest
    volumes:
      - ampache_config:/config
      - /mnt/music:/music:ro
    depends_on:
      - db
  db:
    image: mariadb:11
    volumes:
      - db_data:/var/lib/mysql
volumes:
  ampache_config:
  db_data:

Бэкап именованных volume делается через временный контейнер, который монтирует том и упаковывает его в архив на хосте:

docker run --rm \
  -v ampache_db_data:/data \
  -v /backup/ampache:/backup \
  alpine tar czf /backup/db_data_$(date +%F).tar.gz -C /data .

Для базы в контейнере предпочтительнее не архивировать сырые файлы MySQL (риск получить несогласованную копию), а снимать логический дамп через docker exec mysqldump, как в разделе выше — это надёжнее архивации /var/lib/mysql на живой базе.

Если медиатека подключена как bind mount (/mnt/music:/music), её бэкап не отличается от бэкапа обычной директории на хосте — Docker тут ни при чём, действуют те же правила rsync/снапшотов, что описаны в разделе про медиатеку. Схожий по логике разбор — для другого self-hosted музыкального сервера — есть в статье про бэкап и восстановление Navidrome: подход к разделению «база отдельно, медиатека отдельно» там тот же, различаются только конкретные пути и структура схемы.

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

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