Rsync vs SCP: qué comando de copia usar en Linux

Usa rsync para cualquier cosa más grande que una copia rápida de una sola vez, y scp cuando solo quieras un archivo en otra máquina ya. La diferencia de fondo: scp vuelve a transmitir el archivo completo cada vez y no recuerda una conexión caída, mientras que rsync compara origen y destino, transfiere solo los bloques que cambiaron y reanuda una copia interrumpida donde se quedó. En un backup grande por un enlace inestable, esa es la diferencia entre dos minutos y empezar de cero. Ambos vienen con OpenSSH en prácticamente cualquier distribución de Linux, así que es una elección de hábito, no de instalación — y el hábito debe ser rsync por defecto. Abajo: tabla comparativa sin rodeos, diferencias reales de velocidad, el truco de reanudación que scp no puede hacer y los casos donde scp sigue siendo la respuesta correcta.

¿Qué diferencia hay entre rsync y scp?

scp hace una cosa: abrir un canal SSH, transmitir los bytes, cerrar. No tiene estado entre ejecuciones, así que si la transferencia muere al 90 %, empiezas desde cero.

rsync es una herramienta de sincronización que usa SSH como transporte. Antes de enviar, construye una lista de checksums del archivo de destino (el algoritmo delta de checksums rodantes) y transmite solo los bloques que difieren. Corre el mismo comando dos veces y la segunda pasada casi no mueve nada. Eso también hace de rsync la herramienta natural para mantener dos directorios en sync — prográmalo y cada pasada copia solo los deltas.

Las consecuencias prácticas:

• Interrupciones: rsync reanuda; scp reinicia el archivo.
• Segundas copias: rsync envía solo los cambios; scp reenvía todo.
• Borrados: rsync puede reflejar borrados con --delete; scp no puede.
• Filtrado: rsync tiene patrones --exclude; scp copia todo lo que le apuntes.
• Dry runs: rsync muestra lo que haría con --dry-run; scp no ofrece nada.

¿Es rsync más rápido que scp?

Para una primera copia de un archivo grande por un enlace rápido, están cerca — ambos saturan SSH, y la pasada de checksums añade solo un overhead pequeño. La brecha se abre en tres lugares:

1. Archivos pequeños a granel. rsync hace pipelining de los recorridos de directorio y puede reutilizar una conexión; los scp viejos lanzaban trabajo por archivo. Miles de archivos chicos (un node_modules, un WordPress) terminan notablemente más rápido con rsync.
2. Re-ejecuciones. Copia un archivo de 4 GB en el que cambiaron 50 MB y rsync mueve aproximadamente 50 MB; scp vuelve a mover 4 GB.
3. Compresión. -z comprime en vuelo, lo que ayuda en enlaces WAN lentos.

Puedes cronometrar ambos tú mismo — el comando tiene la misma forma:

# mismo archivo, mismo servidor, ambos por SSH
time scp bigfile.tar.gz user@server:/tmp/
time rsync -avh --progress bigfile.tar.gz user@server:/tmp/

# re-ejecuta ambos: scp vuelve a copiar, rsync verifica y envía ~nada
time scp bigfile.tar.gz user@server:/tmp/
time rsync -avh --progress bigfile.tar.gz user@server:/tmp/

Si vives en servidores, la velocidad de transferencia es de esas cosas que vale medir una vez — igual que ss le gana a netstat en hosts ocupados (ver ss vs netstat: qué comando de puertos usar en Linux).

¿Puede scp reanudar una transferencia interrumpida?

No. scp no tiene reanudación; si la conexión cae en 900 MB de 1 GB, empiezas otra vez. Esta es la razón más citada en cada debate rsync-vs-scp, y es real.

Todo el diseño de rsync asume que la transferencia se interrumpirá a veces. La invocación canónica de reanudación:

rsync -avh --partial --append-verify --progress bigfile.tar.gz user@server:/srv/backup/

• --partial conserva el archivo a medio escribir en vez de borrarlo.
• --append-verify reanuda añadiendo al final y luego verifica por checksum la región añadida — a salvo de un archivo parcial corrupto, a diferencia del viejo --append a secas.
• --progress te muestra dónde retomó.

Envuelto en un bucle de reintentos, esto es un backup de configurar y olvidar incluso sobre una conexión hostil:

until rsync -avh --partial --append-verify --progress \
    ./bigfile.tar.gz user@server:/srv/backup/; do
  sleep 5
done

¿Cuándo conviene usar scp en vez de rsync?

scp sigue siendo la herramienta correcta en un puñado de casos:

• Un archivo pequeño, una vez. Escribir scp app.conf user@host:/etc/myapp/ es más corto que cualquier invocación de rsync, y no hay nada que reanudar.
• rsync no existe del otro lado. rsync necesita su binario en ambos extremos. Muchos contenedores mínimos y appliances traen el servidor SFTP de scp pero no rsync.
• No quieres un servidor rsync expuesto. Raro, pero algunos entornos bloquean específicamente el daemon de rsync.

Un detalle que vale conocer: el proyecto OpenSSH dejó de recomendar el protocolo original de scp hace años, y el scp moderno en realidad habla SFTP por debajo. Eso arregló una rareza de escape de rutas, pero no cambió nada de las dos limitaciones que importan aquí — sin reanudación, sin transferencia delta. El cambio de protocolo no convierte a scp en rsync.

También relacionado: si tu pregunta en el fondo es «rsync vs cp», la respuesta espeja esta — cp es el equivalente solo local de scp (sin reanudación, sin delta, sin atributos salvo que agregues flags), y rsync sirve tanto local como remoto. Para one-shots locales, cp está bien.

¿Qué flags de rsync importan más?

La mayoría de la gente solo necesita una línea:

rsync -avh --partial --progress src/ user@server:/srv/dest/

Flag	Qué hace
-a (archive)	Recursivo + conserva permisos, tiempos, grupo, symlinks, dispositivos
-v (verbose)	Lista lo que transfiere
-h (human)	Tamaños legibles para humanos
--partial	Conserva los archivos transferidos a medias, para que una re-ejecución reanude
--progress	Progreso por archivo — eso que scp nunca tuvo
-z	Comprime en vuelo (CPU lenta en LAN rápida: sáltatelo)
--delete	Refleja también los borrados — peligroso, acompáñalo siempre de un dry run
--dry-run (-n)	Muestra qué pasaría, no cambia nada

Dos hábitos que valen adoptar. Primero, dry run a todo lo que lleve --delete:

rsync -avh --delete --dry-run src/ user@server:/srv/dest/   # revisar
rsync -avh --delete src/ user@server:/srv/dest/             # luego ejecutar

Segundo, ojo con la barra final — /srv/src copia el directorio entero dentro del destino, mientras que /srv/src/ copia su contenido. A todos se les traba una vez; rsync hasta avisa «no bytes transferred» cuando querías la otra forma.

Para un sync diario o semanal, mete rsync en un timer de systemd y deja que copie solo los deltas — el lado journalctl de la programación está cubierto en la chuleta de journalctl.

Rsync vs scp: el veredicto

	scp	rsync
Viene con OpenSSH	Sí	Sí (se necesita en ambos extremos)
Reanudar transferencia interrumpida	No	Sí (--partial)
Transferencia delta en re-ejecuciones	No	Sí
Conservar permisos/symlinks	Parcial	Total (-a)
Patrones de exclusión	No	--exclude
Dry run	No	--dry-run
Reflejar borrados	No	--delete
Ideal para	Copias rápidas de una sola vez	Backups, syncs, árboles grandes

rsync por defecto para backups, árboles grandes, cualquier cosa sobre un enlace que puede caerse y cualquier cosa que vas a correr más de una vez. scp cuando el comando es más corto que el pensamiento. Si te llevas un solo flag, que sea --partial — convierte cada conexión caída futura de un reinicio en una pausa.