Половина одноразовых бэкапов выглядит одинаково: взять папку, сжать, отправить с этого хоста. Никто не любит выписывать пайп руками. Имя с датой, уровень gzip, правильные флаги S3 — поверхности достаточно, чтобы притормозить.
Полный пайп одним промптом
$ clai сжми эту папку tar+gzip с датой и залей в 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.gzПара заметок. Архив стримится: tar -czf - пишет в stdout, aws s3 cp - читает stdin — промежуточный файл на диск не падает. Ключ S3 содержит и имя директории, и timestamp — обычно именно это и нужно для бэкап-нейминга.
Добавим «удалить при успехе»
Естественное продолжение: убрать источник, если заливка прошла.
$ clai сделай ту же заливку и удали локальную папку, если код возврата 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] — рекурсивное удаление рабочей директории.CliAI пометил второй вариант DANGER из-за хвостового rm -rf -- "$PWD". Классификатор смотрит на весь пайплайн, не только на первую стадию. Как принимается это решение — в посте про safety.
Когда правильный ответ — не S3
Меняйте назначение — «в gs://my-bucket», «на удалённый хост через rsync», «в Backblaze B2» — структура остаётся той же. Пайпу всё равно, какой URL; модель выбирает нужный загрузчик.
См. также
- Чистка старых логов и бэкапов — половина задачи про ротацию.
- SSH и rsync на удалёнку — когда назначение это другая машина, а не бакет.