Индексеры, диск, релиз-группы: где Sonarr и Radarr перестают работать сами

MAATRIX

Любой quick-start гайд по Sonarr и Radarr выглядит одинаково: ставим Docker-контейнер, подключаем один публичный индексер, добавляем торрент-клиент, через час всё уже качает первый сезон сериала. Проблема в том, что этот сценарий рассчитан на один сериал и один фильм в неделю. Как только вы добавляете в календарь 40 сериалов и начинаете подчищать фильмотеку за пять лет, всплывают вещи, о которых quick-start гайды молчат: индексеры банят или отключаются, релиз-группы конфликтуют друг с другом, диск кончается за одну ночь, а *arr-стек из трёх-четырёх сервисов начинает жить своей жизнью. Разберём, что реально ломается при масштабировании и как с этим жить.

Один индексер — это демо-режим, а не прод

В гайдах по быстрому старту почти всегда используется один бесплатный публичный индексер (трекер, который Sonarr/Radarr опрашивают в поисках релиза). Он отлично работает, пока вы ищете популярный сериал в разумном качестве — релизы для него появляются на десятках трекеров одновременно, и найти хотя бы один рабочий вариант не проблема.

Ситуация меняется, когда вы начинаете гоняться за конкретным качеством (например, только HEVC с определённым битрейтом), нишевыми сериалами или старыми фильмами, которые давно вымыли из раздач. Один индексер начинает регулярно отдавать пустой список результатов, и вы либо смиряетесь с ожиданием, либо идёте искать вручную — то есть автоматизация перестаёт быть автоматизацией.

Реалистичный список того, что вам понадобится в проде:

• Несколько публичных индексеров — они бесплатны, но нестабильны: могут упасть на день, ограничить частоту запросов (rate limit) или вовсе закрыться. Диверсификация здесь не роскошь, а необходимость.
• Приватные трекеры — требуют инвайт и поддержание рейтио (соотношения отданного и скачанного трафика), но дают куда более полные и качественные каталоги. Порог входа выше: без приглашения не зайти, а с плохим рейтио могут забанить.
• Платные индексеры-агрегаторы — они не хостят раздачи сами, а агрегируют поиск по десяткам источников через единый API. Это платная подписка (порядок цен уточняйте на сайте конкретного сервиса — он меняется), но именно такие агрегаторы чаще всего используют вместе с Prowlarr, чтобы не подключать каждый индексер в Sonarr и Radarr по отдельности.

Ключевой практический момент: индексеры дохнут без предупреждения. Трекер меняет домен, вводит капчу на API, банит ваш IP за слишком частые запросы — и вы узнаёте об этом не сразу, а через несколько дней, когда замечаете, что новые серии перестали подтягиваться. Единственная защита — не полагаться на один источник и периодически проверять статус индексеров в интерфейсе (в Prowlarr это делается одной кнопкой Test для всех индексеров разом).

Prowlarr как прослойка вместо ручного дублирования

Если у вас Sonarr, Radarr, а потом ещё, например, Lidarr для музыки — без прослойки индексеры приходится настраивать в каждом сервисе отдельно. Добавили новый индексер — идёте в три интерфейса и вбиваете его заново. Забанили индексер — снова три места для правки.

Prowlarr решает именно эту задачу: это отдельный сервис, который хранит список индексеров один раз и раздаёт их всем *arr-приложениям через свой API. Настройка в общих чертах:

# Docker Compose, сервис Prowlarr
prowlarr:
  image: lscr.io/linuxserver/prowlarr:latest
  container_name: prowlarr
  environment:
    - PUID=1000
    - PGID=1000
    - TZ=Europe/Moscow
  volumes:
    - ./prowlarr/config:/config
  ports:
    - "9696:9696"
  restart: unless-stopped

После запуска в Prowlarr нужно добавить приложения (Settings → Apps), указав адрес и API-ключ каждого Sonarr/Radarr — тогда индексеры синхронизируются автоматически при каждом изменении. Грабля здесь одна, но частая: если Sonarr и Radarr крутятся в отдельных Docker-сетях или на разных хостах, Prowlarr должен достучаться до их API по сети — проверяйте это через curl с контейнера Prowlarr до того, как разбираться, почему синхронизация «не работает»:

docker exec -it prowlarr curl -s http://sonarr:8989/api/v3/system/status?apikey=ВАШ_КЛЮЧ

Второй нюанс: Prowlarr не заменяет настройку профилей качества и релиз-групп в самих Sonarr/Radarr — он только раздаёт индексеры. Логика «что скачивать» остаётся полностью на стороне каждого приложения.

Конфликты релиз-групп и профилей качества

Это самая частая причина, по которой библиотека в проде выглядит неопрятно: одна серия в 1080p от одной релиз-группы, следующая — в 720p от другой, а на некоторых эпизодах вообще два файла, потому что Sonarr решил, что новый релиз «лучше». По умолчанию профили качества настроены довольно мягко, и без ручной настройки вы получаете разнобой.

Что стоит настроить, чтобы этого избежать:

• Profile качества (Quality Profile) — задаёт не только минимальное и максимальное разрешение, но и порядок предпочтений между вариантами (например, WEB-DL 1080p предпочтительнее Bluray-remux, если вас волнует место на диске, а не эталонное качество).
• Список предпочитаемых и запрещённых релиз-групп — в разделе Custom Formats можно задать положительный или отрицательный балл для конкретных релиз-групп по regex-паттерну в названии файла. Это не бронебойная защита (некоторые релизеры меняют теги в названии), но отсекает основную массу мусорных повторных загрузок.
• Upgrade-логика — Sonarr и Radarr могут автоматически заменять уже скачанный файл на «более качественный», если в профиле разрешён апгрейд. Это удобно, когда вышел лучший релиз, но без ограничений система будет по кругу переcкачивать один и тот же эпизод, если релиз-группы конкурируют за первое место в списке предпочтений, а критерии выставлены нечётко.

Практический совет: не оставляйте профиль качества «по умолчанию» на весь каталог. Разделите его хотя бы на два-три профиля — например, «Компактно» (H.265/HEVC, экономия места) для длинных сериалов, которые вы смотрите фоном, и «Максимум» для фильмов, которые хочется пересматривать в хорошем качестве. Это прямо влияет на следующую проблему.

Диск кончается быстрее, чем кажется

Здесь quick-start гайды обычно ограничиваются фразой «выберите диск побольше». В реальности рост библиотеки нелинейный и часто внезапный:

• Сезон в 4K или HEVC-remux занимает несравнимо больше места, чем WEB-DL 1080p — если у вас в профиле разрешены оба варианта, а предпочтение стоит на максимальном качестве, один активный сериал может съедать десятки гигабайт в неделю.
• Незавершённые загрузки и seed-обязательства приватных трекеров — раздачи занимают место, пока вы обязаны поддерживать рейтио, даже если контент уже импортирован в библиотеку.
• Дублирующиеся файлы при смене релиз-группы — если апгрейд-логика настроена нестрого, старая и новая версия эпизода какое-то время существуют одновременно, пока не сработает удаление.
• Логи и метаданные — сами по себе некритичны, но при активном использовании Sonarr/Radarr/Bazarr логи могут расти месяцами без ротации, если вы не трогали настройки логирования.

Что реально помогает не упереться в стену посреди ночи:

1. Мониторинг свободного места с алертами, а не проверка вручную раз в неделю — к моменту, когда вы замечаете забитый диск глазами, обычно уже поздно. Подробно о настройке алертов по месту и inode — в статье про мониторинг диска на VPS.
2. Отдельный том или диск под загрузки (download-каталог), отличный от тома с готовой библиотекой — так временный всплеск незавершённых закачек не роняет доступность самой медиатеки.
3. Жёсткий лимит на профиль качества для сериалов, которые вы смотрите фоном — HEVC вместо AVC/remux экономит ощутимо, хотя точную экономию в вашем случае надо будет проверить на своих файлах, а не полагаться на усреднённые цифры из интернета.
4. Периодическая ревизия библиотеки — модуль Unmonitored в Sonarr позволяет снять с отслеживания завершённые и больше не нужные сериалы, чтобы система не пыталась их доскачивать при повторном сканировании.

Если библиотека растёт быстрее, чем вы успеваете докупать место на одном диске, вариант с объединением нескольких дисков разного объёма в единый пул без требований классического RAID разобран в статье про mergerfs и SnapRAID.

Импорт: почему файлы «зависают» и не попадают в библиотеку

Ещё одна вещь, которая ломается незаметно: закачка в торрент-клиенте показывает 100%, а в Sonarr/Radarr файл так и не появляется в библиотеке. Обычно причина — в одном из трёх мест:

• Разные пути монтирования в контейнерах Sonarr/Radarr и торрент-клиента. Если торрент-клиент видит папку загрузок как /downloads, а Sonarr — как /data/downloads, автоматический импорт не сработает, потому что сервисы буквально не видят один и тот же файл по одному и тому же пути. Правило простое: во всех контейнерах *arr-стека и торрент-клиента монтируйте общий раздел с одинаковой структурой путей.
• Hardlink вместо копирования не срабатывает между разными файловыми системами — Sonarr по умолчанию старается делать hardlink из папки загрузок в папку библиотеки (это мгновенно и не требует лишнего места), но hardlink работает только в пределах одной файловой системы. Если загрузки и библиотека на разных смонтированных томах, Sonarr откатывается на копирование — а это и медленнее, и требует вдвое больше свободного места на время операции.
• Права доступа (PUID/PGID) — если торрент-клиент и Sonarr/Radarr запущены от разных пользователей в контейнере, доступ на запись может просто не быть у того, кто должен переносить файл. Проверяйте, что во всех контейнерах *arr-стека и торрент-клиента выставлены одинаковые PUID/PGID.

Для базовой настройки самого торрент-клиента, включая том загрузок и веб-интерфейс, см. статью про установку qBittorrent на VPS — на неё удобно опираться при выравнивании путей с Sonarr и Radarr.

Интеграция всего стека: Prowlarr, Sonarr, Radarr, Bazarr и медиасервер

Полноценный *arr-стек в проде обычно выглядит так: Prowlarr раздаёт индексеры, Sonarr и Radarr скачивают контент, Bazarr следом подтягивает субтитры, а на выходе Jellyfin или Plex раздают готовую библиотеку. Каждое звено добавляет свою точку отказа:

Практический вывод из этой таблицы: чем больше звеньев в цепочке, тем важнее единообразие путей и учётных данных между контейнерами. Проще всего гонять весь стек одним docker-compose.yml с общими именованными томами для downloads и media, а не разносить сервисы по независимым конфигурациям — так меньше шансов словить рассинхронизацию путей, о которой шла речь выше.

Про сам выбор и установку медиасервера, который в итоге раздаёт готовую библиотеку, — в статьях про Jellyfin на VPS и в сравнении Jellyfin с Plex, если вы ещё не определились с раздающим сервером.

Где физически размещать стек: домашний NAS или VPS

Отдельный вопрос, который встаёт при масштабировании — где вообще держать всё это хозяйство. У домашнего NAS есть очевидный плюс: локальная сеть, файлы физически рядом, не нужно платить за трафик загрузки. Минусы тоже понятны — зависимость от домашнего интернета (особенно если у вас несимметричный канал с медленной отдачей для seed), необходимость держать домашний роутер открытым для приватных трекеров, и полная остановка автоматизации при отключении света или перезагрузке роутера провайдером.

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

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