Large migrations · Verification · La preuve derrière la barre de progression

Déplacer des centaines de Go entre les cloud : comment savoir si chaque fichier est arrivé ?

À 500 Go, « le téléchargement semblait terminé » n’est pas une preuve. Une migration fiable nécessite un inventaire durable, une transition d'état pour chaque objet, une récupération reproductible après des interruptions et une preuve de la destination elle-même.

Mis à jour ; 16 min de lecture.

En bref

FileArk divise la bibliothèque en enregistrements par fichier et en messages de file d'attente durables. Un travailleur copie une livraison, stocke l'ID de destination renvoyé, valide la taille, relit cet objet exact et compare SHA-256 avec la charge utile source. L'enregistrement n'est vérifié (et le message est reconnu) qu'une fois ces vérifications et la mise à jour de la base de données réussies.

Pourquoi l’échelle change le sens de « travaillé »

Dix dossiers sont faciles à inspecter. Dix mille fichiers ne le sont pas. Une grande bibliothèque personnelle peut combiner des documents minuscules, des vidéos de plusieurs gigaoctets, des fichiers vides, des dossiers imbriqués, des noms Unicode, des projets archivés et des formats natifs du cloud. Un échec peut se cacher derrière un pourcentage impressionnant.

Les totaux sont utiles mais incomplets. Deux bibliothèques peuvent afficher la même taille apparente alors qu'il manque un objet dans l'une ou contient un objet tronqué équilibré par un fichier sans rapport. Le nombre de fichiers peut également différer après l’exportation d’un document natif ou après l’exclusion d’objets fournisseur.

L'unité de vérité utile est le travail de fichier : quel objet source a été lu, quel objet de destination a été créé, quels octets ont été comparés, quand la vérification est terminée et si une tentative reste non résolue.

Le cycle de vie complet de FileArk, annoté

Cycle de vie annoté montrant le gestionnaire de file d'attente durable de la base de données du scanner de configuration du navigateur FileArk et la vérification SHA-256
Le navigateur démarre le flux de contrôle ; l'analyseur, la file d'attente persistante, la base de données et le travailleur effectuent la migration de longue durée.

Lorsque Start est accepté, l'API écrit d'abord une tâche d'analyse dans MongoDB, puis publie un message d'analyse persistant dans une file d'attente RabbitMQ durable avec la confirmation de l'éditeur activée. Si la publication échoue, la tâche est marquée Échec et l'API signale qu'elle n'a pas pu mettre l'analyse en file d'attente en toute sécurité.

L'analyseur authentifie les deux fournisseurs, inventorie la source sélectionnée, vérifie le quota de destination fini par rapport aux octets découverts et insère un enregistrement de base de données pour chaque fichier source. Il publie des messages de migration persistants et marque l'analyse comme terminée uniquement une fois ces publications réussies.

L'agent de migration utilise des accusés de réception manuels et un nombre de prélecture de un. Une livraison reste sans accusé de réception pendant que le contenu est lu, téléchargé, relu, vérifié et conservé. Une connexion ou un processus arrêté peut donc renvoyer un travail inachevé dans la file d'attente.

Une ligne de base de données est un élément de liste de contrôle, et non une comptabilité jetable

Chaque enregistrement de fichier commence en attente, passe à InProgress lors d'une tentative et atteint Téléchargé uniquement après vérification. Le nombre de tentatives, l'heure de la dernière tentative, les détails de l'erreur, l'ID de l'objet de destination, les résumés SHA-256, la méthode de vérification et VerifiedAt restent attachés à l'enregistrement.

Les enregistrements terminés restent dans la base de données en tant que progression et piste d'audit. « Rayer un dossier » signifie un changement d’état contrôlé, et non la suppression des preuves. Les livraisons en file d'attente en double inspectent cet état et reconnaissent immédiatement un enregistrement déjà marqué Téléchargé avec VerifiedAt.

Après trois tentatives infructueuses, un problème persistant devient Échec avec un horodatage d'achèvement pour le cycle de tentative. Cela rend les exceptions visibles et empêche un message incohérent de tourner indéfiniment alors que le tableau de bord semble bloqué.

La porte d'achèvement pour un dossier
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

Pourquoi un fichier peut être livré plus d'une fois

Les files d'attente fiables fournissent généralement une livraison au moins une fois, et non une promesse magique exactement une fois via une API cloud, un courtier de messages et une base de données. Un crash peut se produire après que OneDrive ou Google Drive ait accepté un téléchargement, mais avant que le travailleur n'écrive la fin.

FileArk gère cette incertitude avec des enregistrements idempotents et une récupération de destination. Le travailleur vérifie d'abord si l'enregistrement est déjà vérifié. Sinon, il peut utiliser l'ID de destination stocké ou rechercher le chemin de destination attendu et la taille exacte du résultat interrompu avant de décider de télécharger à nouveau.

Les candidats à la récupération sont ensuite soumis à la même vérification exacte du hachage de l'objet. Trouver un nom de fichier familier ne suffit pas. Le but est de reconvertir une tentative interrompue en preuve, et non en succès optimiste.

La capacité est vérifiée à destination et sur le travailleur

Avant la publication des tâches par fichier, l'analyseur totalise les tailles de métadonnées sources non négatives et compare les besoins avec le stockage restant signalé par la destination chaque fois que le fournisseur fournit un quota fini. Une destination sous-dimensionnée échoue à l’analyse au lieu d’alimenter le travail dans une impasse connue.

Ce chiffre est un contrôle en amont et non une garantie : l'activité du compte peut consommer de l'espace pendant une exécution, les rapports sur les quotas des fournisseurs peuvent être en retard et les fichiers cloud natifs exportés peuvent ne pas avoir une taille source conventionnelle. L’application du fournisseur et la gestion des erreurs par fichier restent actives.

Le disque de votre ordinateur n'est pas utilisé pour la préparation. Sur le programme de migration, les fichiers au-dessus du seuil de mémoire sont placés dans un répertoire temporaire isolé uniquement une fois que le volume a de la place pour l'objet attendu plus une réserve de deux Go. Le contenu temporaire est supprimé lors du nettoyage, que la tentative réussisse ou soit rejetée.

Pourquoi l'ID de destination plus SHA-256 est important

Un nom de fichier n'est pas une identité unique. La destination peut déjà contenir deux fichiers portant le même nom visible, ou la liste des métadonnées peut prendre du temps à s'établir. La réponse de téléchargement fournit un ID d'objet fournisseur et FileArk stocke cet ID avant l'étape de vérification finale.

Le travailleur calcule SHA-256 sur le flux de charge utile source, le télécharge, puis ouvre l'objet de destination exact par cet ID et calcule à nouveau SHA-256. Une taille égale détecte une troncature évidente ; le résumé cryptographique égal est la vérification la plus puissante au niveau des octets.

Seule la représentation du fichier transféré est couverte. Un résumé ne peut pas valider les règles de partage, les commentaires, les versions, les étiquettes, les raccourcis, les paramètres de conservation ou la manière dont un document Google exporté s'affiche pour un utilisateur. Cela reste des tâches d’acceptation.

La suppression de la source est intentionnellement en dehors du chemin de réussite normal

La valeur par défaut la plus sûre est la copie uniquement et l'option de suppression de FileArk est désactivée, sauf si vous l'activez. Lorsque la suppression est désactivée, un échec de vérification ne peut pas supprimer l'original car la suppression n'est jamais demandée.

Si vous activez délibérément la suppression après déplacement, le travailleur attend toujours l’ID de destination, la taille et la validation SHA-256 avant d’appeler l’opération de suppression du fournisseur source. Le choix opérationnel le plus judicieux pour les bibliothèques irremplaçables ou de très grande taille consiste toujours à désactiver cette option et à utiliser une période de chevauchement approuvée par l'homme.

La migration répond : « Une copie vérifiée est-elle arrivée ? » La rétention répond « quand l’ancienne copie peut-elle être supprimée ? » Traitez-les comme des décisions distinctes avec des preuves distinctes.

Le même modèle de contrôle fonctionne dans les deux sens

Pour OneDrive vers Google Drive, la charge utile source est lue à partir de Microsoft Graph et l'objet de destination est vérifié via Google Drive par son ID renvoyé. Pour Google Drive vers OneDrive, la source est téléchargée ou exportée via Google Drive et le nouvel élément OneDrive est relu via Microsoft Graph.

La file d'attente, les états de la base de données, les tentatives limitées, le contrôle en amont de la capacité, le résumé de la source, l'ID de destination, le résumé de destination et l'ordre d'accusé de réception sont neutres en termes de direction. Les adaptateurs de fournisseur gèrent les différentes API de téléchargement, de dossier et de contenu.

L'asymétrie est la sémantique du contenu. Les documents natifs de Google doivent être exportés, et les deux plates-formes ont un comportement de partage et de version spécifique au service. Le contenu des fichiers vérifiés en octets ne doit pas être commercialisé comme un clone complet de chaque fonctionnalité de collaboration.

Utilisez un plan d'acceptation en quatre parties

  1. Rapprocher l'enregistrement système

    Examinez les décomptes terminés, en attente, en cours et ayant échoué. Aucun élément ayant échoué ne doit être écarté car le pourcentage global est élevé.

  2. Échantillon par risque

    Ouvrez les fichiers dont la perte serait la plus préjudiciable, ainsi que les supports volumineux, les archives, les anciens documents, les noms non anglais, les chemins imbriqués et les fichiers cloud natifs convertis.

  3. Valider le comportement de la destination

    Testez l’accès à partir d’appareils et d’utilisateurs réels. Reconstruisez le partage requis et confirmez que les fichiers Office ou Google exportés s'ouvrent comme prévu.

  4. Conserver une période de chevauchement

    Gardez la source disponible et stable pendant que l'utilisation normale exerce la destination. Prenez toute décision d’annulation ou de suppression plus tard.

Questions fréquentes

FileArk utilise-t-il une file d’attente pour chaque fichier ?

Oui. L'analyseur crée ou réutilise un enregistrement de base de données par fichier source et publie un message de migration persistant. Les travailleurs extraient ces messages avec un accusé de réception manuel.

Quand un message de file d’attente est-il reconnu ?

Une fois que l'ID, la taille et le SHA-256 de l'objet de destination ont été vérifiés et que les états Uploaded et VerifiedAt ont été conservés. Les livraisons inachevées peuvent être relivrées.

Les enregistrements de fichiers complétés sont-ils supprimés de la base de données ?

Non. L’achèvement est une transition d’état sur le dossier durable. La ligne conserve l'identité de la destination, les preuves de vérification, le calendrier et les informations sur les tentatives pour la progression et l'audit.

SHA-256 peut-il prouver que les autorisations et les versions ont été déplacées ?

Non. Cela prouve que les octets du fichier de destination correspondent à la charge utile source transférée. Le partage, les autorisations, les versions, les commentaires, les étiquettes, les raccourcis et le comportement natif du fournisseur nécessitent une validation distincte.

OneDrive vers Google Drive est-il vérifié de la même manière que l'inverse ?

La règle de base est la même dans les deux sens : résumé de la charge utile source, identité de l'objet de destination, taille de la destination, résumé du nouveau téléchargement exact de l'objet, vérification persistante, puis accusé de réception de la file d'attente.

Ressources officielles utilisées pour ce guide

Lire le guide