NAS · SSD · NVMe · Docker · Home Assistant · Frigate
Износ SSD и NVMe в NAS: что постоянно пишет на диск и как увеличить ресурс
SSD в NAS или домашнем сервере может годами почти не менять показатель износа, а может за несколько месяцев накопить десятки терабайт записи. Причина обычно не в самом факте работы 24/7, а в характере нагрузки: базы данных, журналы, Docker, Home Assistant Recorder, Frigate, write-cache и другие сервисы постоянно создают мелкие записи. Разберём, как отличить нормальный износ от аномального и где искать источник.
TBW: что означает ресурс SSD
TBW — Terabytes Written, объём данных, который используется производителями как характеристика ресурса записи SSD. Solidigm прямо определяет TBW как количество данных, которое можно записать на накопитель за его ресурс. У многих потребительских SSD гарантия ограничивается либо сроком, либо достижением определённого TBW.
Поэтому SSD с рейтингом 600 TBW не обязан сломаться сразу после 600 ТБ записи, но при выборе диска под постоянную базу данных или cache этот показатель имеет гораздо больше значения, чем для обычного домашнего ПК.
Что означает NVMe SMART Percentage Used
NVM Express рекомендует использовать поле SMART Percentage Used как простой индикатор использованного ресурса накопителя. Условно остаток endurance можно оценивать как 100% минус Percentage Used.
Поле может зависеть от модели и алгоритма производителя. Поэтому дополнительно полезно смотреть Data Units Written/Host Writes, media errors, available spare, unsafe shutdowns и температуру.
SSD показывает 20% износа за полгода: это много?
Возраст сам по себе почти ничего не говорит. Нужно понять скорость расходования ресурса.
Это лишь грубая экстраполяция. Нагрузка может измениться, а SMART не обязан расти идеально линейно. Но такой расчёт сразу показывает разницу между «20% за пять лет» и «20% за шесть месяцев».
Что в домашнем сервере постоянно пишет на SSD
Базы данных
SQLite, MariaDB, PostgreSQL и другие БД постоянно обновляют данные, индексы и служебные структуры.
Home Assistant Recorder
История состояний и событий записывается в recorder database.
Frigate
Видеозаписи, snapshots, metadata и служебные данные зависят от retention и числа камер.
Docker
Логи, writable layers, базы приложений и временные файлы контейнеров.
NAS services
Индексация, thumbnails, Drive, базы пакетов, поисковые индексы.
Swap и системные логи
При нехватке RAM или шумном logging запись может стать постоянной.
Docker: почему write-heavy данные лучше не оставлять в writable layer
Docker хранит изменения контейнера в writable layer поверх image layers. Официальная документация Docker рекомендует использовать volumes для write-heavy workloads вместо постоянной записи в writable container layer.
Особенно внимательно проверяйте базы данных, логи и каталоги приложений. Данные, которые должны жить долго, обычно лучше хранить в явно заданном volume/bind mount с понятным местом и политикой backup.
Home Assistant Recorder: что именно пишет на диск
Recorder хранит историю событий и состояний Home Assistant. Официальная документация указывает, что база автоматически очищается, чтобы не расти бесконечно. По умолчанию используется автоматическая purge-процедура.
Датчик, меняющий состояние очень часто, может создать значительно больше строк, чем десятки спокойных сенсоров.
Полезно пересмотреть, что действительно нужно хранить в Recorder. Для части высокочастотных данных история по каждой смене состояния может не иметь практической ценности.
Что можно оптимизировать в Home Assistant
- оставить включённым auto_purge;
- не увеличивать retention без реальной необходимости;
- исключить из Recorder бесполезные шумные entities;
- проверить интеграции, которые меняют state каждую секунду;
- не использовать database как бесконечный архив сырых данных;
- для долгих трендов использовать long-term statistics там, где они предусмотрены.
Frigate: основной объём обычно создаёт видео, а не база
Frigate поддерживает continuous и object-based recording с отдельными retention periods. Официальная документация позволяет независимо задавать, сколько хранить обычную запись, motion, alerts и detections.
Камеры пишутся постоянно.
Дольше сохраняются только нужные фрагменты.
Snapshots также сохраняются отдельными файлами. Если SSD используется под `/media/frigate`, число камер, битрейт и retention намного сильнее влияют на Host Writes, чем размер самой служебной базы.
Почему видеозапись лучше считать заранее
Например, четыре камеры по 4 Мбит/с могут создать примерно 173 ГБ видеоданных в сутки при непрерывной записи. Если это проходит через небольшой потребительский SSD, TBW будет расходоваться уже совершенно в другом масштабе, чем у Home Assistant database.
SSD cache в Synology: read-only и read-write сильно отличаются
Synology предлагает два режима SSD cache. Read-only cache хранит копии часто читаемых данных. Read-write cache принимает записи на SSD перед последующей работой с основным volume и требует отказоустойчивой конфигурации.
Записи пользователя не зависят от SSD cache как от write-back слоя.
Для write-intensive workloads endurance становится особенно важным.
Synology прямо позиционирует SSD cache прежде всего для частого random I/O небольшими блоками. Большая последовательная видеозапись сама по себе не является идеальным сценарием для cache.
Почему SSD большей ёмкости часто выгоднее для постоянной записи
У дисков одной серии более ёмкие модели нередко имеют более высокий TBW. Кроме того, больший запас свободных NAND-блоков облегчает внутреннее управление записью. Но сравнивать нужно конкретные datasheet, а не только объём.
Для NAS и баз данных смотрите TBW/DWPD конкретной модели и ёмкости.
Температура NVMe в NAS
NVMe в компактном NAS может работать заметно горячее SATA SSD, особенно без воздушного потока. SMART позволяет контролировать composite temperature и thermal warnings.
- не закрывайте M.2 плотной теплоизоляцией;
- следите за вентиляцией NAS;
- проверяйте throttling и temperature warnings;
- не ставьте горячий NVMe вплотную к другим источникам тепла без необходимости.
TRIM и свободное место
SSD должен понимать, какие блоки файловая система больше не использует. TRIM помогает контроллеру эффективнее управлять NAND. Также не стоит постоянно держать рабочий SSD заполненным «под 100%»: свободное пространство полезно для служебных операций и garbage collection.
Конкретная поддержка TRIM зависит от NAS, файловой системы, RAID и режима использования SSD, поэтому проверяйте документацию своей платформы.
RAID1 не уменьшает число записей на каждый SSD
В зеркале данные записываются на оба накопителя. RAID1 повышает отказоустойчивость, но не является способом «разделить износ пополам».
Как найти, кто именно пишет на SSD
- Снимите SMART/NVMe SMART сейчас. Запишите Percentage Used и Host Writes/Data Units Written.
- Повторите через 24 часа. Получите реальную запись за сутки.
- Посмотрите disk I/O процессов и контейнеров.
- Проверьте каталоги Docker volumes.
- Проверьте размер Home Assistant database.
- Проверьте retention и путь записи Frigate.
- Проверьте swap и системные журналы.
- Временно отключайте подозрительные сервисы по одному.
- Снова сравните Host Writes.
Как посчитать текущий темп и прогноз ресурса
Например, если SSD с рейтингом 600 TBW уже получил 120 TB host writes, остаётся условно 480 TB до паспортного TBW. При 200 ГБ/сутки это около 2400 суток, то есть примерно 6,6 года. При 1 ТБ/сутки — уже около 1,3 года.
Host Writes и внутренние NAND Writes не всегда совпадают, нагрузка меняется, а TBW не является гарантированным моментом отказа. Но такой расчёт полезнее предположений «SSD новый, значит всё хорошо».
Как уменьшить ненужную запись
Home Assistant
Уменьшить шум Recorder и разумно выбрать retention.
Frigate
Пересмотреть continuous recording, bitrate и retention.
Docker
Использовать volumes для write-heavy persistent data и контролировать logging.
Logs
Настроить rotation и устранить сервис, который пишет одну ошибку тысячи раз.
Swap
Понять причину постоянного swapping, а не просто переносить swap.
Cache
Не включать read-write SSD cache без задачи, которая действительно от него выигрывает.
Что не нужно оптимизировать вслепую
- не отключайте journaling файловой системы ради SSD wear;
- не переносите критичную БД в RAM без надёжной persistence-схемы;
- не отключайте fsync у базы данных ради уменьшения записи;
- не убирайте резервирование только ради TBW;
- не отключайте системные логи полностью;
- не меняйте SSD только потому, что Percentage Used стал больше нуля.
Частые вопросы
Percentage Used 100% означает, что SSD завтра сломается?
Нет. Это оценка использованного endurance, а не таймер мгновенного отказа. Но такой накопитель уже требует повышенного внимания и плана замены.
Home Assistant действительно «убивает SSD»?
Не обязательно. Recorder действительно пишет базу, но аномальный wear чаще связан с шумными сущностями, слишком большой retention, логами, swap или другими сервисами на том же диске.
Frigate лучше писать на HDD?
Для длительной непрерывной видеозаписи HDD часто рациональнее по стоимости и endurance. SSD полезен там, где нужна высокая random I/O производительность, но конкретная архитектура зависит от числа камер и задач.
Нужно ли использовать enterprise SSD?
Не всегда. Сначала измерьте реальную запись в сутки и сравните с endurance конкретного потребительского SSD. Для тяжёлого write-intensive режима enterprise/NAS-oriented модели могут быть оправданы.
Почему 2 ТБ SSD может жить дольше 500 ГБ?
У большей ёмкости одной серии часто выше TBW и больше NAND для распределения износа. Проверяйте datasheet конкретных вариантов.
Read-only SSD cache тоже изнашивает SSD?
Да, cache периодически заполняется и обновляется, но профиль записи отличается от read-write cache, через который проходят рабочие записи.
Вывод
Износ SSD в NAS нужно оценивать по данным, а не по ощущениям. Главные показатели — Host Writes/Data Units Written, NVMe Percentage Used, TBW конкретной модели и реальный темп записи за сутки.
Если wear растёт слишком быстро, сначала найдите источник I/O. В домашнем сервере им часто оказываются видеозапись, базы данных, Docker logs, Home Assistant Recorder, swap или read-write SSD cache. После этого оптимизируйте именно источник, а не отключайте полезные механизмы надёжности вслепую.
