Large migrations · Verification · Доказательство индикатора выполнения

Перемещение сотен ГБ между облаками: как узнать, что прибыл каждый файл?

При размере 500 ГБ надпись «загрузка выглядела завершенной» не является доказательством. Надежная миграция требует надежной инвентаризации, перехода состояний для каждого объекта, повторяемого восстановления после прерываний и подтверждения из самого места назначения.

Обновлено ; 16 мин чтения.

Краткий ответ

FileArk разбивает библиотеку на записи для каждого файла и сообщения устойчивой очереди. Рабочий копирует одну доставку, сохраняет возвращенный идентификатор пункта назначения, проверяет размер, считывает обратно этот точный объект и сравнивает SHA-256 с исходной полезной нагрузкой. Запись становится проверенной (и сообщение подтверждается) только после того, как эти проверки и обновление базы данных будут успешными.

Почему масштаб меняет значение слова «работал»

Десять файлов легко проверить. Десять тысяч файлов — нет. Большая личная библиотека может объединять крошечные документы, видео размером в несколько гигабайт, пустые файлы, вложенные папки, имена в Юникоде, архивные проекты и облачные форматы. Одна неудача может скрываться за впечатляющим процентом.

Итоговые данные полезны, но неполны. Две библиотеки могут иметь одинаковый видимый размер, в то время как в одной из них отсутствует объект или содержится усеченный объект, сбалансированный каким-либо несвязанным файлом. Количество файлов также может отличаться после экспорта собственного документа или исключенных объектов поставщика.

Полезной единицей истины является задание файла: какой исходный объект был прочитан, какой целевой объект был создан, какие байты сравнивались, когда завершилась проверка и осталась ли какая-либо попытка неразрешенной.

Полный жизненный цикл FileArk с аннотациями

Аннотированный жизненный цикл, показывающий работу базы данных сканера установки браузера FileArk, устойчивую работу очереди и проверку SHA-256.
Браузер запускает поток управления; сканер, постоянная очередь, база данных и исполнитель выполняют длительную миграцию.

Когда Start принят, API сначала записывает задание сканирования в MongoDB, а затем публикует постоянное сообщение сканирования в устойчивую очередь RabbitMQ с включенным подтверждением издателя. Если публикация не удалась, задание помечается как не выполненное, и API сообщает, что не удалось безопасно поставить сканирование в очередь.

Сканер аутентифицирует обоих поставщиков, инвентаризирует выбранный источник, сверяет конечную квоту назначения с обнаруженными байтами и обновляет запись базы данных для каждого исходного файла. Он публикует постоянные сообщения о миграции и помечает сканирование как завершенное только после успешной публикации.

Рабочий по миграции использует подтверждения вручную и счетчик предварительной выборки, равный единице. Доставка остается неподтвержденной, пока контент читается, загружается, перечитывается, проверяется и сохраняется. Таким образом, остановленное соединение или процесс может вернуть незавершенную работу в очередь.

Строка базы данных — это элемент контрольного списка, а не одноразовая бухгалтерия.

Каждая запись файла начинается с состояния «Ожидание», перемещается в состояние «Выполняется» во время попытки и достигает состояния «Загружено» только после проверки. Количество попыток, время последней попытки, сведения об ошибке, идентификатор объекта назначения, оба дайджеста SHA-256, метод проверки и VerifiedAt остаются прикрепленными к записи.

Завершенные записи остаются в базе данных в виде журнала прогресса и аудита. «Вычеркивание файла» означает контролируемое изменение состояния, а не удаление доказательств. Дубликаты доставки в очередь проверяют это состояние и немедленно подтверждают запись, уже помеченную как «Загружено» с «ПровереноAt».

После трех неудачных попыток постоянная проблема становится «Неудачной» с отметкой времени завершения цикла попыток. Это делает исключения видимыми и предотвращает постоянное появление подозрительного сообщения, пока панель мониторинга зависает.

Ворота завершения для одного файла
Pending
  → InProgress (attempt recorded)
  → destination ID stored
  → destination size matches
  → exact destination object re-downloaded
  → source SHA-256 == destination SHA-256
  → Uploaded + VerifiedAt persisted
  → queue message acknowledged

Почему файл может быть доставлен более одного раза

Надежные очереди обычно обеспечивают доставку «хотя бы один раз», а не волшебное обещание «точно один раз» через облачный API, брокер сообщений и базу данных. Сбой может произойти после того, как OneDrive или Google Drive примут загрузку, но до того, как исполнитель запишет завершение.

FileArk справляется с этой неопределенностью с помощью идемпотентных записей и восстановления места назначения. Работник сначала проверяет, проверена ли уже запись. В противном случае он может использовать сохраненный идентификатор места назначения или выполнить поиск по ожидаемому пути назначения и точному размеру прерванного результата, прежде чем принять решение о повторной загрузке.

Кандидаты на восстановление затем подвергаются той же проверке хеша точного объекта. Найти знакомое имя файла недостаточно. Цель состоит в том, чтобы превратить прерванную попытку обратно в доказательства, а не в оптимистический успех.

Емкость проверяется в пункте назначения и на рабочем месте

Прежде чем публиковать задания для каждого файла, сканер суммирует неотрицательные размеры исходных метаданных и сравнивает требования с сообщенным оставшимся объемом памяти места назначения всякий раз, когда поставщик предоставляет конечную квоту. Адресат меньшего размера не проходит проверку вместо того, чтобы отправлять работу в известный тупик.

Эта цифра является предварительной, а не гарантией: активность учетной записи может занимать пространство во время выполнения, отчеты о квотах провайдера могут запаздывать, а экспортированные облачные файлы могут не иметь обычного исходного размера. Принудительные меры поставщика и обработка ошибок для каждого файла остаются активными.

Диск вашего компьютера не используется для постановки. В рабочем процессе миграции файлы, объем памяти которых превышает пороговое значение, помещаются в изолированный временный каталог только после того, как на томе появится место для ожидаемого объекта плюс резерв в два гигабайта. Временное содержимое удаляется при очистке независимо от того, была ли попытка успешной или неудачной.

Почему важен идентификатор пункта назначения и SHA-256

Имя файла не является уникальным идентификатором. Место назначения может уже содержать два файла с одинаковым видимым именем, или для составления списка метаданных может потребоваться время. В ответе на загрузку предоставляется идентификатор объекта поставщика, и FileArk сохраняет этот идентификатор перед финальным этапом проверки.

Рабочий вычисляет SHA-256 в исходном потоке полезных данных, загружает его, затем открывает точный целевой объект по этому идентификатору и снова вычисляет SHA-256. Равный размер улавливает очевидное усечение; равный криптографический дайджест — это более строгая проверка на уровне байтов.

Охватывается только переданное файловое представление. Дайджест не может проверять правила общего доступа, комментарии, версии, метки, ярлыки, настройки хранения или то, как экспортированный документ Google отображается для пользователя. Это остаются задачи приемки.

Удаление источника намеренно выходит за рамки обычного пути успеха.

Самым безопасным значением по умолчанию является только копирование, а опция удаления FileArk отключена, если вы ее не включите. Если удаление отключено, ошибка проверки не может удалить оригинал, поскольку удаление никогда не запрашивается.

Если вы намеренно включили удаление после перемещения, рабочий процесс все равно будет ждать идентификатора назначения, размера и проверки SHA-256, прежде чем вызывать операцию удаления исходного поставщика. Более разумный вариант для незаменимых или очень больших библиотек — по-прежнему отключать эту опцию и использовать период перекрытия, одобренный человеком.

Миграция отвечает «пришла ли проверенная копия?» Хранение отвечает на вопрос: «Когда можно будет удалить старую копию?» Относитесь к ним как к отдельным решениям с отдельными доказательствами.

Одна и та же модель управления работает в обоих направлениях.

При переходе из OneDrive в Google Диск исходная полезная нагрузка считывается из Microsoft Graph, а целевой объект проверяется через Google Диск по возвращенному идентификатору. При использовании Google Диска в OneDrive исходный код загружается или экспортируется через Google Диск, а новый элемент OneDrive считывается обратно через Microsoft Graph.

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

Асимметрия – это семантика контента. Собственные документы Google нуждаются в экспорте, и обе платформы имеют функцию совместного использования и версии, специфичную для конкретной службы. Содержимое файла с байтовой проверкой не должно продаваться как полный клон всех функций совместной работы.

Используйте план приемки из четырех частей

  1. Согласовать системную запись

    Проверка завершена, ожидающая, выполняющаяся и неудачная. Ни от одного невыполненного задания нельзя отказываться, поскольку общий процент высок.

  2. Выборка по риску

    Открывайте файлы, потерять которые было бы больнее всего, а также большие носители, архивы, старые документы, неанглийские имена, вложенные пути и преобразованные облачные файлы.

  3. Проверка поведения места назначения

    Тестовый доступ с реальных устройств и пользователей. Восстановите необходимый общий доступ и убедитесь, что файлы Office или экспортированные файлы Google открываются должным образом.

  4. Удерживайте период перекрытия

    Сохраняйте источник доступным и стабильным, пока при обычном использовании используется пункт назначения. Решение об отмене или удалении примите позже.

Часто задаваемые вопросы

Использует ли FileArk очередь для каждого файла?

Да. Сканер создает или повторно использует запись базы данных для каждого исходного файла и публикует постоянное сообщение о миграции. Работники получают эти сообщения с подтверждением вручную.

Когда подтверждается сообщение очереди?

После проверки идентификатора, размера и SHA-256 целевого объекта и сохранения состояний Uploaded и VerifiedAt. Незавершенные поставки могут быть доставлены повторно.

Удалены ли завершенные записи файлов из базы данных?

Нет. Завершение — это переход состояния долговременной записи. В этой строке хранится идентификатор пункта назначения, доказательства проверки, время и информация о попытках для прогресса и аудита.

Может ли SHA-256 доказать перемещение разрешений и версий?

Нет. Это доказывает, что байты файла назначения соответствуют передаваемой полезной нагрузке источника. Совместное использование, разрешения, версии, комментарии, метки, ярлыки и собственное поведение поставщика требуют отдельной проверки.

Проверяется ли OneDrive на Google Диск так же, как и наоборот?

Основное правило одинаково в обоих направлениях: дайджест полезной нагрузки источника, идентификатор объекта назначения, размер назначения, дайджест повторной загрузки точного объекта, постоянная проверка, затем подтверждение очереди.

Официальные источники, использованные в этом руководстве

Читать руководство