Mundos y copiasUna restauración que tarda veinte minutos no va lenta: está haciendo tres trabajos genuinamente secuenciales, cada uno limitado por un tipo distinto de E/S, y ninguno se puede saltar ni acelerar de verdad desde el lado del cliente.
Por qué no es instantánea
Las copias premium viven en un array de almacenamiento remoto aparte, no en el mismo NVMe del que corre el servidor en marcha; esa separación es lo que las hace sobrevivir a un problema con el propio nodo. Restaurar una significa traer el archivo comprimido entero por la red hasta el nodo, descomprimirlo, y escribir cada archivo extraído de vuelta al NVMe local. Son tres operaciones seguidas, cada una con su propio cuello de botella: velocidad de transferencia de red, descompresión limitada por CPU, y rendimiento de escritura del disco local; y un servidor de más de 10 GB tiene de verdad esa cantidad de datos que mover por las tres fases.
A dónde se va el tiempo de verdad
| Fase | Limitada por |
|---|---|
| Traer el archivo del almacenamiento remoto | Transferencia de red hasta el nodo |
| Descomprimirlo | CPU |
| Escribir los archivos extraídos al NVMe | Rendimiento de escritura del disco local |
Cancelar o reiniciar el contenedor a medio camino deja archivos extraídos a medias, no corruptos en el sentido de bytes dañados, sino genuinamente ausentes, porque el proceso se paró antes de llegar a escribirlos del todo. A diferencia de un .mca con una escritura cortada, no hay ninguna recuperación parcial disponible; lo seguro es siempre dejar que una restauración termine, por larga que parezca la estimación.