Large migrations · Verification · Доказ за індикатором виконання

Переміщення сотень ГБ між хмарами: як дізнатися, що кожен файл надійшов?

При 500 ГБ «завантаження виглядало завершеним» не є доказом. Надійна міграція потребує надійної інвентаризації, зміни стану для кожного об’єкта, повторюваного відновлення після перерв і підтвердження від самого місця призначення.

Оновлено ; 16 хв читання.

Коротка відповідь

FileArk розбиває бібліотеку на файлові записи та стійкі повідомлення в черзі. Працівник копіює одну доставку, зберігає повернутий ідентифікатор призначення, перевіряє розмір, зчитує цей об’єкт назад і порівнює SHA-256 із джерелом корисного навантаження. Запис стає перевіреним, а повідомлення підтверджується лише після успішного завершення перевірок і оновлення бази даних.

Чому масштаб змінює значення слова «працював»

Десять файлів легко перевірити. Десять тисяч файлів не є. Велика особиста бібліотека може об’єднувати крихітні документи, багатогігабайтні відео, порожні файли, вкладені папки, назви Unicode, архівні проекти та формати, вбудовані в хмару. Одна невдача може ховатися всередині вражаючого на вигляд відсотка.

Підсумки корисні, але неповні. Дві бібліотеки можуть відображати однаковий видимий розмір, тоді як в одній відсутній об’єкт або містить усічений об’єкт, збалансований якимось непов’язаним файлом. Кількість файлів також може відрізнятися після експорту рідного документа або виключених об’єктів постачальника.

Корисною одиницею істинності є завдання файлу: який об’єкт-джерело було прочитано, який об’єкт-приймач створено, які байти порівнювалися, коли завершено перевірку та чи залишилися спроби невирішеними.

Повний життєвий цикл FileArk з анотаціями

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

Коли Start приймається, API спочатку записує завдання сканування в MongoDB, а потім публікує повідомлення про постійне сканування в довготривалій черзі RabbitMQ з увімкненим підтвердженням видавця. Якщо опублікувати не вдається, завдання позначається як «Не виконано», а API повідомляє, що не вдалося безпечно поставити сканування в чергу.

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

Працівник міграції використовує підтвердження вручну та кількість попередньої вибірки, яка дорівнює одиниці. Доставка залишається непідтвердженою, поки вміст читається, завантажується, перечитується, перевіряється та зберігається. Таким чином, зупинене з’єднання або процес може повернути незавершену роботу до черги.

Рядок бази даних – це пункт контрольного списку, а не одноразова бухгалтерія

Кожен запис файлу починає очікувати, переходить до InProgress під час спроби та досягає завантаженого лише після перевірки. Кількість спроб, час останньої спроби, деталі помилки, ідентифікатор цільового об’єкта, обидва дайджести SHA-256, метод перевірки та VerifiedAt залишаються долученими до запису.

Завершені записи залишаються в базі даних як хід виконання та контрольний слід. «Викреслення файлу» означає контрольовану зміну стану, а не видалення доказів. Подвійні доставки в черзі перевіряють цей стан і негайно підтверджують запис, уже позначений як Uploaded з VerifiedAt.

Після трьох невдалих спроб постійна проблема стає невдалою з міткою часу завершення для циклу спроб. Це робить винятки видимими та запобігає постійному обертанню отруйного повідомлення, поки інформаційна панель здається завислою.

Шлюз завершення для одного файлу
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 Диск так само, як і навпаки?

Основне правило однакове в обох напрямках: дайджест джерела корисного навантаження, ідентичність об’єкта призначення, розмір призначення, дайджест повторного завантаження точного об’єкта, постійна перевірка, потім підтвердження в черзі.

Офіційні ресурси, використані для цього посібника

Читати посібник