Quem cuida de três ou mais servidores já digitou um rsync, parou e se perguntou: era -a ou -r? preciso de --delete? a barra no final vai onde? A barra no final sozinha causou mais quedas do que as pessoas gostam de admitir.
1. Sync excluindo o típico
$ clai rsync desta pasta pra staging:/srv/app/ excluindo node_modules e .git→ rsync -avz --delete --exclude='node_modules' --exclude='.git' \ ./ staging:/srv/app/A barra em ./ importa. O CliAI acerta. Note que --delete está incluso porque "sync" implica que o destino espelhe a origem — mas é o tipo de flag que vale confirmar antes do Enter.
2. SSH com port forward local
$ clai ssh em prod-db, encaminhe a porta local 5432 pro postgres dele→ ssh -L 5432:localhost:5432 prod-dbA sintaxe de forward (-L local:host_remoto:porta_remota) é dessas que só viram automáticas depois de um ano de uso semanal.
3. SCP de um diretório
$ clai scp do diretório reports inteiro de staging:/srv/reports pra ./reports→ scp -r staging:/srv/reports ./reports-r é obrigatório para diretórios; sem ele o scp silenciosamente não faz nada útil. O CliAI sabe; você não precisa.
4. Preservar permissões e timestamps
$ clai copia /etc/nginx do prod pra cá, preservando permissões e timestamps→ rsync -avz --rsync-path='sudo rsync' prod:/etc/nginx/ ./nginx-backup/--rsync-path='sudo rsync' é o padrão certo quando a origem precisa de root para leitura, mas o ssh entra como usuário comum. Difícil de lembrar, fácil de pedir.
Lembrete de autenticação
O CliAI gera o comando; não configura suas chaves SSH nem hosts. Se ssh staging não funciona no seu terminal, o comando gerado também não vai. Invista uma vez no seu ~/.ssh/config e ssh-agent e esses one-liners pagam pra sempre.
Veja também
- Compactar e subir pra S3 — quando "remoto" é object storage, não outra máquina.
- Triagem de rede — quando o comando remoto falha por rede, não por sintaxe.