Как ночные бэкапы NAS тормозили Plex: рассказываю, как помог перенос на 3 часа ночи

Многие пользователи настраивают автоматические резервные копии и забывают о них, пока не столкнутся с проблемами. Я столкнулся с тем, что мои автоматические бэкапы NAS полностью разрушали производительность домашнего медиасервера Plex, пока я не додумался перенести их на глубокую ночь.

За годы администрирования я испробовал множество конфигураций резервного копирования. Моя общая стратегия оставалась неизменной: ночной перенос важных данных на второй жесткий диск и удаленный VPS. Такой подход полностью отвечает правилу бэкапов 3-2-1 и не раз выручал меня при аппаратных сбоях. Однако я долгое время не придавал значения времени запуска таких процессов. Главное — чтобы скрипт отрабатывал каждую ночь, и какое-то время всё работало отлично.

Мои бэкапы тормозили абсолютно всё в домашней сети

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

Но в одну из недель количество жалоб резко возросло. Первой зацепкой стало то, что все сообщения от разных людей приходили примерно в одно и то же время в течение нескольких вечеров подряд. Эти временные окна полностью совпадали с моим расписанием резервного копирования, хотя осознание причины пришло не сразу. Жалобы носили эпизодический характер, поскольку обычно объем новых данных для сохранения небольшой, и канал связи остается свободным.

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

Перенос расписания решил проблемы с производительностью

Решение оказалось банальным: я отредактировал crontab, перенеся задачи туда, где они никому не мешают. Локальную синхронизацию я сдвинул на 3 часа ночи, а удаленную — на час позже, чтобы эти два процесса не конкурировали друг с другом. Ежемесячный скан zpool я перенес на раннее утро субботы, когда сервером практически никто не пользуется.

Теперь мой файл конфигурации выглядит следующим образом:

0 3 * * * /mnt/scripts/local-sync.sh
0 4 * * * /mnt/scripts/offsite-sync.sh
0 1 * * 6 zpool scrub tank

Эффект проявился мгновенно. Я больше не получаю жалоб на зависания Plex в часы вечернего пикового трафика. Сами бэкапы стали выполняться быстрее, так как сервер свободен, а домашнее интернет-соединение не перегружено. Единственное, что мне теперь требуется — ежедневно просматривать логи утром, чтобы убедиться в корректности создания копий и снимков.

Особенности и подводные камни автоматических бэкапов

Настройка регулярного копирования требует учета нескольких важных нюансов. Когда бэкап запускается раз в сутки, за день накапливается большой объем изменений. Для файлов, которые постоянно обновляются, суточного интервала может быть недостаточно. Кроме того, автоматика не спрашивает разрешения на перенос конкретных изменений: скрипты rsync срабатывают при любых условиях, даже если вы еще не заметили какую-то проблему.

Код моего сайта постоянно получает правки, особенно с учетом активного использования искусственного интеллекта для генерации текстов. Пару раз мне приходилось восстанавливать разделы из бэкапов после неудачных экспериментов. Однако для таких задач гораздо лучше подходят системы контроля версий вроде Git, которые созданы именно для этого. Восстановление из полной копии или снапшота не содержит подробных логов изменений.

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

Почему выбор времени для бэкапов имеет критическое значение

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