La mitad de los backups ad-hoc tienen la misma forma: agarrar un directorio, comprimirlo, empujarlo fuera del host. A nadie le encanta escribir el pipe a mano. Nombres con fecha, niveles de gzip, los flags correctos de S3 — hay suficiente superficie como para frenar.
El pipeline en un solo prompt
$ clai tar esta carpeta, gzip con sufijo de fecha, sube a 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.gzAlgunas cosas que vale la pena notar. El archivo va por streaming — tar -czf - escribe en stdout, aws s3 cp - lee de stdin — así no se queda nada en disco local. La key de S3 incluye nombre del directorio y timestamp, que es lo que la mayoría quiere para sus backups.
Añade un guardia "borrar al éxito"
Continuación natural: limpiar el origen si la subida tuvo éxito.
$ clai haz la misma subida y borra la carpeta local si vuelve con código 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] — borrado recursivo del directorio actual.CliAI marcó la segunda variante DANGER por el rm -rf -- "$PWD" final. El clasificador mira todo el pipeline, no solo la primera etapa. El post de safety explica cómo se toma esa decisión.
Cuando la respuesta correcta no es S3
Cambia el destino — "a gs://my-bucket", "a un host remoto vía rsync", "a mi bucket de Backblaze B2" — y la estructura no cambia. Al pipe le da igual la URL; el modelo elige el cargador correcto.
Ver también
- Limpiar logs y backups viejos — la mitad de rotación del problema.
- Tareas remotas con SSH y rsync — cuando el destino es otra máquina, no un bucket.