263 ГБ из Google Takeout: zip без карты, скрипты и шесть итераций с Gemini
Автор поста на dev.to описывает выгрузку через Google Takeout объёмом порядка 263 ГБ: набор разбитых архивов, боль с именами и метаданными, неработающие подсказки по удалению данных и два дня работы с кастомными скриптами.
В центре сюжета — не только формат экспорта, но и опыт «парного программирования» с Gemini: от мёртвых ссылок до автоматизации в браузере, где модель несколько раз уводила решение в тупик, пока не сработала шестая попытка после передачи «сырого» HTML DOM.
Архивы без манифеста: цена полного перезапуска
По описанию в материале, Takeout приходит набором zip с шаблоном имён вроде takeout-20260406T202814Z-…-….zip; в тексте приводятся примеры частей, в том числе на 50 ГБ и 32 ГБ.
У дочернего аккаунта автора — семь архивов суммой 167 ГБ, без манифеста, индекса и merge tool. В каждом архиве корень Takeout/ с подпапками сервисов, но какой сервис в каком файле — выясняется только открытием.
Инкрементального экспорта нет: при пропуске или повреждении части, по словам автора, остаётся запускать многочасовой экспорт заново.
Это не абстрактная «боль UX», а инженерная задача. Без карты архивов разработчик вынужден писать свои проверки и обходчики — и дальше, при попытке автоматизировать удаление на стороне Google, подключать генеративную модель как генератор черновиков кода под враждебный интерфейс.
Имена путей, Windows и sidecar JSON вместо привычного EXIF
На стыке Linux и Windows всплывают пробелы в конце имён папок (корректно на Linux, на Windows извлечение падает с FileNotFoundError).
Автор пишет, что после проверки 118 096 извлечённых файлов проблемы с именами у 62 (около 0,05 %): 6 случаев связаны с альбомом Google Photos (вероятная связь с распознаванием лиц), 56 — файлы Google Voice с ведущими пробелами при пустом caller ID.
У каждого изображения есть sidecar .json с датами, GPS, описанием и данными камеры. По утверждению автора, эти поля не встроены в EXIF, который ждут обычные фото-приложения; для нормальной работы нужен кастомный код, чтобы слить JSON с EXIF.
Когда «официальный» контур отдаёт данные в неудобном виде, цепочка «скрипт + модель-помощник» выглядит не роскошью, а способом сократить ручную рутину — если держать в голове лимиты модели и необходимость самому валидировать результат.
Gemini, мёртвые ссылки и сага шести попыток в браузере
Автор обращался к Gemini за помощью с массовым удалением и получил две ссылки на страницы Google (…/delete-services-gateway, …/delete-services); в его опыте обе вели на 404 (в оригинале приведены полные пути).
Раздел поста назван «The Gemini Saga: 6 Scripts to Delete Your Own Data» — перечислены Attempt 1–6 с автоматизацией в браузере для удаления фото в Google Photos.
- Попытка 1: селекторы
role="checkbox"— путаница кнопки «Move to trash» с подтверждением в модалке, двойной клик, зависание. - Попытка 2: таргетирование диалога добавлено, reference check не проходит между слоями DOM.
- Попытка 3: кратко работало, затем сценарий не справляется с ленивой подгрузкой сетки; автору приходилось вручную скроллить, чтобы появились новые элементы.
- Попытка 4: выбор 75 элементов сразу приводит к падению фронтенда (
CUIERROR26); в тексте упоминаетсяscale(Infinity)в CSS-анимациях. Автор отмечает, что Gemini «потеряла нить» и начала выдавать C# Playwright вместо JS для консоли браузера. - Попытка 5: «архитектурно здравый» вариант с неверными селекторами; в логе — завершение примерно за 18 секунд, при этом 67,3 ГБ фото остаются.
- Попытка 6: в чат вставлен «сырой» HTML DOM; Gemini формулирует проблему Wiz и тяжёлых accessibility-атрибутов, мешающих стандартным кликам; после этого получен рабочий скрипт. Автор подчёркивает необходимость периодически перезапускать сценарий из-за утечки памяти и thousands of detached DOM nodes.
Формулировка в кратком анонсе поста про «6 failed Gemini attempts» в полном тексте соответствует шести итерациям: первые пять описаны как неудачные или недостаточные, шестая — как давшая работающий сценарий после передачи DOM.
Отдельно в посте пересказывается ответ Gemini про обновления бэкенда delete-services и связку Photos с пулом Google One / исчезновение иконки Trash в меню — как содержание диалога с моделью, а не как независимо проверенный факт о продукте.
Открытый код, цифры из интерфейса и осторожность с оценочными тезисами
После цикла с Gemini и браузерными скриптами автор выкладывает инструменты в репозиторий github.com/LostBeard/free-your-data и называет файлы ExtractTakeout.cs, VerifyExtraction.cs, remove-all-automated.js (имена — как в посте; отдельной проверки кода репозитория в материале нет).
В блоке про расширения Chrome приводятся числа пользователей с витрины, указанные автором: 9 000 и 10 000, суммарно 19 000 «across just two extensions» — как утверждение в его тексте.
При даунгрейде Google One цитируется предупреждение интерфейса про потерю функций при использовании >200 ГБ при контрасте с 14,6 ГБ занятого места у автора — цифры из поста. Упоминается также, что слоган «Don't be evil» снят в 2018 — по формулировке автора.
Отдельного разбора лицензий или ToS в материале нет.
Оценочные и интерпретативные тезисы (в том числе про dark pattern при даунгрейде Google One, намеренное удержание, сравнение с «textbook dark pattern design») нельзя подавать как юридически проверенные факты: это позиция автора, на которую стоит смотреть критически и сверять с первоисточником.
Источники
- LostBeard. I Got My Data Out of Google - Here's What They Did to It on the Way Out — https://dev.to/lostbeard/i-got-my-data-out-of-google-heres-what-they-did-to-it-on-the-way-out-296i (дата доступа: 2026-04-08, UTC).