ПП №445 не называет готовое число терабайт, а связывает емкость технических средств накопления информации с объемом сообщений. Ошибка в базовом объеме сохраняется во всех шагах и к пятому увеличению масштабируется коэффициентом 1,15⁵. Ниже приведен инженерный расчет, который нужно согласовать с проектом СОРМ и приемочными документами.
Основание расчета — постановление Правительства РФ №445 от 12.04.2018. С 1 сентября 2026 года пункты 5 и 6 действуют в редакции постановления №1066 от 24.08.2026. №573 — это приказ Минкомсвязи от 29.10.2018 с требованиями к информационным системам, а не постановление об объеме хранения.
Что именно требует закон: два разных правила
Правила содержат два независимых требования, и применяются они к разным видам услуг.
Пункт 5 устанавливает хранение голосовой информации и текстовых сообщений в полном объеме в течение 6 месяцев. Применимость требования определяют по лицензиям, услугам и действующей редакции Правил.
Пункт 6 связывает емкость с объемом сообщений за 30 суток, предшествующих вводу в эксплуатацию, и предусматривает ежегодное увеличение на 15 процентов в течение пяти лет. Точкой отсчета служит акт ввода в эксплуатацию, подписанный представителями органа ФСБ, Роскомнадзора и оператора связи.
Пункты 5 и 6 задают разные режимы. Какие из них одновременно применяются к конкретным лицензиям и услугам, оператор связи подтверждает у профильного юриста и согласующего органа. Автоматическое удаление и кольцевая запись настраиваются по применимым требованиям проекта.
От чего считать: фактический трафик, а не канал
Расчет от номинальной полосы способен завысить проектную емкость. Канал 10 Гбит/с при непрерывной полной загрузке передал бы около 3,2 ПБ за 30 суток в одном направлении, но это только теоретическая верхняя граница, а не нормативная база.
Базу получают из согласованной схемы точек консолидации для оказываемых услуг, а не автоматически из счетчика внешнего канала. Зафиксируйте интерфейсы, межабонентский трафик, положение относительно NAT, исключение транзита, направления учета и единицы. Методика должна быть подтверждена в проекте СОРМ.
Берут именно 30 суток, предшествующих вводу. Сезонность используют для проектного запаса, но она не подменяет установленный период и согласованную выборку трафика.
Формула и пример расчета
Возьмем условный пример: фактический трафик за тридцать суток составил 400 ТБ.
Шаг первый. Объем сообщений за 30 суток равен 400 ТБ. Это C_base для инженерного примера, а сопоставление нормативной емкости с usable или raw фиксируют в проекте и приемочных документах.
Шаг второй. Коэффициент usable берут из спецификации конкретной схемы, включая файловую систему, метаданные и служебные резервы. Универсальные 5 процентов нельзя применять без расчета производителя.
Шаг третий. Пересчитайте базу в raw по коэффициенту схемы массива. Если для выбранной конфигурации K_usable равен 0,80, то 400 ТБ / 0,80 равно 500 ТБ raw до учета spare и проектного резерва.
Шаг четвертый. Отдельно задайте K_project для свободного места, spare, метаданных, единиц измерения и запаса на рост до следующего расширения.
Формула выглядит так: C_raw = C_base / K_usable × K_project. Значение около 600 ТБ остается иллюстрацией только при явно перечисленных коэффициентах. Закупочную и приемочную емкость подтверждают расчетом производителя и проектом СОРМ.
Рост на 15%: таблица на пять лет
Для проектного ориентира ниже показано пять ежегодных увеличений на 15 процентов. Конкретный календарь подтверждают применительно к дате акта и действовавшим для системы переходным решениям.
| Год | Коэффициент к базе | Требуемая емкость от 400 ТБ |
|---|---|---|
| Ввод в эксплуатацию | 1,00 | 400 ТБ |
| Через 1 год | 1,15 | 460 ТБ |
| Через 2 года | 1,32 | 529 ТБ |
| Через 3 года | 1,52 | 608 ТБ |
| Через 4 года | 1,75 | 700 ТБ |
| Через 5 лет | 2,01 | 805 ТБ |
Пять увеличений дают коэффициент 1,15⁵, то есть около 2,01. Это консервативное проектное допущение, а не право выбирать между четырьмя и пятью увеличениями. График должен быть подтвержден для конкретной даты ввода.
Таблица показывает C_base в терминах объема сообщений. Как значения переводятся в полезную и сырую емкость конкретного сертифицированного комплекса, фиксируют в проекте, спецификации и приемочных документах.
График расширения привязывают к дате акта, а не к заполнению массива. Параметры дисковых систем проверяют на конечную емкость, доступность полок, лицензии и время поставки до закупки.
Полезная и сырая емкость: куда девается разница
Raw, usable и нормативная емкость не являются взаимозаменяемыми терминами. Их соответствие описывают в расчете производителя и приемочной методике.
Коэффициент схемы зависит от числа дисков, четности, spare, распределения данных и ограничений СХД. Его берут из спецификации целевой конфигурации, а не из универсального процента.
Метаданные, служебные разделы и файловая система также уменьшают доступный объем. Их долю подтверждают расчетом для выбранного ПО и размера массива.
Свободное место и запас под расширение относятся к проектным параметрам. Их указывают отдельно, чтобы не выдавать эксплуатационный резерв за требование Правил.
Разница между C_base и C_raw складывается из K_usable и отдельно раскрытого K_project. Все коэффициенты должны быть воспроизводимы в спецификации.
Согласуйте единицы: 1 TB равен 10¹² байт, а 1 TiB равен 2⁴⁰ байт. Счетчики трафика, расчет и коммерческая спецификация должны использовать одну систему единиц.
Требования к системе хранения под этот профиль
СХД работает с непрерывным входным потоком и чтением по запросу. Помимо средней скорости учитывают burst, число потоков, размер записи, одновременную выгрузку и работу во время rebuild. Отдельно проверяют длительную запись без переполнения кеша, сохранение потока при отказе контроллера и влияние фоновых операций. Приемочный тест проводят на требуемой конечной конфигурации или на модели, позволяющей обоснованно пересчитать результат.
Sustained ingest должен укладываться в производительность при штатной записи, отказе диска, восстановлении массива и параллельной выгрузке. Эти режимы проверяют нагрузочным тестом.
Для дисков фиксируют технологию записи. SMR может требовать специальной поддержки и вести себя иначе при перезаписи, поэтому допустимость конкретной модели подтверждают матрицей совместимости и тестом кольцевой нагрузки.
При одинарной четности второй отказ в группе до завершения rebuild обычно делает массив нереконструируемым. Двойная четность рассчитана на два отказа, а критическим становится третий либо сочетание с необнаружимой ошибкой чтения. Время реконструкции измеряют под рабочей записью, фиксируя размер группы, приоритет rebuild и влияние на ingest.
Пункт 4(1) Правил требует действующего на момент установки заключения по ПП №719 для поставляемого технического средства накопления информации и указанного состава. Запись в реестре проверяют по производителю, модели, комплектности и сроку действия, а не по отдельным дискам.
Заложить расширение конструктивно
Расширение должно быть предусмотрено в исходной архитектуре. До закупки проверьте:
- Отсеки и полки расширения, предел числа дисков, портов и полок, совместимость и подтвержденные сроки поставки;
- Лицензии на емкость, контроллеры, функции распределения данных и условия расширения без остановки записи;
- Место в стойке, независимое питание, охлаждение и сеть рассчитывают под конечную конфигурацию.
Если конечная емкость превышает предел масштабирования, потребуется новая СХД или миграция. Подбор СХД учитывает этот порог до первой закупки.
Ошибки, которые искажают расчет
- Расчет по внешнему каналу вместо согласованных точек консолидации включает лишний транзит или теряет межабонентский трафик.
- Отсутствие календаря увеличения приводит к внеплановой закупке. Постройте график от даты акта и подтвердите число увеличений.
- Смешение C_base, usable и raw дает несопоставимые цифры в проекте и договоре. Зафиксируйте определения и коэффициенты.
- Сезонность используется как проектный риск, но не заменяет установленный период 30 суток перед вводом.
- Применимость пунктов для голоса и передачи данных нельзя выводить по общему названию услуги. Сверьте лицензии и действующую редакцию ПП №445.
Контрольные даты и итог расчета
Методика опирается на согласованный период трафика и дату акта. Первый задает C_base, вторая запускает календарь ежегодного увеличения.
Зафиксируйте точки консолидации и объем за 30 суток. Затем согласуйте связь C_base с usable и raw, получите K_usable и K_project, постройте график на пять лет и проверьте масштабирование, rebuild и ingest конечной конфигурации.
Расчет остается инженерной методикой, а не готовым юридическим заключением. Для оборудования для провайдеров связи передайте согласованный объем, дату акта и требования проекта, чтобы сформировать спецификацию и график расширения.