Облако за годы легко превращается из удобного хранилища в платную археологию: старые папки, дубли, рабочие копии, медиаархивы и материалы, которые уже невозможно отличить от мусора без спокойной инвентаризации.
В этом кейсе Codex не получал пароль и не парсил веб-интерфейс. Доступ был выдан через официальное приложение Яндекса и OAuth, первая фаза была строго read-only, а все опасные действия шли через карантин, manifest и отдельное подтверждение.
Доступ
Официальный API
Отдельное приложение Яндекса, OAuth-токен и локальное хранение вне репозитория, без передачи пароля аккаунта.
Безопасность
Read-only сначала
Сначала только metadata: путь, тип, размер, md5, MIME-type, дата изменения и верхняя папка.
Результат
~180 ГБ
Столько освободил подтверждённый Level A delete-pass по exact-дублям после карантина и проверки.
Исходная задача
Обычная ручная чистка облака быстро превращается в усталость: открыл папку, увидел хаос, закрыл и купил ещё места. Здесь задача была другой: не гадать, а построить проверяемую карту Яндекс.Диска и понять, что можно вынести, что нельзя трогать и что требует ручного решения.
В облаке были старые проекты, видеоархивы, музыкальные релизы, промоматериалы, загрузки, рабочие копии и папки с историей. Удалять по ощущению было опасно.
Яндекс подталкивал к оплате дополнительного места, но главный вопрос был шире: какая структура хранения мне действительно нужна и что должно переехать в другую систему.
Доступ
Первый путь через уже существующий серверный контур помог быстро проверить, что задача решаема. Но для повторяемой услуги и спокойной безопасности нужен был прямой, объяснимый и отзывной доступ.
Токен — это отдельный ключ для конкретного приложения. Его можно отозвать, выдать заново и хранить отдельно от проекта.
Доступ лежит вне репозитория, не печатается в чат и не попадает в отчёты. Все рабочие артефакты проходят проверку на секреты.
Codex ходит в Yandex Disk REST API напрямую. Это лучше, чем парсить браузер или держать лишний сервер как мост доступа.
Метод
Самая частая ошибка в уборке данных — слишком рано начать действовать. Поэтому первая фаза намеренно исключала скачивание содержимого, перемещение, удаление, публикацию файлов и очистку корзины.
Карантин
Удалять сразу страшно и неправильно: можно потерять единственную полезную копию. Карантин меняет модель работы: файл больше не мешает активной структуре, но его ещё можно вернуть и проверить.
Подтверждённые дубли, старые рабочие копии и ручные кандидаты сначала уходили в отдельную зону, а не уничтожались.
Карантин не стал корзиной, которую можно удалить целиком. Внутри оставались разные типы объектов с разным уровнем уверенности.
Перед финальным удалением был собран отдельный список готовности: что является точным дублем, что спорно, а что нельзя трогать без человека.
Даже после удаления подтверждённых дублей оставался дополнительный rollback-слой через корзину Яндекс.Диска.
Что нашли
В многолетнем облаке редко бывает простой список лишнего. Там смешиваются архив, рабочие зоны, публикационные материалы, клиентские документы, личные файлы и случайные загрузки.
Если два файла совпадают по `md5 + size`, их содержимое одинаковое. Но удалять можно только после решения, какая копия остаётся канонической.
Похожие файлы в релизном архиве, рабочем проекте и медиа-папке — это уже не технический дубль, а вопрос политики хранения.
`Загрузки` и похожие зоны разгрузили, но оставили как стандартный входящий слой, а не как вечный склад.
Появились понятные крупные области: `_Music`, `_Projects`, `_Media`, `_Archive`, `Uplifto`, `Фабрика контента` и другие.
Часть зон осталась на ручной выбор: агент может показать риск, но не должен принимать смысловое решение за владельца.
Очистка стала подготовкой к архитектуре хранения: что держать в Яндекс.Диске, что переносить, что архивировать и что удалять.
Результат
На выходе появилась не просто более чистая папка, а повторяемый порядок работы с облаком: официальный доступ, read-only inventory, карта, exact-дубли, карантин, manual zones и отдельное подтверждение на необратимые шаги.
Это был не широкий снос всего подряд, а Level A duplicate delete-pass по объектам, которые прошли через quarantine pipeline и правила проверки.
Лишнее ушло из рабочих папок, а оставшиеся зоны получили более ясный смысл: входящие, архив, проекты, медиа и материалы для ручного выбора.
Такой процесс можно повторять для людей и команд с многолетними облачными архивами: безопасно, объяснимо и без доступа к содержимому там, где он не нужен.
После аудита можно спокойно выбирать архитектуру хранения: Яндекс.Диск, Google Drive, локальный NAS, холодный архив или удаление.
Кому это подходит
Это не только личная уборка. Та же проблема возникает у продюсеров, команд, предпринимателей и проектов, где облако годами собирало документы, видео, музыку, презентации, клиентские файлы и рабочие версии.
Когда в облаке уже невозможно быстро понять, что оригинал, что копия, что архив, а что временный мусор.
Когда видео, релизы, промоматериалы и документы живут рядом, а ошибка удаления может стоить дороже лишнего тарифа.
Когда миграцию нельзя начинать с переноса хаоса: сначала нужна карта, правила и список того, что вообще стоит переносить.
Источник
В статье подробно описано, как Codex подключался к Яндекс.Диску через официальный доступ, почему первая фаза была read-only и как карантин превратил очистку в управляемый процесс.
Кейсы
Кейс
DevOps-аудит семи VPS: сначала безопасная инвентаризация и документы, потом риски, решения и точечные изменения там, где они действительно нужны.
Открыть →Кейс
Автономный контур синка транскриптов из Plaud в Notion с дедупликацией, миграцией структуры данных и рабочим UX.
Открыть →Кейс
Идея внешней проверки стала рабочим Codex-скиллом, публичным GitHub-репозиторием и сразу прошла проверку на настоящем архитектурном риске.
Открыть →