Healthy authoritative path
Configured storage имеет приоритет над historical DR copies.
Backup · Repair · DR
Backup, Repair и DR: обновление защиты не должно требовать ручного восстановления файлов
Опубликованная 10.050 с установщиком r18 исправляет найденные при Repair дефекты 10.049: Healthy Repair выбирает configured storage, mutable public assets сохраняются отдельно от canonical package, а rollback должен вернуть webroot, DB, identity и Challenge assets в предыдущее состояние.
Installer r18Signed releaseMutable assets preservedTransactional rollback
Repair transaction
Storageconfigured path
VERIFIEDMutable snapshot20 assets
SAVEDMigration10049 → 10050
PASSActivationruntime validation
COMMIT_READYPUBLISH/COMMIT выполняются только после verification; build PASS сам по себе не означает безопасную публикацию.
Production recovery
Repair — это transaction с источниками истины, а не «распаковать архив поверх сайта»
Код релиза, private state и mutable public artifacts имеют разные owners/source-of-truth. Repair r18 сначала собирает доказательства, делает snapshot, проверяет package/migration/runtime и только затем активирует новое состояние.
Assets переживают replacement
Custom public derivatives snapshot/preserve/regenerate вместо потери при atomic webroot switch.
Точный возврат
При injected failure возвращаются old webroot, DB/prestate, markers, identity и mutable artifacts.
Архитектура
State machine до COMMIT_READY
Installer хранит transaction journal и знает текущий stage: от ENVIRONMENT_OK и STORAGE_VERIFIED до MUTABLE_PUBLIC_RESTORED, RUNTIME_VERIFIED и COMPLETE.
Discover/verify
Environment, source, storage, package, signatures.
Snapshot
DB/prestate и разрешённые mutable public artifacts.
Stage
Развернуть canonical payload отдельно от active webroot.
Migrate
Выполнить idempotent migration 10050 и проверить DB.
Restore/validate
Вернуть mutable assets, permissions, runtime, policy, license state.
Commit/rollback
Активировать только после checks; при failure восстановить prestate.
No blind copy. Нельзя копировать весь старый webroot поверх canonical package или broad-scan storage при здоровом configured path.
Что умеет модуль
Что входит в lifecycle 10.050
Это не только updater: один installer должен поддерживать Clean Install, Update, Repair-Upgrade и Disaster Recovery в пределах policy.
Healthy Repair
Configured storage selection без ложного RECOVERY_STORAGE_AMBIGUOUS из-за sibling backups.
Подробнее →Mutable preservation
Declarative registry разрешённых runtime-generated public artifacts.
Подробнее →Self-healing assets
Custom derivative можно регенерировать из private source; builtin — восстановить из signed package.
Подробнее →Rollback journal
Transaction ID, stages, source/target versions, mutable count и rollback status.
Подробнее →Signed release
Manifest, hashes, signatures и separation software/network/license trust.
Подробнее →Acceptance matrix
Clean Install, Update, Repair, DR, Rollback, canary и PHP 7.4 checks.
Подробнее →Readiness & evidence
CURRENT_CANONICAL — это больше, чем совпавший номер версии
Update Center различает identity/build/metadata drift и не должен считать установку здоровой только потому, что version string совпала.
CURRENT_CANONICAL
Canonical identity совпадаетVersion/build/provenance соответствуют опубликованному release.
BUILD_DRIFT
Canonical file изменёнЛокальное изменение application file обнаружено.
REPAIR_AVAILABLE
Есть repair pathУстановка восстановима подписанным package.
CORRUPT
Нарушен required invariantНужен controlled Repair/DR, а не suppress ошибки.
Практическое применение
Когда нужен каждый режим
Одинаковая кнопка «переустановить» не подходит всем состояниям установки.
UPDATE
Связанный сценарий →Рабочая canonical 10.049
Подписанный переход по поддерживаемой chain до 10.050.
REPAIR
Связанный сценарий →Код повреждён, private state здоров
Восстановить canonical app, сохранив identity/storage/mutable artifacts.
DR
Связанный сценарий →Webroot потерян
Найти и валидировать recovery storage, затем восстановить приложение.
ROLLBACK
Связанный сценарий →Ошибка в transaction
Вернуться к точному предыдущему состоянию без ручного cp/chmod.
Release discipline
«Тесты зелёные» не равно «релиз готов»
Релиз 10.050 опубликован. Перед применением на конкретном сайте отдельно проверяются совместимость, резервная копия и подходящий сценарий Install/Update/Repair/DR. Результат сухого прогона восстановления не равен выполненному восстановлению; условные SKIP не должны подменять обязательные проверки.
FAQ
Вопросы про Repair и DR
Чем Repair отличается от Update?
Update переводит поддерживаемую canonical версию на следующую. Repair восстанавливает повреждённую/дрейфующую установку, сохраняя authoritative private state и identity.
Почему раньше могли пропадать Challenge assets?
Atomic webroot replacement заменял mutable public derivatives canonical package. В 10.050 эти artifacts имеют отдельный preservation/self-healing lifecycle.
Что если рядом лежат старые DR copies?
Healthy Repair сначала валидирует configured storage и не должен выполнять broad discovery, пока он здоров.
Нужно ли вручную chmod после Repair?
Нет по release invariant 10.050: managed permissions/assets должны восстанавливаться и валидироваться автоматически.
Следующий шаг
Проверим installation health перед Repair/Update
Сначала подтвердим canonical build, storage, identity, backups и mutable assets — и только потом будем менять production webroot.