■ espacio · carril de prosa

■ the answer first

rsync para copias de seguridad, árboles grandes, cualquier cosa que vayas a correr más de una vez — scp para un archivo pequeño, una vez.

scp no puede reanudar : una caída a los 900 MB de 1 GB — faltan 100 MB — reinicia desde cero. rsync con --partial --append-verify convierte ese reinicio en una pausa.

On re-runs rsync moves solo los bloques cambiados; scp re-sends everything. The one flag to take away: --partial.

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

¿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/

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

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

scprsync
Viene con OpenSSHYesSí (se necesitan ambos lados)
Reanudar un transfer interrumpidoNoSí (--partial)
Transferencia delta en re-corridasNoYes
Conserva permisos/symlinksParcialmenteTotalmente (-a)
Patrones de exclusiónNo--exclude
SimulaciónNo--dry-run
Refleja borradosNo--delete
Ideal paraCopias rápidas de una vezBackups, sincronías, árboles grandes

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.

■ sello honesto Probado en: rsync · scp (habla SFTP por debajo) · tus claves y config SSH existentes. Publicado por primera vez 2026-09-08, ficha refrescada 2026-10-04. Cada comando corre tal cual está impreso; el comportamiento de reanudación, el algoritmo delta y el cambio a SFTP son comportamiento documentado de rsync y OpenSSH, tecleado desde transfers que de verdad se cayeron.

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