Кейс: кассеты «пропали» из реестра — форма штрихкода и LTO-суффикс

1. Ситуация

Холодный класс на ленте, кассеты заведены, часть архивов записана. Через какое-то время в GUI появляются предупреждения о том, что кассет меньше, чем ожидалось, а minimum_tape_safety падает в ноль. Архивация и restore при этом ведут себя непоследовательно: часть объектов возвращается, часть «висит».

Интуитивная реакция — проверить библиотеку: слоты, приводы, I/E station. Библиотека показывает кассеты на местах. Продукт — нет.

2. Что видели

1. Событие о недостатке кассет / нулевом safety.
2. В списке носителей продукта часть кассет имеет состояние, не соответствующий реальному.
3. Число «отсутствующих» кассет медленно растёт или скачком появляется после обновления каталога.
4. Библиотека (своей консолью) показывает нормальное наличие.
5. В реестре кассет, который ведёт оператор, штрихкоды записаны в полной форме, включая суффикс поколения.

3. Механизм

Штрихкод кассеты LTO обычно имеет две части: собственно номер и суффикс поколения — например, номер плюс L8 для LTO-8. Библиотека отдаёт штрихкод целиком.

Продукт при сопоставлении отрезает две последние позиции — нормализует штрихкод до «номера без поколения». Логика разумная: кассету можно перемаркировать под другое поколение, номер остаётся. Но реестр, который ведёт оператор, часто хранит полную форму.

Дальше простое следствие: строка 000281 в продукте и строка 000281L8 в реестре — для системы разные носители. Кассета, которую «внесли в реестр», для продукта не внесена; кассета, которую продукт видит, в реестре оператора отсутствует. Safety считается по тому набору, который видит продукт.

Второй, более редкий сценарий того же класса: перемаркировка кассеты под другое поколение. Номер тот же, суффикс другой — продукт считает это той же кассетой, а оператор — новым носителем.

Третий: кассета, которая числится отсутствующей дольше заданного окна, автоматически снимается с учёта (у нас — при отсутствии более 96 часов и в пределах порога допустимых «пропавших»). После этого вернуть её в учёт нужно явным действием, а не ожиданием.

4. Как это доказали

1. Взяли штрихкод кассеты из консоли библиотеки — полная форма с суффиксом.
2. Нашли ту же кассету в списке носителей продукта — номер без суффикса.
3. Сравнили списки программно (список библиотеки против реестра с вычтенным суффиксом) и увидели, что расхождение исчезает, если нормализовать обе стороны одинаково.

Это и есть корень: не «библиотека врёт» и не «продукт сломался», а две разные формы одного идентификатора.

5. Что сделали

1. Привели реестр к форме продукта — штрихкоды хранятся без LTO-суффикса. Это единственная форма, которая совпадает со штатной нормализацией.
2. Пересобрали каталог кассет из фактического состояния библиотеки, а не из журнала оператора: список библиотеки — источник истины по физическому наличию.
3. Сверили safety после синхронизации: он должен считаться, а не оставаться нулевым при живых кассетах.
4. Зафиксировали правило маркировки: на всех новых кассетах форма штрихкода одна и та же, суффикс поколения в реестр не пишется.
5. Добавили проверку в регламент: после каждого пополнения библиотеки — сверка «библиотека против продукта», до первой записи архивов.

Физически кассеты не трогали: перезаписи, перемаркировки и «перезаведения» носителей не потребовалось. Проблема была в форме идентификатора, а не в носителе.

6. Проверка результата

Проверять надо именно после цикла проверки коннектора, а не сразу: список пересобирается не мгновенно.

7. Уроки

1. Штрихкод — это идентификатор в системе, а не надпись на наклейке. Форма важнее содержания.
2. Продукт нормализует, человек — нет. Везде, где сравниваются списки, нормализовать надо обе стороны одинаково.
3. Один формат на все кассеты. «Кто как наклеил» превращается в класс инцидентов.
4. Safety — расчётная величина, и она считается по тому, что видит продукт. Ноль не всегда значит «кассет физически нет».
5. Автосписание существует. Кассета, отсутствующая дольше окна, уходит из учёта сама — и её возврат требует действия.
6. Источник истины по наличию — библиотека. Журнал оператора удобен, но не первичен.

8. Что не стоит делать

• Стирать кассеты, чтобы «начать с чистого листа»: данные на них — это архив, а не тестовый набор.
• Удалять кассету из библиотеки, пока она заведена в продукте: получите ровно тот же класс «пропавших».
• Массово помечать носители неиспользуемыми (media unused --delete пачкой): safety обвалится, а вернуть учёт можно только явной операцией.
• Перемаркировывать кассеты «под продукт», меняя номер: номер — единственное, что связывает физический носитель с записью в реестре.
• Править реестр вручную по одной строке без сверки: ошибка в одном штрихкоде выглядит как «пропавшая кассета» и уводит разбор в сторону.

Источники

• Cold Storage Tech Brief (доступ 2026-11-07)
• Release Notes 7.3 (доступ 2026-11-07): Tape Space Reclamation, LTO-10, правило COLD_STORAGE_INVALID_BARCODE_DETECTED (7.1)
• Наша практика (обезличенно): ведение реестра кассет и разбор safety = 0 на стенде с холодным классом; окно автосписания и порог «пропавших» — параметры нашей конфигурации, не вендорский факт.
• Обновлено: 2026-11-07.