# Октябрь 2020 — тройное ревью автономного пакета П32 «Резервное копирование и восстановление» Статус: **принят независимым редактором в выпусковой набор**. Этот документ не переписывает базовый архив. В объектах revision нет полей date и author: слой публикации сохраняет стабильные метаданные исходных статей. Проверенные revision: - editorial-2020-10-practice-backup-recovery; - editorial-2020-10-mechanism-backup-recovery; - editorial-2020-10-field-backup-recovery. Модуль экспортирует ровно три revision. Режим --print-revisions пишет только JSON; режим --verify-fixture запускает детерминированную in-memory модель. Она не создаёт archive, не открывает PostgreSQL и не восстанавливает реальные данные. ## Проход 1. Факты, механизм и ограничения — пройдено | Утверждение или решение | Первичный / официальный источник | Проверенная граница | | --- | --- | --- | | PostgreSQL различает SQL dump, файловую копию и continuous archiving | [PostgreSQL 12: Backup and Restore](https://www.postgresql.org/docs/12/backup.html) | Пакет разбирает только учебный logical dump. Он не называет его PITR, полной копией кластера или disaster recovery. | | pg_dump создаёт dump одной базы; custom archive читается pg_restore; выбор схемы может не включить нужные зависимости | [PostgreSQL 12: pg_dump](https://www.postgresql.org/docs/12/app-pgdump.html) | Scope записывает includes и excludes, а проверка list archive предшествует restore. Отдельная схема не объявлена самодостаточной без доказательства. | | Cluster-wide объекты, включая роли и tablespaces, требуют отдельного рассмотрения | [PostgreSQL 12: pg_dumpall](https://www.postgresql.org/docs/12/app-pg-dumpall.html) | Учебный manifest явно исключает роли и tablespaces. Их отсутствие не маскируется зелёным статусом одного database dump. | | Non-plain archive восстанавливается и диагностируется через pg_restore | [PostgreSQL 12: pg_restore](https://www.postgresql.org/docs/12/app-pgrestore.html) | В статье list archive — отдельный gate. Успешный list не подменяет structural или semantic checks после restore. | | SHA-256 сравнивает bytes артефакта, а не прикладную пригодность восстановленного набора | [NIST FIPS 180-4: Secure Hash Standard](https://csrc.nist.gov/pubs/fips/180-4/final) | Hash — обязательная проверка до restore, но не сертификат полноты scope, ролей, внешних файлов или поведения приложения. | Технический разбор повторно сверил эти границы с кодом и текстом: - backup отделён от проверенного restore: archive, digest, archive list, isolated candidate и evidence остаются отдельными шагами; - manifest содержит scope, format, SHA-256, ожидаемые relations и safe checks, но не содержит URL, access key, пароля или реальных данных; - fixture отклоняет изменённые bytes и искусственно суженный scope, подтверждает две relations, синтетические row count и запрет перезаписи источника; - custom dump не выдан за копию cluster-wide объектов; роли, tablespaces и external files честно остаются за границей учебного маршрута; - строки о RPO/RTO сформулированы как вопросы и будущие измерения. В пакете нет вымышленного срока восстановления, production disaster recovery или заявления о зрелой SRE-программе. Реальный запуск --verify-fixture вернул девять истинных проверок: checksumMatches, byteCountMatches, scopeMatches, safetyMatches, expectedRelationsPresent, expectedRowsPresent, alteredBytesRejected, narrowedScopeRejected и sourceWasUntouched. Фикстура использует фиксированный 85-byte учебный buffer и synthetic manifest; это проверка контракта текста, не интеграционный test СУБД. Вердикт прохода: **пройден**. Источники поддерживают сказанное, а механика не выходит за проверенные границы. ## Проход 2. Редактура, голос М3 и объём — пройдено | Revision | Проблема и цена в первых двух абзацах | Практический путь | Тон и ограничение | | --- | --- | --- | --- | | Практика | Файл появляется по расписанию, но никто не знает, что вернётся из него; цена — неполный restore, риск затронуть источник и потеря времени в сбое | Scope → custom archive → manifest/hash → isolated candidate → relations и safe counts | Автор формирует первый runbook и не называет учебную пробу реальным RPO/RTO или production recovery. | | Механизм | Digest совпал, но restore может упасть на роли, зависимости или пустой relation; цена — принять целостность файла за готовность системы | Разделить evidence capture, bytes, format и semantics; зафиксировать их в manifest и gates | М3 связывает данные, delivery и безопасные проверки, но не изображает платформенную SRE-практику. | | Полевой разбор | Archive есть, а scope, target и критерий успеха не названы; цена — эксперимент над источником в момент сбоя | Собрать evidence packet, разобрать четыре симптома и пройти drill по нумерованному маршруту | Synthetic trace показывает метод, а не реальный инцидент, среду или достигнутые показатели. | - Draft gate измерил основной текст без разделов источников: практика — **10 835** знаков, механизм — **10 734**, полевой разбор — **10 778**. Все три текста находятся в требуемом диапазоне 5 000–15 000 знаков. - В первых двух абзацах каждого материала названы конкретные симптом и цена. Дальше сохраняется рабочая последовательность «симптом → причина → проверка → действие», а не общая речь о важности backup. - В каждом материале есть как минимум пять смысловых разделов, figure с содержательным alt/figcaption, таблица с caption/thead, воспроизводимый manifest/code или fixture, нумерованный маршрут и не менее двух официальных источников. - Язык короткий и технический: archive, scope, checksum, candidate и checks каждый раз связаны с конкретной операцией или критерием. Нет реальных данных, имён окружений, access key, URL, passwords, статуса production или фиктивных чисел RPO/RTO. Вердикт прохода: **пройден**. Статьи соответствуют М3 / октябрю 2020 года: автор уже документирует recovery drill, но не присваивает себе несуществующую операционную зрелость. ## Проход 3. Визуал и выпуск автономного пакета — пройдено в заданных границах - backup-recovery-contract-2020.svg показывает, почему scope, archive, manifest, isolated restore и evidence являются разными стадиями. Последняя подпись прямо разделяет byte-level checksum и смысловые checks. - backup-recovery-restore-path-2020.svg показывает шесть последовательных gate: scope, checksum, archive list, candidate, restore и evidence. У каждого есть отдельное условие остановки. - backup-recovery-diagnosis-2020.svg связывает четыре симптома с причиной, проверкой и безопасным действием, не добавляя destructive команды к источнику. - У всех SVG есть title, desc, role="img", вертикальный viewBox, контрастные карточки и короткие подписи. В них нет JavaScript, foreignObject, внешних URL, raster data URI или реальных данных. - Каждая схема отрендерена локально через Sharp при ширине **375 px** и просмотрена независимо. Первичный preflight нашёл одну длинную нижнюю подпись в схеме диагностики; она была разбита на две строки, SVG отрендерен повторно. Финальные версии не имеют визуального обрезания, наложений или горизонтального overflow. ### Фактические команды и результаты 
cd web
node --check scripts/upgrade-2020-10.mjs
npm run audit:draft -- scripts/upgrade-2020-10.mjs
node scripts/upgrade-2020-10.mjs --verify-fixture
xmllint --noout \
  public/assets/editorial/2020/backup-recovery-contract-2020.svg \
  public/assets/editorial/2020/backup-recovery-restore-path-2020.svg \
  public/assets/editorial/2020/backup-recovery-diagnosis-2020.svg
| Проверка | Реальный результат | | --- | --- | | node --check | код завершения 0 | | Draft audit | PASS: 10 835 / 10 734 / 10 778 знаков тела | | In-memory fixture | все девять логических checks вернули true; hash учебного buffer — ef4e31fd…90d419a | | XML | все три SVG валидны, код завершения 0 | | 375 px visual preflight | выполнен локальным Sharp-рендером; одна длинная подпись исправлена и финальные изображения просмотрены повторно | | Scope/self-review | revision не меняют date/author; registry, articles.json, standard, очередь, package config и Git не менялись | Не запускались PostgreSQL, pg_dump, pg_restore, cron, object storage, browser, CI, production build, deployment, внешний стенд или assistive technology. Sharp-проверка 375 px проверяет компоновку локального SVG, но не подменяет browser-review или проверку скринридером. Учебные команды и fixture не являются доказательством реального disaster recovery. ## Итог Статус: **тройное ревью пройдено; П32 принят к отдельной публикации**. Созданы только пять файлов, разрешённых задачей: 1. web/scripts/upgrade-2020-10.mjs; 2. editorial/reviews/2020-10-draft.md; 3. web/public/assets/editorial/2020/backup-recovery-contract-2020.svg; 4. web/public/assets/editorial/2020/backup-recovery-restore-path-2020.svg; 5. web/public/assets/editorial/2020/backup-recovery-diagnosis-2020.svg. Автономный авторский пакет не менял registry, articles.json, стандарт, очередь, package configuration или Git. ## Независимая интеграционная приёмка Основной редактор 31 июля 2026 года подключил три revision к web/data/editorial-revisions.mjs, не меняя базовый articles.json, даты или автора архивных записей. В registry стало 91 revision. Отдельно выполнены: | Проверка после интеграции | Реальный результат | | --- | --- | | Строгий audit трёх slug | PASS: 10 835 / 10 734 / 10 778 знаков; у каждой статьи есть figure, table и code examples | | Production build | PASS: Next.js собрал 374 статические страницы | | Независимый mobile visual review | PASS: основной редактор повторно просмотрел три SVG после Sharp-рендера в 375 px; clipping, overlap и overflow не обнаружены | Первичные PostgreSQL 12-документы сверены независимо: они действительно разделяют SQL dump, файловую копию и continuous archiving; pg_dump работает с одной базой, а cluster-wide объекты требуют отдельного рассмотрения. Ни этот отчёт, ни интеграция не утверждают запуск PostgreSQL, реальный backup/restore, browser или assistive technology. Выпусковой вердикт: **ACCEPT**. Commit и push выполняются отдельной публикационной операцией; Git остаётся источником её фактической записи.