Le problème de l’utilisateur source n’était pas simplement que « deux boîtiers ZimaOS ne peuvent pas copier de données ». Il déplaçait environ 600 Go entre des systèmes exécutant ZimaOS 1.5.x, et le transfert de fichiers s’arrêtait régulièrement avec le message « l’hôte est hors service », alors que les deux serveurs restaient accessibles.
Ce comportement historique doit être distingué de celui de ZimaOS actuel. IceWhale recommande désormais explicitement d’utiliser le stockage LAN dans Fichiers pour déplacer des données depuis un autre NAS, tandis que l’application Sauvegarde actuelle peut cibler un autre appareil Zima et propose des tâches reprenables et tolérantes aux erreurs. Pour un transfert très volumineux, choisissez la méthode selon que vous souhaitez une copie visible effectuée une seule fois, une tâche de protection reprenable ou le transfert physique le plus rapide.
Le transfert de fichiers source redémarrait régulièrement alors que les deux hôtes restaient en ligne
L’utilisateur a essayé les deux sens : envoyer les données depuis l’ancien boîtier ZimaOS et les récupérer depuis le nouveau. Dans les deux cas, le processus Fichiers dans le navigateur finissait par s’arrêter, même si le tableau de bord de la source restait accessible.
La communauté a recommandé rsync comme option en ligne de commande la plus facilement reprenable
Une réponse de la communauté proposait d’utiliser rsync via SSH avec la prise en charge des transferts partiels, afin de pouvoir relancer une copie interrompue sans recommencer depuis le début. Il s’agit d’un conseil avancé utile, mais il n’a pas été publié par le personnel d’IceWhale et l’utilisateur source n’a pas confirmé l’avoir utilisé.
Les recommandations actuelles d’IceWhale utilisent toujours Fichiers pour une migration de NAS à NAS
La documentation actuelle de ZimaOS recommande d’ajouter l’ancien NAS comme stockage LAN dans Fichiers, puis de copier les dossiers vers le stockage du nouveau ZimaOS. Le délai d’expiration observé avec la version 1.5.x ne doit donc pas être généralisé en affirmant qu’il ne faut « jamais utiliser Fichiers pour une migration volumineuse ».
Utilisez le processus de migration actuel via le stockage LAN pour effectuer une copie visible classique.
La fonction Sauvegarde actuelle peut cibler un autre appareil Zima
Pour les transferts de longue durée, lorsque la possibilité de reprendre compte davantage que la navigation manuelle dans la destination, l’application Sauvegarde actuelle prend en charge un autre appareil Zima comme destination. IceWhale documente la planification, la progression en temps réel, la reprise et la tolérance aux erreurs.
Consultez le processus actuel de sauvegarde Zima à Zima reprenable.
SMB est une alternative simple à la logique de copie du navigateur
La communauté source a également recommandé de monter le partage SMB source sur la destination, puis d’effectuer la copie depuis la destination. L’utilisateur avait auparavant réussi à transférer des données depuis un ancien NAS vers ZimaOS à l’aide de partages SMB montés.
Un transfert par USB ou NVMe peut être le plus rapide lorsque les boîtiers sont physiquement proches
Pour plusieurs centaines de gigaoctets ou plusieurs téraoctets, un SSD ou NVMe externe rapide peut éliminer toutes les variables liées au réseau. Le compromis est qu’il faut effectuer deux copies : de la source vers le support intermédiaire, puis du support intermédiaire vers la destination.
De nombreux petits fichiers peuvent donner l’impression que la migration est beaucoup plus lente
Les données AppData, les miniatures, les fichiers annexes de photos, les arborescences de code et autres jeux de données riches en métadonnées peuvent être transférés bien plus lentement que de gros fichiers multimédias, car chaque fichier nécessite des opérations d’ouverture, de création et de gestion des métadonnées.
Vérifiez les données avant de supprimer la source
Après toute migration, comparez des dossiers représentatifs, le nombre de fichiers lorsque cela est possible, et ouvrez les fichiers critiques sur la destination. Conservez la source intacte jusqu’à ce que le nouveau boîtier ait été utilisé avec succès et qu’une sauvegarde existe.
Fichiers et Sauvegarde répondent à des besoins de migration différents
Fichiers est le choix le plus clair lorsque vous souhaitez parcourir la source, sélectionner certains dossiers et voir immédiatement les fichiers copiés sur la destination. Sauvegarde est préférable lorsque le transfert doit durer plusieurs heures ou plusieurs jours et que vous privilégiez la reprise, la tolérance aux erreurs, la planification et un historique de tâches récupérable.
Ne présentez pas une tâche de sauvegarde comme un « déplacement » transparent. Elle crée une copie protégée avec ses propres mécanismes de restauration ; vérifiez l’organisation de la destination avant de supprimer la source.
Vérifiez le chemin réseau avant d’optimiser l’outil de copie
Sur une liaison théorique de 1 GbE, vérifiez que les deux machines ont effectivement négocié une connexion Ethernet Gigabit, qu’aucun segment Wi-Fi ou 100 Mb/s n’est utilisé et que le commutateur et le câblage sont en bon état. Un outil de copie ne peut pas dépasser les limites d’une liaison physique lente.
Testez ensuite un seul fichier volumineux. Si un gros fichier est transféré rapidement, mais qu’une arborescence est lente, le nombre de fichiers et la surcharge liée aux métadonnées sont probablement plus importants que la bande passante réseau brute.
Les fichiers utilisateur et les données AppData actives nécessitent un traitement différent
Les films, les photos et les documents peuvent généralement être copiés comme des fichiers ordinaires. Les bases de données d’applications actives et les données AppData peuvent nécessiter l’arrêt de l’application, une exportation ou une migration tenant compte de l’application afin de garantir la cohérence interne de la copie.
Ne supposez pas que la copie du répertoire d’une base de données en cours d’exécution d’un boîtier à l’autre constitue une migration valide de l’application.
Conservez ou recréez délibérément les autorisations des partages
Même si chaque octet est transféré, le boîtier ZimaOS de destination possède ses propres utilisateurs, définitions de partages et mappages de conteneurs. Recréez les autorisations Samba et les chemins de volumes d’applications nécessaires, puis testez l’accès avec l’utilisateur non administrateur concerné.
Utilisez une bascule en deux phases pour les données importantes
Pour une migration volumineuse d’un NAS actif, copiez d’abord les données principales tout en laissant l’ancien boîtier en service. À l’approche de la bascule, arrêtez ou mettez en pause les applications qui écrivent des données, exécutez une dernière passe incrémentielle et reprenable, vérifiez la destination, puis redirigez les clients vers le nouveau boîtier. Cela réduit l’interruption de service et évite de supprimer trop tôt l’unique copie intacte.
FAQ sur la migration d’un boîtier ZimaOS vers un autre
La source a-t-elle prouvé que Fichiers n’est jamais fiable pour les grosses copies ?
Non. Elle a documenté un cas d’échec avec la version 1.5.x. Les recommandations actuelles d’IceWhale utilisent toujours Fichiers et le stockage LAN pour la migration d’un NAS.
Quelle option actuelle prend en charge les transferts Zima à Zima reprenables ?
L’application Sauvegarde actuelle peut cibler un autre appareil Zima et inclut des fonctions de reprise et de tolérance aux erreurs.
rsync était-il la méthode finale confirmée par l’utilisateur source ?
Non. rsync était une recommandation de la communauté ; l’utilisateur a ensuite indiqué que la migration était terminée sans documenter la méthode de transfert finalement utilisée.
