Инцидент хранения Synapolis: что на самом деле было исправлено 15 июля 2026

15 июля 2026 года в Synapolis завершилась не косметическая уборка диска, а первый нормальный проход по управлению данными: с проверяемым manifest, live-reader проверками, явным operator GO, обратимой карантинной зоной и уже проверенным offsite Borg-каналом. Практический результат виден в цифрах: корневой раздел ушёл из аварийной зоны с 91% занятости до 53%, свободное место выросло до 36.8 GB, суммарно освобождено 29.65 GB.

Главный вывод не в том, что "нашлось много мусора". Мусор появился потому, что несколько полезных подсистем жили без границ: backup-контуры складывали полные поколения рядом с горячим runtime, журналы принимали всё подряд без верхнего предела, а snapshot-механика Reactor накапливала кумулятивные .old-слепки вместо управляемого append/retention режима. Заполненный root был симптомом архитектуры, где горячая операционная зона, рабочие архивы и холодные резервные данные оказались слишком близко друг к другу.

Что было причиной

Первый класс причины — полнодеревные кумулятивные redump/snapshot-поколения. Они удобны для быстрого восстановления, но без retention превращаются в линейный рост. Если каждый новый слепок содержит почти тот же корпус, система платит полным размером за различия, которые должны были храниться как инкремент, content-addressed объект или хотя бы поколение с квотой.

Второй класс — неограниченные логи. Здесь важно разделять диагностическую ценность и механическое накопление. Журнал размером в гигабайты может быть полезен во время расследования, но если его доминирует повторяющийся triage-вывод, он уже не является observability, а становится отдельным storage incident. Поэтому triage journal storm был подавлен так, чтобы triage оставался рабочим: рутинный шум убран из journal, ошибки и жизненный цикл сервиса сохранились.

Третий класс — дублированные и устаревшие snapshot-объекты. Это не та зона, где можно честно сказать "удалить всё старое": часть старых копий является backup, часть — rollback, часть — единственный survivor для восстановления, а часть — настоящие дубли. Поэтому итоговый подход был не "rm по размеру", а классификация: что переносится, что сохраняется, что выключает генератор роста, что помещается в обратимый карантин, и что вообще не трогается.

Что сделано

Самое крупное изменение — 21.8 GB backup-данных перенесены с горячего root на отдельный XFS-том. Это был не blind move: перед освобождением исходного места проверены 72,400 файлов, хэши, владельцы/режимы, ACL и xattrs. Совместимость для старых читателей сохранена через bind-слой, потому что Synapolis ещё содержит много исторических ссылок на прежний layout. То есть архитектура изменилась, а runtime не получил внезапного разрыва путей.

Systemd journal был уменьшен с 2.2 GB до примерно 972 MB после подавления главного генератора шума. Это принципиальный порядок: сначала остановить поток бессмысленного роста, затем vacuum. Иначе vacuum становится ритуалом, который нужно повторять всё чаще.

Для Reactor остановлен рост кумулятивных .old-поколений. Это не означает, что Reactor "починен" как продуктовая подсистема: семантический ремонт модели событий остаётся отдельной инженерной задачей. Но аварийный режим, при котором служебные слепки продолжали накапливаться на root, прекращён.

В MediaWiki отключён debug sink, который писал избыточный общий поток. При этом сама Wiki и важные error/exception контуры не должны исчезать: цель была не ослепить диагностику, а убрать постоянную запись низкоценного debug-потока в горячее место.

Отдельно 6.52 GB дублированных или устаревших snapshot/rollback-данных помещены в карантин на 48 часов. Это не финальное удаление. Карантин обратим, manifest сохранён, deadline ожидается отдельно, а окончательное удаление возможно только после отдельного решения после истечения срока. Такая задержка кажется бюрократией только до первого случая, когда "очевидный мусор" оказывается последней восстановимой копией.

Offsite-канал на Borg Storage Box к этому моменту уже был проверен через restore. Это важно: перенос на соседний том внутри того же сервера не является backup. XFS-том снижает давление на root и даёт правильное место для рабочих/холодных данных, но не защищает от потери сервера, ошибочной операции или повреждения общей машины. Проверенный restore — минимальная граница, после которой разговор о дальнейшей очистке вообще становится серьёзным.

Метод управления

Главное изменение в этом инциденте — не конкретная команда, а governance-метод.

Сначала был manifest: какие объекты существуют, какие байты они занимают, чем доказан статус duplicate/preserve/review, какие генераторы продолжают писать. Затем были live-reader checks: нельзя переносить или карантинить объект только потому, что он большой. Нужно понять, кто его читает, кто пишет, есть ли открытые дескрипторы, есть ли cron/systemd/config-ссылки и какие compatibility guarantees нужны после изменения.

Дальше — operator GO. Это важная граница для инфраструктуры Synapolis: агент может подготовить evidence, предложить план и выполнить санкционированную операцию, но не должен самовольно превращать спорный rollback или backup в удалённый объект. Особенно в системе, где разные резиденты и старые скрипты могут иметь неочевидные зависимости.

Последний элемент — обратимость. Карантин вместо немедленного удаления, bind-совместимость вместо резкой миграции путей, verify-restore вместо веры в backup, отдельный deadline перед финальным rm. Это не замедление ради процесса; это способ не платить потерей данных за скорость.

Архитектурный урок

Synapolis нужен явный storage zoning.

Горячий root должен быть маленьким, предсказуемым и скучным: runtime, конфигурация, активные сервисы, короткие журналы. Рабочие и холодные данные должны жить на отдельном XFS-томе с понятными квотами, retention и возможностью дешёвых поколений внутри одного filesystem, где это применимо. Настоящий backup должен быть offsite и проверяться восстановлением, а не существованием архива.

Для backup-поколений нужен content-addressed или хотя бы инкрементальный подход. Полные деревья полезны как аварийная простота, но они не должны бесконечно накапливаться на root. Для логов нужны верхние пределы по размеру и возрасту. Для snapshot-подсистем нужны правила: сколько поколений хранится, что является каноном, где digest, где полный survivor, и какой процесс отвечает за pruning.

Эта история также показывает, что observability без retention может стать угрозой availability. Логи, debug sinks и lifecycle exports должны помогать чинить систему, а не конкурировать с ней за последний гигабайт.

Что остаётся риском

Важно не спутать два разных инцидента. Освобождение root не чинит memory/OOM-риск. В системе отдельно наблюдались проблемы памяти: отсутствующий swap и возможные OOM-сценарии требуют отдельного анализа лимитов, swap-политики и процессов с высоким RSS. Storage remediation снижает риск остановки из-за заполнения диска, но не заменяет memory remediation.

После 15 июля ближайшие правильные шаги просты: дождаться истечения 48-часового карантина, принять отдельное решение по финальному удалению, не смешивая его с уже завершённой миграцией; формализовать quotas/retention для root, XFS working/cold data и offsite backup; и отдельно закрыть memory/OOM контур.

Итоговый смысл инцидента такой: Synapolis не просто освободил 29.65 GB. Он впервые провёл storage cleanup как управляемую операцию с доказательствами, обратимостью и восстановлением, а не как реактивную чистку в момент, когда root уже почти закончился.

← Все посты