IPFS: восстановление у другого хранителя
Предыдущий поставщик недоступен, но библиотека сохранила переносимый архив. В уроке составим восстановительный маршрут к новому хранителю, который сохраняет идентичность выпуска и не переключает читателей раньше готовности данных. Такой сценарий показывает практическую ценность отделения содержания от места выдачи.
Ни архив, ни новый аккаунт здесь не используются. Импорт и запросы pinning не выполняются. Все стадии и результаты — подготовленный договор будущей операции.
Идентичность до переноса
Из доверенной описи получаем releaseId, корневой CID, SHA-256 точных байтов манифеста, профиль импорта и формат архива. Проверяем, что запись относится к нужному курсу и редакции. Название файла backup-latest.car не является достаточной идентичностью.
Сначала получаем независимую копию и сверяем файловую контрольную сумму контейнера. Это защищает от незаметного изменения относительно известной описи, но ещё не доказывает состав. Затем разбираем архив и его корни совместимым инструментом.
Если формат неизвестен, не пытаемся обрезать заголовок и обработать остаток как CARv1 без спецификации. Выбирается поддерживаемый маршрут или другой архив. Неизвестная структура отражается как ограничение восстановления.
Импорт блоков
Новый клиент принимает блоковые записи и проверяет их связь с CID. Повреждённые данные не становятся допустимыми из-за того, что архив пришёл из знакомого облачного аккаунта. Доверие к месту хранения и криптографическая проверка содержания дополняют друг друга.
Импорт может создать блоки, но не установить всю политику удержания. Поэтому затем нужный корень закрепляется или включается в иной предусмотренный механизм долговременного хранения. Временный успешный просмотр не заменяет эту стадию.
копия архива → проверка байтов → разбор
→ импорт → полнота → удержание
→ независимое получение → переключение маршрутаКаждая стадия имеет собственное основание. Если произошёл сбой посередине, журнал сообщает последнюю завершённую точку, а не общий успех по факту существования каталога данных.
Проверка полного выпуска
От корня проходят необходимые связи и восстанавливаются объявленные файлы. Полученные байты манифеста сверяются с известным SHA-256 и допустимой схемой. Затем проверяются файлы по её описи.
Если корень читается, а изображение отсутствует, восстановление неполное. Не нужно заменять его новой картинкой и сохранять прежний статус идентичности. Такая правка создаст другой выпуск. Для восстановления требуется именно объявленная часть либо ясное сообщение, что она потеряна.
Если архив содержит только доказательный набор для одного пути, он может восстановить манифест, но не весь курс. Опись coverage помогает увидеть это заранее. При недостатке блоков ищем другую сохранённую копию, не заявляя о готовности всех уроков.
Новый хранитель
Поставщик получает тот же согласованный набор. Асинхронная задача отслеживается по собственному идентификатору до конечной стадии. Созданный аккаунт или полученный токен не являются доказательством наличия данных.
После завершения клиент проверяет доступность через выбранный маршрут. Если новый URL работает только для оператора с административной сессией, публичная выдача читателю ещё не подтверждена. Внутренний доступ и продуктовый маршрут различаются.
Новый поставщик может иметь свои лимиты и модель экспорта. Досье фиксирует их, чтобы восстановление не привело к новой закрытой зависимости. Переносимые блоки остаются частью собственного архива библиотеки независимо от чужого кабинета.
Переключение указателей
Когда новый набор готов, можно обновить разрешённый шлюз в приложении либо изменить операционное объявление провайдера. IPNS и DNSLink, если используются, сохраняют цель содержания или переключаются по редакционному решению. Сам CID прежнего выпуска не меняется только от переезда.
Читатель с точной ссылкой старого шлюза может увидеть отказ его оператора. Поэтому библиотека предоставляет понятный путь к другому месту того же содержания. Не заменяем выпуск на текущую редакцию без уведомления, называя это восстановлением старого.
Кэши могут некоторое время сохранять прежний маршрут или отрицательный ответ. Интерфейс различает доступность конкретного места и идентичность объекта. Повтор запроса выполняется с ограничениями, без бесконечного обхода случайных чужих источников.
Импорт блоков и повторная сборка — разные пути
Новый хранитель получил полный CAR и импортирует сохранённые блоки. Цель этого маршрута — сохранить именно прежнее content-addressed-представление. Если блоки корректны и достаточны, ожидаемый корень остаётся тем же. Повторная сборка из Markdown решает другую задачу: она сначала создаёт готовые файлы, затем заново импортирует их с профилем. Отличия генератора, зависимостей или метаданных способны дать новый корень ещё до попытки предоставить данные.
Поэтому для восстановления прежнего выпуска предпочтительно иметь сохранённые точные блоки и опись. Исходники полезны как отдельный резерв и для редактирования, но не дают автоматического обещания того же CID. Если повторная подготовка всё же нужна, результат сравнивают по согласованным уровням: файловым байтам, структуре и корню. Совпадение прочитанного текста при отличающемся HTML недостаточно для объявления восстановления точной редакции.
Новый хранитель может иметь успешный импорт, но ещё не удерживать корень по долговременной политике и не предоставлять его читателям. Процесс продолжает стадии хранения и выдачи. Старый поставщик не прекращается по одному локальному сообщению импортёра. Если собственный резерв расположен на отключённом носителе, его восстановление требует отдельного организационного времени, что отражается в обещании доступности библиотеки.
При независимом восстановлении важно не обратиться незаметно к прежнему источнику за отсутствующим блоком. Иначе успешное чтение скроет неполноту копии. Будущая процедура задаёт допустимые источники и фиксирует их использование. Сейчас такой опыт не проводился; сохранены модель и ожидаемые критерии. Эта граница позволяет позже отличить настоящее восстановление из собственного резерва от временно удачного получения недостающей части из сети, которую как раз предполагалось пережить без исходного хранителя.
История решения
Журнал переноса содержит старого и нового хранителя, корень, стадию проверки и время переключения. Старый договор прекращается только после достаточного основания. Если данные ещё доступны у прежнего места, это возможность сверки, а не причина поспешно удалить собственный архив.
При обнаружении расхождения корня выясняем, был ли использован другой импорт вместо переноса блоков. Повторная сборка с новой версией генератора может дать иной выпуск. Такой объект нельзя объявить идентичной копией без сравнения по договору.
Официальные основы содержатся в CARv1 и удалённом pinning. После урока библиотека имеет последовательный восстановительный сценарий. Пока он не выполнен, опись говорит о готовой процедуре и конкретных непроверенных этапах, а не о состоявшемся переезде.