rsync vs scp — qué comando de copia Linux, y cuándo

■ espacio · carril de prosa

LA ÚNICA LÍNEA, ANOTADA

La mayoría solo necesita esto — cada flag etiquetado, en orden:

la barra final engaña a todos una vez — rsync incluso avisa "no bytes transferred" cuando querías la otra forma

LO QUE COMPRA LA DIFERENCIA DE ESTADO

scp hace una cosa: abrir un canal SSH, fluir los bytes, cerrar. Sin estado entre corridas, así que un transfer que muere al 90% reinicia de cero y reenvía todo. rsync es una herramienta de sincronización que usa SSH como transporte: antes de enviar construye una lista de checksums del destino (el algoritmo rolling-checksum

• 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 cannot.
• Filtrado : rsync tiene patrones --exclude ; scp copia todo lo que apuntes.
• Simulaciones: rsync shows what it would do with --dry-run ; scp no ofrece nada.

¿ES RSYNC MÁS RÁPIDO?

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

1. Archivos pequeños a granel. rsync encadena los recorridos de directorio y puede reutilizar una conexión; los scp antiguos lanzaban un proceso por archivo. Miles de archivos pequeños — un node_modules, una instalación de WordPress — terminan notablemente más rápido con rsync.
2. Re-corridas. Copia un archivo de 4,0 GB donde cambiaron 50 MB y rsync mueve unos 50 MB; scp mueve 4 GB otra vez.
3. Compression. -z comprime en vuelo, lo que ayuda en enlaces WAN lentos.

Puedes cronometrarlos tú — el comando es idéntico en forma, y la re-corrida es donde vive la respuesta:

# 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-corrida de 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/

LA ENCANTACIÓN DE REANUDACIÓN

No, scp no puede reanudar un transfer interrumpido — ni flag, ni truco. Todo el diseño de rsync asume que el transfer se interrumpirá a veces:

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, y luego verifica por checksum la región añadida — seguro contra un parcial corrupto, a diferencia del viejo --append.
• --progress te muestra dónde retomó.

Envuelto en un bucle de reintentos, es una copia de seguridad 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

verifica: corre el mismo rsync otra vez → verifica y envía ~nada

CUÁNDO SCP TODAVÍA GANA

• 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 está en el otro extremo. rsync necesita su binario en ambos lados. Muchos contenedores mínimos y appliances traen el servidor SFTP de scp pero no rsync.
• No quieres un demonio rsync expuesto. Raro, pero algunos entornos bloquean específicamente el demonio rsync.

One subtlety worth knowing: the OpenSSH project deprecated scp's original protocol years ago, and modern scp actually speaks SFTP debajo. Eso arregló una rareza de escape de rutas, pero no cambió nada en las dos limitaciones que importan — sin reanudación, sin transferencia delta. El cambio de protocolo no convierte scp en rsync. Y si tu pregunta es en realidad "rsync vs cp": cp es el equivalente solo-local de scp — sin reanudación, sin delta, sin atributos a menos que añadas flags — y para one-shots locales va bien.

EL PELIGROSO

--delete refleja también los borrados — elimina en el destino los archivos que ya no están en el origen. Potente para espejos, peligroso en el resto. Simula primero:

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

verifica: la pasada --dry-run imprime la lista de borrados y no cambia nada

Para una sincronización diaria o semanal, mete rsync en un timer systemd y deja que copie solo los deltas — el journal es donde las corridas dejan su historia.

LA TABLA DEL VEREDICTO

Por defecto, rsync para backups, árboles grandes, todo lo que pase por un enlace que puede caerse, y todo lo que correrás más de una vez. Usa scp cuando el comando es un one-shot y nada puede interrumpirse — y añade siempre --partial — convierte cada conexión futura caída de reinicio en pausa.

fin de la página de copia · nada descargado · todo local