Docs · Conceptos
Velocidad de las copias
Lo que cuesta una copia de 5 GB en tiempo, datos enviados y recursos del servidor, medido el 2026-11-09 con el agente real en un cliente de 2 vCPU frente al software de almacenamiento real. Las cifras de abajo son medidas, no promesas: tu servidor, tus discos y sobre todo tu enlace de red marcan las tuyas.
Versión MarkdownEl CLI habla inglés por defecto (`--lang es` para español). Algunos bloques de salida vienen de una sesión en francés: están señalados y traducidos en el texto.
Qué se midió
Medido en el servidor Ikoula compartido, cliente de 2 vCPU, el 2026-11-09, agente 0.3.0, restic 0.18.1. Un contenedor cliente desechable (Alpine Linux, PostgreSQL 17) limitado a 2 vCPU y 2 GB de RAM recibió un neverwiped install real y luego una muestra sintética de 5,3 GB en 50 037 archivos más una base de datos:
- 2,1 GB de registros de aplicación en 32 archivos (texto, comprimible);
- 2,0 GB de datos aleatorios en 5 archivos (incomprimibles, como fotos, vídeos o archivos comprimidos);
- 1,0 GB en 50 000 archivos JSON pequeños de 20 KB (el coste por archivo de una copia);
- una base PostgreSQL de 577 MB, exportada con
pg_dumpallen cada copia como cualquier base detectada.
El almacenamiento (la misma pasarela y los mismos servidores REST de restic que en producción) corría en la misma máquina, por la interfaz local: el enlace de red no forma parte de estas cifras. Lo que se mide es el trabajo en tu servidor (leer, deduplicar, comprimir, cifrar, exportar la base) y lo que queda por enviar una vez hecho ese trabajo. La sección de más abajo convierte los bytes enviados en minutos para enlaces habituales.
Resultados
| Fase | Duración | Datos leídos | Enviado al almacenamiento | Repositorio después | CPU / RAM del cliente (pico) |
|---|---|---|---|---|---|
| Primera copia | 18 s | 5,81 GB, 50 132 archivos | 3,09 GB | 3,09 GB | 201 % (los dos núcleos) / 380 MiB |
| Segunda copia, sin cambios | 3 s | 5,81 GB, 50 132 archivos | 0,4 MB | 3,09 GB | demasiado corta para medirla |
| Tercera copia, 200 MB cambiados | 6 s | 5,87 GB, 50 134 archivos | 210 MB | 3,30 GB | 128 % / 368 MiB |
| Restauración completa en una carpeta nueva | 10 s | 5,87 GB escritos | — | — | 161 % / 542 MiB |
Los 200 MB cambiados fueron 150 MB sobrescritos dentro de uno de los archivos aleatorios más un archivo de texto nuevo de 50 MB; la base no se tocó y aun así se volvió a exportar, por eso se leyeron 5,87 GB. Tras la restauración, el SHA-256 de cada archivo y una reimportación de la base coincidieron con los originales.
En el lado del almacenamiento, la pasarela se mantuvo por debajo del 13 % de un núcleo y 10 MiB de RAM durante la primera copia; el servidor REST de restic detrás de ella, por debajo del 22 % y 104 MiB. La generación de la muestra (54 s en el host) no se cuenta.
Qué dicen estas cifras:
- La primera copia depende de tus datos y de tu enlace. 5,81 GB leídos y 3,09 GB enviados: los registros, los archivos pequeños y la exportación de la base se comprimieron bien; los 2 GB aleatorios, no. Con los dos núcleos a tope, el servidor procesó unos 320 MB/s; un disco más lento o
neverwiped limits --limit-cpus 1baja esa cifra. - Una noche sin cambios cuesta segundos. El agente vuelve a leer la lista de archivos y a exportar la base, y luego no envía casi nada (0,4 MB de metadatos).
- Una noche con cambios cuesta los cambios. 200 MB cambiados, 210 MB enviados, en 6 s de procesamiento.
- La restauración es rápida en el servidor: 5,87 GB escritos en 10 s. En un enlace real, la descarga de los 3,3 GB guardados marca el ritmo.
Qué esperar en tu enlace
El tiempo de procesamiento de arriba es el suelo; la subida suele ser el techo. Aritmética a partir de los bytes enviados (sin margen, enlace estable supuesto):
| Enlace (subida) | Primera copia, 3,09 GB enviados | Tercera copia, 210 MB enviados | Restauración, 3,3 GB descargados |
|---|---|---|---|
| 1 Gbit/s (125 MB/s) | unos 25 s | 2 s | unos 27 s |
| 100 Mbit/s (12,5 MB/s) | unos 4 min 10 s | 17 s | unos 4 min 25 s |
| 20 Mbit/s (2,5 MB/s) | unos 21 min | 1 min 25 s | unos 22 min |
Una primera copia de 50 GB de datos mixtos enviaría a grandes rasgos de 25 a 30 GB: unos 35 minutos a 100 Mbit/s, unas 3 horas a 20 Mbit/s. La instalación muestra una estimación para tu propio plan antes de enviar nada, y neverwiped limits --limit-upload mantiene el enlace utilizable mientras tanto (la primera copia tarda entonces más; una ejecución programada se detiene a las 12 horas, así que quita el límite para una primera copia muy grande).
En una frase
En nuestro servidor de pruebas de 2 vCPU, una primera copia de una muestra de 5 GB necesitó 18 segundos de procesamiento y envió 3,1 GB tras compresión y deduplicación, unos cuatro minutos en un enlace de 100 Mbit/s; la noche siguiente, sin cambios, 3 segundos; con 200 MB cambiados, 6 segundos y 210 MB enviados.
Reproducirlo
La medición es un script del repositorio del agente (scripts/speed-report.sh): arranca la pila de almacenamiento y un sustituto de la plataforma en una máquina, instala el agente en un contenedor cliente de 2 vCPU con la muestra de arriba, cronometra las tres copias y la restauración, verifica cada suma de comprobación, imprime la tabla y lo elimina todo. La fecha de arriba dice cuándo se ejecutó por última vez.