Die Hälfte aller Ad-hoc-Backups hat dieselbe Form: ein Verzeichnis nehmen, komprimieren, vom Host wegschicken. Niemand schreibt die Pipe gern von Hand. Datums-Namen, gzip-Stufen, die richtigen S3-Flags — genug Oberfläche, um zu zögern.
Die volle Pipe in einem Prompt
$ clai tar diesen Ordner, gzip mit Datums-Suffix, upload nach 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.gzEin paar Details. Das Archiv wird gestreamt — tar -czf - schreibt nach stdout, aws s3 cp - liest von stdin — kein lokales Zwischenfile. Der S3-Key enthält Verzeichnisname und Timestamp, was die meisten Teams beim Backup-Naming sowieso wollen.
Wache „bei Erfolg löschen" anfügen
Natürliche Folge: die Quelle löschen, wenn der Upload geklappt hat.
$ clai gleichen Upload, lösche lokalen Ordner wenn Exit-Code 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] — rekursive Löschung des Arbeitsverzeichnisses.CliAI hat die zweite Variante mit DANGER markiert wegen des nachfolgenden rm -rf -- "$PWD". Der Klassifikator schaut auf die gesamte Pipeline, nicht nur den ersten Abschnitt. Wie diese Entscheidung fällt, beschreibt der Safety-Beitrag.
Wenn die richtige Antwort nicht S3 ist
Tausch das Ziel — „nach gs://my-bucket", „auf einen Remote-Host via rsync", „in meinen Backblaze-B2-Bucket" — und die Struktur bleibt gleich. Der Pipe ist die URL egal; das Modell wählt den passenden Uploader.
Siehe auch
- Alte Logs und Backups aufräumen — die Rotations-Hälfte.
- SSH und rsync für Remote-Aufgaben — wenn das Ziel eine andere Maschine ist, kein Bucket.