Metade dos backups ad-hoc tem a mesma cara: pegar um diretório, compactar, jogar pra fora do host. Ninguém adora escrever a pipe na mão. Nome com data, nível do gzip, flags certas do S3 — superfície suficiente para parar e pensar.
A pipe inteira num prompt
$ clai tar desta pasta, gzip com sufixo de data, sobe pra s3://team-backups/db/→ tar -czf - . \ | aws s3 cp - "s3://team-backups/db/$(basename "$PWD")-$(date +%Y%m%d-%H%M).tar.gz"upload: <stdin> to s3://team-backups/db/data-20260427-1432.tar.gzAlgumas coisas valem nota. O arquivo é streamado — tar -czf - escreve em stdout, aws s3 cp - lê do stdin — sem arquivo intermediário no disco. A key do S3 traz nome do diretório e timestamp, padrão que a maioria dos times quer pra backup.
Adiciona um guard "apagar se sucesso"
Continuação natural: limpar a origem se o upload deu certo.
$ clai mesmo upload, apaga a pasta local se o código de retorno for 0→ tar -czf - . \ | aws s3 cp - "s3://team-backups/db/$(basename "$PWD")-$(date +%Y%m%d-%H%M).tar.gz" \ && rm -rf -- "$PWD"[Safety: DANGER] — remoção recursiva do diretório atual.O CliAI marcou a segunda variante como DANGER por causa do rm -rf -- "$PWD" no final. O classificador olha o pipeline todo, não só o primeiro estágio. Como a decisão é tomada, no post sobre safety.
Quando a resposta certa não é S3
Troque o destino — "pra gs://my-bucket", "pra um host remoto via rsync", "pro meu bucket Backblaze B2" — e a estrutura permanece. A pipe não se importa com a URL; o modelo escolhe o uploader certo.
Veja também
- Limpeza de logs e backups antigos — a metade da rotação.
- Tarefas remotas com SSH e rsync — quando o destino é outra máquina, não um bucket.