Files
progcode/editorial/reviews/2020-10-draft.md
T
huncode 2ffa7a40eb
Build and deploy / deploy (push) Successful in 13s
revise October 2020 backup articles
2026-07-31 11:49:22 +03:00

15 KiB
Raw Blame History

Октябрь 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 Пакет разбирает только учебный logical dump. Он не называет его PITR, полной копией кластера или disaster recovery.
pg_dump создаёт dump одной базы; custom archive читается pg_restore; выбор схемы может не включить нужные зависимости PostgreSQL 12: pg_dump Scope записывает includes и excludes, а проверка list archive предшествует restore. Отдельная схема не объявлена самодостаточной без доказательства.
Cluster-wide объекты, включая роли и tablespaces, требуют отдельного рассмотрения PostgreSQL 12: pg_dumpall Учебный manifest явно исключает роли и tablespaces. Их отсутствие не маскируется зелёным статусом одного database dump.
Non-plain archive восстанавливается и диагностируется через pg_restore PostgreSQL 12: pg_restore В статье list archive — отдельный gate. Успешный list не подменяет structural или semantic checks после restore.
SHA-256 сравнивает bytes артефакта, а не прикладную пригодность восстановленного набора NIST FIPS 180-4: Secure Hash Standard 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 остаётся источником её фактической записи.