A restore that takes twenty minutes is not slow — it is doing three genuinely sequential jobs, each bound by a different kind of I/O, and none of them can be skipped or meaningfully sped up from the client end.
Why it is not instant
Premium backups live on a separate remote storage array, not on the same NVMe the live server runs from — that separation is what makes them survive a problem with the node itself. Restoring one means pulling the entire compressed archive across the network to the node, decompressing it, and writing every extracted file back onto local NVMe. Those are three back-to-back operations, each with its own bottleneck: network transfer speed, CPU-bound decompression, and disk write throughput — and a server north of 10 GB genuinely has that much data to move through all three stages.
Where the time actually goes
| Stage | Bound by |
|---|---|
| Pulling the archive from remote storage | Network transfer to the node |
| Decompressing it | CPU |
| Writing extracted files to NVMe | Local disk write throughput |
Cancelling or restarting the container partway through leaves files half-extracted — not corrupted in the sense of damaged bytes, but genuinely missing, since the process was stopped before they were ever fully written. Unlike a .mca file with a torn write, there is no partial recovery available; the safe move is always to let a restore finish, however long the estimate looks.