Mondes et sauvegardesUne restauration qui prend vingt minutes n'est pas lente — elle accomplit trois tâches réellement séquentielles, chacune limitée par un type d'E/S différent, et aucune ne peut être sautée ni vraiment accélérée depuis le côté client.
Pourquoi ce n'est pas instantané
Les sauvegardes premium vivent sur un réseau de stockage distant séparé, pas sur le même NVMe où tourne le serveur en direct — cette séparation est ce qui les fait survivre à un problème du nœud lui-même. En restaurer une signifie tirer toute l'archive compressée à travers le réseau jusqu'au nœud, la décompresser, puis réécrire chaque fichier extrait sur le NVMe local. Ce sont trois opérations bout à bout, chacune avec son propre goulot : vitesse de transfert réseau, décompression limitée par le CPU, et débit d'écriture du disque local — et un serveur au-delà de 10 Go a réellement cette quantité de données à faire traverser les trois étapes.
Où va le temps en réalité
| Étape | Limitée par |
|---|---|
| Récupérer l'archive depuis le stockage distant | Transfert réseau vers le nœud |
| La décompresser | CPU |
| Écrire les fichiers extraits sur le NVMe | Débit d'écriture disque local |
Annuler ou redémarrer le conteneur en plein milieu laisse des fichiers à moitié extraits — non pas corrompus au sens d'octets endommagés, mais réellement absents, car le processus a été arrêté avant qu'ils ne soient jamais complètement écrits. Contrairement à un fichier .mca avec une écriture interrompue, aucune récupération partielle n'est disponible ; le bon réflexe est toujours de laisser une restauration se terminer, aussi long que paraisse l'estimation.