■ espacio · carril de prosa
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
- 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:
- 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. - 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.
- Compression.
-zcomprime 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/
--partialconserva el archivo a medio escribir en vez de borrarlo.--append-verifyreanuda añadiendo, y luego verifica por checksum la región añadida — seguro contra un parcial corrupto, a diferencia del viejo--append.--progresste 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
| scp | rsync | |
|---|---|---|
| Viene con OpenSSH | Yes | Sí (se necesitan ambos lados) |
| Reanudar un transfer interrumpido | No | Sí (--partial) |
| Transferencia delta en re-corridas | No | Yes |
| Conserva permisos/symlinks | Parcialmente | Totalmente (-a) |
| Patrones de exclusión | No | --exclude |
| Simulación | No | --dry-run |
| Refleja borrados | No | --delete |
| Ideal para | Copias rápidas de una vez | Backups, 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.
fin de la página de copia · nada descargado · todo local