Бэкап, который проверяют: restic, Borg 2.0 и Kopia — чанкинг, дедупликация и восстановление

Аннотация

У дедуплицирующего бэкапа есть несколько разных признаков исправности: ссылки на блоки существуют; сохранённые байты читаются и проходят криптографическую проверку; файлы записываются на новую файловую систему; приложение действительно работает с восстановленными данными. Название check или verify само по себе не говорит, какой из этих уровней проверен. У restic и Kopia обычная проверка не перечитывает весь файловый payload; у Borg 2.0 есть дополнительное различие между проверкой хешей packs и криптографическим аудитом содержимого чанков.¹²³

Данные на 2026-11-04. Закреплённые версии: restic v0.19.1, Borg 2.0.0b25, Kopia v0.23.1.⁴⁵⁶ Borg 2 рассматривается именно как beta: официальный сайт предупреждает «do not use it in production», стабильная серия — 1.4, текущий stable — 1.4.5. Это не сравнение трёх одинаково готовых production-вариантов.⁷

Допущение автономного обзора: небольшой self-hosted парк, один администратор, общий online-репозиторий на локальном либо удалённом хранилище. Изучены документация, tagged source code, release notes и академические работы; реальные репозитории не открывались, backup/restore и corruption experiments не запускались. Главный вывод — выбирать нужно не только алгоритм дедупликации, но и проверяемый путь восстановления с независимым доступом к ключам. Численного рейтинга скорости и обещаний RTO здесь нет.

Введение

Цель — сравнить три модели по цепочке «файл → чанки → packs/index → проверка → восстановление → удаление истории». Вопросы обзора: что именно переиспользуется между снимками; где находятся незаменимые данные; что читает стандартная проверка; как распределить дорогой аудит; какие ошибки может скрыть успешная материализация файлов; что остаётся от защиты при компрометации backup-клиента.⁸⁹¹⁰

Это продолжение, а не повторение предыдущих обзоров. В статье о self-hosted фото рассматривался состав резервной копии приложения; в обзоре SQLite — согласованная копия живой базы; в сравнении NixOS, Ansible и Compose — границы отката конфигурации. Здесь предмет другой: уже выбранный набор файлов превращается в общий граф блоков, и требуется доказать, что этот граф можно прочитать и превратить обратно в нужные данные.

Границы. Не рассматриваются тарифы облаков, ленточные архивы, полная матрица ACL разных ОС и безопасность конкретной настройки NAS. Не выбирается «самый быстрый»: исследование CDC измеряет отдельный алгоритм, тогда как backup-продукт дополнительно выполняет хеширование, сжатие, шифрование, индексирование и I/O. Подмена одного другим даёт красивый, но непригодный для выбора рейтинг.¹¹

1. Чанк, его идентификатор и pack — три разных вещи

Content-defined chunking определяет границы по содержимому, а не по фиксированным смещениям. Поэтому вставка в начале файла не обязана сдвигать все последующие блоки, как при fixed-size chunking. Но функция, выбирающая границу, — не та же функция, которая даёт чанку криптографический ID. Первая отвечает за повторное использование похожих областей; вторая — за адресацию и проверку содержимого.¹¹⁸⁹

В restic v0.19.1 используется Rabin fingerprint со скользящим окном 64 bytes. Документация указывает диапазон чанков 512 KiB–8 MiB и целевой средний размер 1 MiB; файлы меньше 512 KiB вообще не делятся. Последняя оговорка важна: писать «все объекты restic не меньше 512 KiB» неверно. Полином выбирается при создании репозитория и сохраняется в его config; ID открытого содержимого — SHA-256.⁸

В Borg 2.0.0b25 встроенный default — уже FastCDC, fastcdc,19,23,21,2: минимум 512 KiB, максимум 8 MiB, цель около 2 MiB, normalization level 2. Это не привычный по Borg 1 buzhash. Для encrypted modes ID открытого чанка задаётся keyed hash/MAC; отдельный unkeyed BLAKE3 store hash именует объекты нижнего слоя. Смешивать эти уровни в формуле «Borg проверяет хеш» нельзя: они удостоверяют разные свойства.⁹

В Kopia v0.23.1 default splitter — DYNAMIC-4M-BUZHASH. Имя обозначает динамическое разбиение, а не постоянные блоки ровно по 4 MiB. Архитектура разделяет content-addressable blocks, объекты произвольного размера и manifests снимков. Одинаковые блоки получают одинаковые идентификаторы в рамках соответствующей конфигурации репозитория и могут совместно использоваться разными объектами.¹⁰¹²

“A key property of block identifiers is that two identical blocks of data will produce exactly the same identifiers, thus resulting in natural de-duplication of data.” — Kopia, Architecture.¹⁰

Маленькие чанки помогают находить мелкие совпадения, но создают больше индексов и служебной работы; большие уменьшают эту накладную стоимость, но изменение затрагивает более крупную единицу. Gregoriadis и соавторы исследуют именно этот компромисс, а не определяют победителя среди backup CLI. Их throughput-тест исключает fingerprinting полученных чанков и читает вход из RAMdisk; реальные наборы предварительно склеиваются в поток. Авторы прямо предупреждают, что это отличается от пофайловой дедупликации storage-систем.¹¹

Дедупликация также не создаёт независимую копию каждого снимка. Снимки могут ссылаться на один сохранённый блок; потеря этого блока затрагивает всех его потребителей. Li и соавторы формализуют отдельную проблему — фрагментацию: соседние части восстанавливаемого файла могут физически лежать далеко друг от друга. Это теоретическая работа о размещении и избыточности, не измерение restic, Borg или Kopia; она объясняет, почему высокий dedup ratio не является доказательством быстрого или устойчивого restore.¹³

2. Формат репозитория определяет цену обслуживания

У restic файл описывается упорядоченным списком blob IDs, каталог — деревом метаданных. Index связывает ID с pack, смещением и длиной. Pack объединяет несколько независимо зашифрованных и аутентифицированных blobs; его header позволяет восстановить индекс при сохранных packs. Это восстановление карты расположения, а не генерация исчезнувших пользовательских байтов.⁸

Новые репозитории restic v0.19.1 по умолчанию используют format 2; этот формат требует restic 0.14.0 или новее и поддерживает compression. Номер формата не совпадает с версией CLI. Аналогично Kopia v0.23.1 создаёт новые репозитории с default format 3: исторический пример с format 2 нельзя выдавать за текущий default.¹⁴¹⁵

У Kopia data packs имеют префикс p, metadata packs — q, indexes — x; индекс адресует содержимое внутри pack. В конце pack есть локальный индекс для восстановления при повреждении отдельных индексов. Поэтому «репозиторий — просто зашифрованные файлы» слишком слабая модель: без корректного восстановления связей между snapshots, objects, contents и packs сами blobs ещё не дают готовой файловой системы.¹⁰

У Borg b25 repository version — 5, объекты собраны в packs поверх borgstore. Changelog b25 прямо содержит предупреждение:

“Breaking changes (you must create new repos for b25)”.¹⁶

Следовательно, ранняя beta и b25 — не взаимозаменяемые форматы. Документация описывает перенос Borg 1 через transfer --from-borg1 в новый репозиторий, а не upgrade production-хранилища на месте. Связанные ключи и совместимый ID algorithm — только часть задачи: если нужно продолжать дедуплицировать новые backups против перенесённой истории Borg 1, важен и совместимый chunker; документация выделяет для этого buzhash. Переход на FastCDC меняет разбиение, даже если пользовательские файлы прежние.¹⁷¹⁸

У restic copy тоже есть похожая граница. Перенос между произвольными репозиториями допустим, но для ожидаемого переиспользования одинаковых данных нужны одинаковые chunker parameters. Их копируют при инициализации destination через --copy-chunker-params; у существующего репозитория эти параметры уже не меняются. Практический вывод: процедуру второй копии стоит проектировать до заполнения второго repository, а не после неожиданного роста объёма.¹

3. Что на самом деле доказывает check

restic: структура отдельно, чтение payload отдельно

В v0.19.1 обычный restic check проверяет структурную согласованность snapshots, trees и packs, но не удостоверяется в неизменности всех actual pack bytes. Для этого нужен check --read-data, который скачивает все pack files. Даже сообщения check all packs и no errors were found у стандартного запуска нельзя интерпретировать как полный аудит содержимого.¹

Для небольших регулярных проверок есть --read-data-subset. Форма n/t делит packs на группы: обход 1/5…5/5 покрывает фиксированный набор за несколько запусков. Процентная форма выбирает случайную часть и прямо не гарантирует полного покрытия после повторений. Если между этапами prune перепаковал содержимое, набор packs изменился: утверждение «мы закончили обход» требует учитывать именно проверяемый набор, а не просто считать завершённые jobs.¹¹⁹

Borg: обычная проверка сильнее простого наличия, но не равна verify-data

В b25 нижняя repository-фаза borg check сверяет store hashes index objects и packs и обнаруживает отсутствующие packs; archive-фаза читает metadata и проверяет ссылки на чанки. Первая стадия способна обнаруживать случайное повреждение pack bytes. Поэтому формула «у всех троих check читает только метаданные» неверна. Но unkeyed content-addressing нижнего слоя не заменяет криптографическую проверку файлового содержимого.²

borg check --verify-data дополнительно читает, расшифровывает и распаковывает данные, всегда пересчитывая plaintext chunk ID. Для ssh:// нижнеуровневые pack hashes может вычислить сервер без передачи всех packs клиенту; архивные проверки с расшифровкой выполняются на клиенте. Это различие маршрута I/O, а не доказательство, что Borg быстрее другого продукта на любом backend.²

--max-duration в b25 требует --repository-only: это распределение нижнеуровневой проверки по времени, без archive checks и без --verify-data. --max-age позволяет переиспользовать недавние результаты проверки intact packs. Ни одна из этих опций не означает «случайно восстановить N% файлов». Сопоставлять их с процентной проверкой Kopia можно только после указания проверяемого уровня.²

Kopia: полнота видимого графа и чтение file objects

В v0.23.1 kopia snapshot verify по умолчанию имеет --verify-files-percent=0. Проверяются доступные manifests, directory/indirect metadata и ссылки; для direct repository строится также карта backing blobs. Проверка через Repository Server не автоматически равна административному обходу всего физического хранилища: набор видимых manifests и доступ к blob map отличаются.²⁰

С --verify-files-percent=100 читаются все выбранные достижимые file objects: download, decrypt, decompress. Но реализация отправляет прочитанное в io.Discard, а не создаёт рабочую копию приложения. Это полезный полный тест пути чтения выбранного содержимого, не испытание записи на целевую ФС и не проверка всех возможных сценариев аварийного запуска.²¹

Иллюстрации синтаксиса для закреплённых версий ниже не выполнялись. Подразумеваются уже настроенные подключения; никакие пароли не передаются в командной строке. Полный аудит создаёт I/O, CPU и сетевую нагрузку, поэтому это не предложение немедленно запустить все команды на production.¹²²⁰

# restic v0.19.1: структура и чтение всех packs
restic check --read-data

# Borg 2.0.0b25: криптографический аудит repository/archive data
borg check --verify-data

# Kopia v0.23.1, доверенное direct/admin подключение
kopia snapshot verify --verify-files-percent=100 --file-parallelism=2

4. Почему ежедневный 1% не обещает проверить всё

В tagged-документации Kopia v0.23.1 есть сильное утверждение: ежедневный --verify-files-percent=1 якобы даёт за год «roughly 98% likelihood to have tested 100% of your backed up data». Код выбирает file objects по случайному условию 100*rand.Float64() < VerifyFilesPercent. Из него не следует обещание для всего набора данных.³²¹

Для одного неизменного объекта при независимых ежедневных выборах вероятность попасть хотя бы в одну проверку за 365 запусков равна 1 − 0.99^365 ≈ 97.45%. Это собственный расчёт по модели выборки, выполненный Python, а не измерение надёжности Kopia. Для условного фиксированного набора из 1000 отдельных объектов ожидается около 25.52 ни разу не выбранных объектов. Значит, вероятность покрытия отдельного объекта нельзя подменять вероятностью покрытия всех; сам процент задаётся не как строгая квота физических bytes или packs.²¹

Противопоставление — не «случайная выборка бесполезна». Она повышает шанс раннего обнаружения проблем при ограниченном бюджете. Но для доказуемого обхода фиксированного набора нужны учёт покрытия или полный проход. restic аккуратно формулирует эту границу для random subset; его n/t даёт другой контракт, не эквивалентный повторению случайного процента.¹

Рекомендация автора: отдельно логировать scope проверки, snapshot IDs, версию программы, дату последнего полного чтения и результат учебного restore. Частоту выбирать по допустимой потере данных, времени обнаружения и бюджету, а не по универсальному совету «раз в месяц». Источники подтверждают различие режимов, но не задают одну оптимальную периодичность для всех хранилищ.¹²³

5. Файлы появились — восстановление ещё не закончено

restic: verify существует, но это не полный тест приложения

В v0.19.1 у restore есть --verify, выключенный по умолчанию. После restore выполняется дополнительное чтение восстановленных regular files и проверка их содержимого по blob IDs. Код пропускает не восстановленные этой операцией файлы и metadata-only updates; это не обещание заново проверить весь snapshot, ACL и xattrs.²²²³

Есть и ловушка выбора: у restore latest --path ... параметр --path помогает выбрать snapshot, а не ограничивает восстанавливаемые файлы этим каталогом. Для отбора содержимого служат include/exclude либо форма SNAPSHOT:/subfolder. В drill надёжнее фиксировать ID и пустой target, чем полагаться на движущееся latest и смешивать уже существующие файлы с восстановленными.²⁴

Borg b25: предупреждение может означать нули вместо содержимого

borg extract --dry-run проходит путь чтения, расшифровки и распаковки без записи output files. Но в b25 при missing/corrupt content chunk extract не обязательно прерывается: соответствующая область файла заменяется нулями, логируется ошибка, возвращается warning exit code. Документация формулирует результат буквально:

“The extracted file thus has the correct size and metadata, but wrong (all-zero) content where the damaged chunks were.”²⁵

Поэтому проверка «каталог существует, размеры совпали» недостаточна. Нельзя считать warning успешным восстановлением. Кроме того, обычный пользователь может получить правильные bytes, но не исходного владельца: для части metadata нужны root или соответствующие capabilities; отсутствие восстановления ownership может не изменить exit code.²⁵

Есть ещё тонкость b25: default BORG_ASSERT_ID=repair,transfer,rechunk не включает read. Обычное чтение аутентифицирует envelope и привязку к chunk ID, но не обязано заново вычислять ID открытого содержимого. Для недоверенного клиента, ранее имевшего ключ, это отдельная угроза; check --verify-data всегда проверяет этот инвариант. Называть обычный extract «никак не проверяющим данные» тоже неверно: envelope authentication остаётся.²⁶

Kopia: успешное чтение не испытывает целевую файловую систему

В v0.23.1 restore по умолчанию допускает overwrite files/directories/symlinks и имеет ignore-permission-errors=true. Для строгого учебного восстановления полезно явно запретить игнорирование permission errors и восстанавливать в отдельное пустое место. --shallow создаёт placeholders и не подходит как подтверждение полной материализации. Это границы CLI, проверенные по tag-коду, не результаты проведённого здесь испытания.²⁷

Предлагаемый критерий приёмки одинаков для трёх инструментов: из независимого recovery environment получить доступ к конкретному snapshot/archive, выполнить полное чтение, материализовать данные, проверить содержимое и необходимые metadata, затем открыть приложение и проверить его собственные инварианты. Последние шаги — рекомендация автора: restore --verify, extract --dry-run и чтение в io.Discard по своему устройству не проверяют весь этот контракт.²³²⁵²¹

6. Retention, освобождение места и право удалить историю

Удалить snapshot — не то же самое, что освободить bytes

У restic v0.19.1 forget удаляет snapshots, а prune убирает недостижимые данные и может перепаковывать частично живые packs. Такая операция требует места и download/upload, а не только удаления нескольких файлов. Политика retention по умолчанию группируется по host,paths; сначала нужно смотреть forget --dry-run для реальных групп. Keep rules нельзя читать как простую сумму независимых квот.¹⁹

У Kopia v0.23.1 физическую очистку и compaction выполняет maintenance. Есть один maintenance owner; выключенный ноутбук-владелец не превращается в постоянно работающий GC-сервис. Код задаёт интервалы quick 1h и full 24h, но интервал не является гарантией, что обслуживание произошло. Safety delays защищают от опасного взаимодействия конкурентных операций; --safety=none — не штатная оптимизация нехватки места, документация прямо предупреждает о corruption.²⁸²⁹

Это не абстрактная осторожность. Kopia v0.23.1 исправляет rare race condition с возможной потерей данных и рекомендует upgrade. Issue #5371 описывает выбор неполного набора epoch indexes при определённом сценарии compaction. Это подтверждённый дефект проекта, но не численная вероятность отказа и не доказательство, что обновление само восстановит уже потерянные данные.⁶³⁰

У Borg b25 check --repair прямо назван потенциально lossy: привести репозиторий к согласованности не означает вернуть утраченные байты. При несовпадении pack со store hash salvage его неповреждённых объектов в этой версии ещё не реализован. Поэтому ремонтируют не единственную оставшуюся копию вслепую: документация рекомендует предварительно сохранить отдельную копию repository.²

Append-only — граница полномочий, а не свойство шифрования

restic явно не обещает защитить repository от владельца storage, способного удалять файлы. Append-only обеспечивается отдельным backend/service, а полные полномочия для retention/prune остаются на доверенном maintenance-узле. Более того, скомпрометированный append-only клиент может добавлять garbage snapshots с подходящими timestamps, чтобы доверенный retention затем сам удалил хорошие. --keep-within защищает хорошие снимки только в соответствующем временном окне, а не навсегда.⁸¹⁹

С Borg 2 нельзя ни переносить старый --append-only, ни объявлять новую серию совсем лишённой аналога. В b25 есть серверный borg serve --rest --permissions=no-delete; default permissions — all, в legacy mode эта опция игнорируется. no-delete запрещает удаление и overwrite существующих archives/chunks, но implementation оставляет изменяемыми служебные namespaces, включая index/cache/config/locks. Это не WORM всего repository и не защита от обходного прямого доступа к backend.³¹³²

Kopia Repository Server убирает underlying storage credentials с клиентов и ограничивает manifests пользователя. Но документация устанавливает важную границу:

“Only snapshot and policy manifests are access-controlled, not the underlying contents.”³³

Аутентифицированный пользователь, знающий valid object ID, может прочитать соответствующее содержимое. Это полезная серверная граница доступа, но не независимые криптографические tenants. Общий репозиторий ради дедупликации нельзя автоматически считать безопасной изоляцией недоверяющих друг другу пользователей.³³

Ключи входят в backup, даже если лежат отдельно

У restic смена password не отзывает уже утёкший master key; threat model требует пере-шифровать repository, например через copy в новый с новым master key. У Borg b25 экспорт ключа не содержит passphrase: зашифрованному export нужна исходная passphrase, а change-passphrase не заменяет data encryption/MAC keys. Наличие сохранных packs без пригодного пути расшифрования не означает восстановимость.⁸³⁴

FAQ Kopia v0.23.1 предупреждает об отсутствии recovery забытого пароля, но отдельно допускает смену password при сохранённом работающем direct-подключении с доступным секретом. Implementation повторно шифрует repository configuration, а не все data packs. Поэтому запасной доступ, смена password и ротация утёкшего content key material — разные операции.³⁵³⁶

7. Как выбирать и что записать в runbook

restic стоит оценивать, если нужен явно разделённый цикл snapshots/forget/prune и понятный выбор между structural check, full pack read и распределёнными n/t-проверками. Цена этой ясности — самостоятельно связать retention, дорогой аудит и restore drill в одну процедуру. Отдельно помнить: быстрый backup неизменившегося файла может опираться на file-change detection; это другая оптимизация, не доказательство, что исходный файл каждый раз перечитан полностью.¹¹⁹³⁷

Borg 2.0.0b25 интересен как новая архитектура: FastCDC, packs, отдельные store/chunk hashes, изменённые permissions.⁹³¹ Но для единственной production-копии официальный запрет на beta важнее преимуществ формата. Практический выбор стабильного Borg 1.4.5 требует собственного runbook его команд: переносить строки b25 в 1.x нельзя.⁷ Миграцию разумно изучать на дополнительном repository, не удаляя рабочую историю.¹⁸

Kopia стоит оценивать, если нужны policy/maintenance и repository server в одной системе. При этом операционный контракт должен явно фиксировать maintenance owner, direct/admin scope проверки и процент чтения файлов. Иначе автоматическое обслуживание выглядит как доказанный restore, хотя full verify и restore проверяют разные уровни, а server connection может видеть не весь repository.^20212833

Предлагаемый минимальный runbook, не универсальный стандарт частоты:

• Зафиксировать версию CLI, format, backend, список источников и исключений, конкретный snapshot/archive ID; для restic различать дедупликацию и shortcut определения изменений.¹⁴¹⁵³⁷
• Хранить отдельно доступные из recovery environment ключи/passphrases и процедуру открытия repository; проверить, что она не зависит от единственной погибшей машины.⁸³⁴³⁵
• Разделить jobs проверки структуры, полного чтения содержимого и материализованного восстановления; записывать scope и exit status, не только наличие финальной строки в логе.¹²²¹²⁵
• Разнести права backup-клиента и maintenance там, где выбранная серверная модель это позволяет; проверить retention до физической очистки.¹⁹³¹³³
• После восстановления отдельно принять содержимое, metadata и работу приложения; предупреждения о нулях и permission errors считать результатом проверки, а не шумом.²⁵²⁷

Дискуссионные вопросы и противоречия

«Verify — эквивалент test restore». Документация Kopia использует близкую формулировку для полного чтения, но код пишет в io.Discard. Противоречие разрешается разделением критериев: восстановление bytes из репозитория действительно испытывается; запись на выбранную ФС, права и запуск приложения — нет. Для отчёта о готовности это разные результаты.³²¹

«Daily 1% проверяет всё за год». Это не просто различие терминов: вероятность для одного объекта ошибочно распространяется на весь набор. Выборка полезна, но её статистическую границу нужно считать явно; для полного охвата использовать полный аудит либо отслеживаемый обход.³²¹¹

«Borg использует buzhash» и «в Borg 2 удалили append-only». Обе фразы сохраняют часть истории, но неверно описывают b25 целиком. Default сменился на FastCDC, а старый флаг заменён другой серверной моделью.⁹³¹ Для dedup-compatible миграции buzhash по-прежнему важен; no-delete не делает неизменяемыми все служебные объекты.¹⁷³²

Документация против tag-кода. Getting Started Kopia показывает daily/weekly retention, отличающиеся от defaults кода v0.23.1.³⁸ Для этой версии код задаёт daily 7 и weekly 4, но действующая политика конкретного repository может быть иной. Источник противоречия — смешение иллюстративного guide и текущих defaults; production-политику всё равно требуется прочитать отдельно.³⁹

Недостаточность данных

Нет сопоставимого рейтинга производительности. Найдены вторичные сравнения, но их числа не использованы как доказательство для этой тройки закреплённых версий. Академический CDC benchmark изолирует алгоритмы и не измеряет полный backup/restore. Не установлены throughput, peak RAM, dedup ratio и RTO на общем dataset, backend и cache state; превращать алгоритмический выигрыш в обещание продукта нельзя.¹¹

Нет end-to-end проверки отказов. Не испытывались повреждение packs, исчезновение индекса, потеря ключей, фактическое enforcement server permissions и восстановление приложения. Документация и source code подтверждают контракт, но не надёжность конкретного NAS, clock synchronization, IAM или целевой ФС.²³²⁷ Все команды в обзоре — иллюстрации, не журнал выполненного recovery.

Нет универсальной совместимости metadata. Какие ACL, privileged xattrs и owners переживут переход между конкретными ОС и файловыми системами, здесь не проверялось. Даже Borg документирует зависимость части результата от привилегий, а Kopia допускает игнорирование permission errors по умолчанию. Этот пробел закрывается испытанием конкретной пары source/target, не дополнительной строкой check.²⁵²⁷

Заключение

Три системы экономят место за счёт совместного использования содержимого.⁸⁹¹⁰ Но наличие ссылок и очередной успешный job ещё не доказывают, что приложение можно вернуть. В отчёте о проверке нужны раздельные ответы: что проверено структурно, какие bytes перечитаны, что реально материализовано и какие прикладные проверки прошли.²¹

Из сравнения не следует один победитель. У restic явно отделены full pack read и subset. Borg b25 различает нижнеуровневую и криптографическую проверки, но проект не рекомендует эту версию для production.⁷¹² У Kopia связаны policy, maintenance и repository server; для проверки существенны scope подключения и фактические defaults.²⁰²⁸ Выбирать стоит тот вариант, для которого администратор способен выполнить и повторить полный recovery-контракт.

Quality Metrics

Единица учёта — отдельный документ, release note или файл исходников; разные представления одного файла объединены, release API не добавлен к соответствующему релизу как независимая работа. Числа found/read вычислены из объединённого manifest трёх исследовательских веток и дополнительного поиска; read означает прочитанные релевантные разделы с сохранёнными выдержками, не обязательное изучение всех строк каждого файла. Категории относятся к процитированному набору; issue разработчиков отнесён к official primary. Две академические работы — version-pinned arXiv manuscripts: прочитаны механизм/методология, но математические доказательства независимо не проверялись. Это не 39 независимых испытаний: основная доказательная база — документы самих трёх проектов. Покрытие считается по содержательным абзацам, не по числу прочитанных страниц.