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

MAATRIX

Icecast — один из немногих сервисов, который годами работает без изменений в протоколе: конфиг написан один раз, сервер перезагружается раз в полгода при апдейте пакетов, и про бэкапы благополучно забывают. А потом диск сыпется, или провайдер разово теряет ноду, и оказывается, что восстанавливать особо нечего — потому что никто не сохранял ни SSL-сертификат, ни htpasswd для источников, ни fallback-файл, который слушатели гоняли по кругу три года. Ниже — что у Icecast на самом деле стоит бэкапить, а что бэкапить бессмысленно, и как поднять поток на новом сервере без простоя эфира дольше нескольких минут.

Что в Icecast нужно бэкапить, а что нет

Ключевая особенность Icecast — у него почти нет собственного состояния. Сам поток эфемерный: сервер ретранслирует то, что в данный момент присылает источник (Liquidsoap, BUTT, mpd, ffmpeg), и ничего не пишет на диск, если вы явно не включили запись. Из-за этого бэкап Icecast — это не бэкап «базы данных», а бэкап окружения, без которого сервис не поднимется в прежнем виде.

Стоит бэкапить:

• /etc/icecast2/icecast.xml (или /etc/icecast.xml на не-Debian сборках) — главный конфиг: точки монтирования, лимиты, admin-пароли.
• Файлы аутентификации источников — .htpasswd или скрипт для authenticate=url, если используете внешнюю проверку токенов.
• SSL-сертификат и ключ, если Icecast слушает TLS напрямую (директива <ssl> в конфиге), либо конфиг реверс-прокси перед ним.
• Кастомные XSL-шаблоны веб-интерфейса из /usr/share/icecast2/web/ или /etc/icecast2/web/, если их правили под свой дизайн.
• Fallback-файлы (fallback-mount, обычно mp3/ogg-заглушка на паузу эфира) и статичные плейлисты для relay-точек.
• Systemd unit-файлы и override'ы (/etc/systemd/system/icecast2.service.d/), если меняли лимиты по файловым дескрипторам или пользователя запуска.
• Конфиг источника (Liquidsoap .liq, cron-задачи автозапуска), если он живёт на том же сервере.

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

Где лежат файлы на типовых дистрибутивах

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

Найти реальный путь конфига быстрее всего через сам процесс:

ps aux | grep icecast
# icecast -c /etc/icecast2/icecast.xml -b

Флаг -b в выводе — это запуск в фоне; путь после -c — тот самый конфиг, который нужен для бэкапа.

Скрипт бэкапа конфигурации и сертификатов

Для большинства инсталляций достаточно простого tar-архива по cron, без отдельной СУБД или снапшотов — объём файлов измеряется килобайтами.

#!/bin/bash
# /usr/local/bin/icecast-backup.sh
set -euo pipefail

DATE=$(date +%Y%m%d-%H%M)
DEST=/var/backups/icecast
SRC_LIST=(
  /etc/icecast2/icecast.xml
  /etc/icecast2/web
  /etc/icecast2/*.htpasswd
  /etc/systemd/system/icecast2.service.d
  /etc/letsencrypt/live/radio.example.com
)

mkdir -p "$DEST"
tar -czf "$DEST/icecast-$DATE.tar.gz" \
  --ignore-failed-read \
  "${SRC_LIST[@]}" 2>/dev/null || true

find "$DEST" -name 'icecast-*.tar.gz' -mtime +30 -delete

Добавьте --ignore-failed-read, потому что не на всех серверах есть все пути из списка (например, TLS может терминироваться на nginx, а не на самом Icecast) — скрипт не должен падать из-за отсутствующего каталога.

Запуск раз в сутки через cron достаточен — конфиг меняется редко:

0 3 * * * /usr/local/bin/icecast-backup.sh

Автоматизация с ретеншеном через restic

Если сервер уже отдаёт другие сервисы и у вас есть общая схема бэкапов, логичнее подключить Icecast к тому же репозиторию restic, а не городить отдельный tar-скрипт. Кратко: инициализация репозитория и снапшот конфигурации.

restic -r s3:https://s3.example.com/backups init

restic -r s3:https://s3.example.com/backups backup \
  /etc/icecast2 \
  /etc/letsencrypt/live/radio.example.com \
  --tag icecast

restic -r s3:https://s3.example.com/backups forget \
  --tag icecast --keep-daily 14 --keep-weekly 8 --prune

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

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

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

1. Установить Icecast тем же способом, что и раньше (пакет icecast2 из репозитория дистрибутива — самый предсказуемый вариант):

apt update && apt install -y icecast2
systemctl stop icecast2

1. Развернуть архив бэкапа на место штатных путей:

tar -xzf icecast-20260828-0300.tar.gz -C /
chown -R icecast2:icecast /etc/icecast2

1. Проверить конфиг на синтаксические ошибки до запуска сервиса — Icecast умеет валидировать конфиг без старта прослушивания:

icecast -c /etc/icecast2/icecast.xml -b
tail -f /var/log/icecast2/error.log

Если в логе нет ошибок парсинга XML и сервис слушает порт (по умолчанию 8000), можно запускать через systemd:

systemctl enable --now icecast2

1. Проверить, что точки монтирования отвечают и источник может переподключиться:

curl -s http://localhost:8000/status-json.xsl | python3 -m json.tool

1. Переключить источник (Liquidsoap, автоматизацию эфира) на новый адрес сервера и обновить DNS-запись или балансировщик, если IP сменился.

Если вы уже настраивали похожий сценарий переезда, общая логика повторяет бэкап и восстановление PeerTube и Owncast — у всех потоковых сервисов главная головная боль не в данных, а в правильном порядке: сначала конфиг и сертификаты, потом сервис, потом источник.

Мониторинг доступности и автоматический рестарт

Бэкап не спасёт от долгого простоя, если о падении сервиса узнают только слушатели в чате. Минимальная проверка — cron-скрипт, который дергает status-json.xsl и рестартует сервис при отсутствии ответа:

#!/bin/bash
# /usr/local/bin/icecast-watchdog.sh
if ! curl -fs -m 5 http://localhost:8000/status-json.xsl > /dev/null; then
  systemctl restart icecast2
  echo "$(date): icecast restarted" >> /var/log/icecast-watchdog.log
fi

*/2 * * * * /usr/local/bin/icecast-watchdog.sh

Для внешнего мониторинга (проверка не с самого сервера, а снаружи) добавьте отдельную HTTP-проверку конкретной точки монтирования — curl -I http://radio.example.com:8000/stream.mp3 должен возвращать 200 и заголовок icy-name. Это ловит ситуации, когда сам процесс жив, а конкретный mount отвалился из-за обрыва связи с источником.

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