Мой бэкап исправно сохранял мусор. Ошибку я заметил по счёту за облако

Я посмотрел на расходы облачного хранилища и полез разбираться, что туда вообще уезжает с моего компьютера. Бэкап был настроен для рабочих файлов: проектов, истории изменений, заметок. Он должен был спасать работу, если с диском что-то случится. А заодно начал добросовестно сохранять временные папки, которые оставляла автоматическая разработка.

Самое неприятное: бэкап не ломался. Он выполнял именно то, что я ему разрешил. Поэтому искать причину среди ошибок запуска было бы бесполезно. Пришлось смотреть состав копии и журнал передачи файлов.

На компьютере у меня работают ИИ-помощники. Для правок они создают отдельные рабочие каталоги: можно менять код, проверять его и не мешать соседней задаче. В Git такая рабочая копия называется worktree. Для меня в этой истории важнее другое: на диске появляется ещё одна папка с файлами проекта.

Когда правка закончена и попала в основную версию, временную папку можно убрать. История изменений от этого не исчезнет. Но если уборка не входит в завершение задачи, папка остаётся. Задача закрыта, отчёт получен, а её рабочее место продолжает занимать диск.

У меня именно так и получилось. Временные каталоги накапливались внутри общей рабочей папки. А ночное копирование смотрело на эту папку целиком. Для него черновая копия проекта ничем не отличалась от нужного документа: есть файл, попадает под правила — надо сохранить.

Почему я сначала смотрел не туда

Когда настраиваешь облачный бэкап, легко думать только об объёме. Сколько места занимают проекты, сколько будет стоить хранение, поместится ли архив. У меня внимание тоже было на этом. Но в журнале проявился другой расход: передача множества отдельных файлов.

Каждая временная рабочая копия приносила своё дерево каталогов. Конвейер разработки создавал и менял эти деревья, а конвейер бэкапа следом переносил их в облако. Там ещё сохранялись версии изменённых и удалённых файлов. Полезная страховка от случайного удаления работала и для того, что я вообще не собирался хранить.

Я не заложил в процесс простой момент: кто и когда убирает рабочую папку после завершения задачи. Отдельно разработка выглядела разумно. Отдельно резервное копирование тоже. Вместе они производили лишнюю работу, за которую приходил настоящий счёт.

Именно это меня зацепило сильнее самих расходов. Я не подключал новый сервис и не увеличивал объём полезных данных намеренно. Дополнительная нагрузка появилась из побочного результата уже работающей автоматизации. Ей не понадобилось отдельное разрешение, потому что нужные разрешения я выдал раньше.

Что оказалось в исправлении

Мы исключили временные рабочие каталоги конвейера из резервного копирования. Правило получилось узким: оно относится к определённым папкам, а не выкидывает из бэкапа всю разработку. Основной репозиторий и его история нужны для восстановления, их я сохраняю.

Накопившиеся чистые рабочие копии убрали штатной командой Git. Важная оговорка: чистые. Если в каталоге осталась незавершённая работа, удаление ради аккуратного диска само станет новым происшествием. Сначала нужно понять, что сохранено в истории, а что существует только в этой папке.

С облаком пришлось разобраться отдельно. Новое исключение влияет на последующие запуски, но старые временные файлы уже успели туда попасть. Их тоже убрали, сохранив основной бэкап. Одной правкой настроек история бы не закончилась.

По дороге выяснилась ещё одна неудобная деталь. Фильтр надо проверять от той же корневой папки, от которой запускается реальное копирование. Если для удобства начать проверку глубже, относительный путь изменится и исключение может не совпасть. Можно потратить время на исправное правило только потому, что проверяешь его в других условиях.

Теперь в завершении работы конвейера есть уборка временной копии после переноса готовых изменений. А исключение в бэкапе остаётся дополнительной защитой. Если рабочая папка задержится на компьютере, ночное копирование не должно автоматически делать из неё долгосрочный архив.

Что я теперь хочу видеть в отчёте

Раньше мне было достаточно знать, что резервная копия сделана. После этой истории хочется понимать, что именно в неё добавилось. Большой поток новых файлов может означать полезную работу, а может означать забытые рабочие каталоги. По сообщению об успешном запуске этого не различить.

Я собираю сервисы на нейросетях и постепенно замечаю, сколько хозяйства остаётся вокруг готового результата. Временные папки, промежуточные картинки, сохранённые версии. У каждого такого файла была причина появиться. Причина хранить его дальше есть далеко не всегда.

Свой бэкап я по-прежнему считаю необходимым. Но теперь к задаче «сохрани мою работу» добавился вопрос: где заканчивается работа, которую надо беречь, и начинается оставленный после неё мусор? В этот раз ответ пришлось искать уже после ночной загрузки в облако.