Cualquiera con tres o más servidores ha escrito un rsync, ha pausado, y se ha preguntado: ¿era -a o -r? ¿necesito --delete? ¿dónde va la barra final? La barra final ha causado más caídas de las que la gente quiere admitir.
1. Sync excluyendo lo típico
$ clai rsync esta carpeta a staging:/srv/app/ excluyendo node_modules y .git→ rsync -avz --delete --exclude='node_modules' --exclude='.git' \ ./ staging:/srv/app/La barra final en ./ importa. CliAI la pone bien. Fíjate que --delete está incluido porque "sync" implica que el destino debe espejar el origen — pero es de los flags que conviene confirmar antes de pulsar Enter.
2. SSH con port forward local
$ clai ssh a prod-db reenviando el puerto local 5432 a su postgres→ ssh -L 5432:localhost:5432 prod-dbLa sintaxis (-L local:host_remoto:puerto_remoto) es de las cosas que no se interiorizan hasta usarlas semanalmente durante un año.
3. SCP de un directorio
$ clai scp todo el directorio reports desde staging:/srv/reports a ./reports→ scp -r staging:/srv/reports ./reports-r es obligatorio para directorios; sin él scp silenciosamente no hace nada útil. CliAI lo sabe; tú no tienes que.
4. Preservar permisos y timestamps
$ clai copia /etc/nginx desde prod aquí preservando permisos y timestamps→ rsync -avz --rsync-path='sudo rsync' prod:/etc/nginx/ ./nginx-backup/--rsync-path='sudo rsync' es el patrón correcto cuando el origen requiere root para leer pero tu ssh va como usuario normal. Difícil de recordar, fácil de pedir.
Sobre autenticación
CliAI genera el comando; no configura tus claves SSH ni hosts. Si ssh staging no funciona en tu terminal, el comando generado tampoco. Invierte una vez en tu ~/.ssh/config y ssh-agent y estos one-liners te pagan para siempre.
Ver también
- Comprimir y subir a S3 — cuando "remoto" es almacenamiento de objetos en lugar de otra máquina.
- Triage de red — cuando el comando remoto falla por la red, no por la sintaxis.