В начале октября под удары беспилотников попали три площадки Яндекса — в Сасово, Калуге и Владимире, из-за чего часть инфраструктуры облачных сервисов работала с перебоями. 11 октября компания отключила в веб-версии Диска скачивание папок, альбомов и наборов файлов одним действием, оставив пользователям только поштучную загрузку. Автор публикации на профильном ресурсе, хранивший на Диске около 1,8 ТБ данных и ещё порядка 160 ГБ фотографий в безлимитном тарифе, решил не ждать восстановления и собрать резервную копию самостоятельно. План выглядел прямолинейно: утилита rclone, арендованный сервер в Нидерландах и аккаунт Google Drive на 2 ТБ в качестве приёмника. Однако почти каждый шаг упирался в особенности реализации API и политики доступа Яндекса, а итоговые цифры оказались далеки от ожиданий. По словам автора, первые пять минут копирования не дали ни одного скопированного байта, а выборочная проверка 300 случайных файлов показала, что отдаётся лишь около половины. Все скрипты и инструкции он выложил в открытый репозиторий на GitHub.

Первая проблема возникла на этапе авторизации: стандартный вход через браузер проходил успешно, команда просмотра квоты возвращала корректные данные, но любая попытка прочитать содержимое папки завершалась ошибкой 410 Gone. Прямые запросы к REST API с тем же токеном отдавали сведения о Диске, но не список файлов и не ссылки на скачивание, то есть приложение пускали к метаданным, но не к данным. Обход нашёлся через отладочную страницу Полигона самого Яндекса, где можно получить OAuth-токен с полным доступом примерно на год. Дополнительно пришлось подставить фиктивный refresh_token и срок действия в 2099 году, иначе rclone версии 1.75 отказывался стартовать с токеном без механизма обновления.

Отдельная история связана с фотографиями из безлимитного хранилища: они не лежат в обычной папке «Фотокамера» и видны только в разделе «Фото». API сообщает их суммарный объём — около 162,7 ГБ, но обратиться к ним напрямую нельзя: запрос к пути photounlim возвращает ошибку DiskAreaDoesNotExistsError, WebDAV отвечает 404, а в плоском списке файлов этих объектов нет вовсе. Единственный выход — перенести снимки в обычную папку, после чего они начинают занимать место в тарифе. Проверка на одном видео подтвердила механику: занятое пространство выросло почти на 11 МБ, а счётчик безлимита уменьшился на ту же величину. Поскольку веб-интерфейс позволяет выделить не более 500 фотографий за раз, а всего их около 30 тысяч, автор разобрал запросы браузера к внутреннему эндпоинту models-v2 и написал скрипт, вызывающий нужные методы через fetch из открытой вкладки с сохранением cookies и TLS-отпечатка. Практика показала, что пачка из 50 файлов отклоняется с ошибкой валидации «Too many items», а 40 проходит; перемещения выполняются последовательно со скоростью примерно 85–120 файлов в минуту. Все 30 738 фотографий переехали примерно за шесть часов, 49 файлов не перенеслись из-за ошибки 500 на стороне сервиса.

Со скачиванием основной массы данных картина оказалась ещё сложнее. Цепочка выдачи файла включает запрос ссылки через API, редирект на downloader.disk.yandex.ru и перенаправление на конкретный узел хранения; почти весь архив автора размещён на узлах с суффиксом klg, вероятно калужских. Из 262 проверенных файлов на этих узлах отдались только 117, причём соединение устанавливалось и зависало до тайм-аута. Заранее отсеять мёртвые файлы по имени узла не удалось: из 225 узлов в выборке 31 оказался смешанным, где часть объектов доступна, а часть нет. Компания о потере данных не сообщала, поэтому автор исходит из того, что файлы временно недоступны, и докачивает их повторными прогонами.

Сравнение транспортов оказалось в пользу REST: под нагрузкой WebDAV отвечает 503 и рвёт соединения, выдавая около 0,2 МБ/с на поток против примерно 0,8 МБ/с у REST, который вдобавок возвращает MD5 каждого файла для проверки целостности. По умолчанию rclone ждёт ответа пять минут и делает десять повторов, из-за чего один мёртвый файл способен застопорить весь поток, а к середине дня выдача ссылок растягивалась от одной до 60 секунд с периодическими ошибками 500 даже при остановленной заливке. Рабочая конфигурация включила 64 параллельных передачи, восемь проверяющих потоков, лимит 20 транзакций в секунду, тайм-ауты 60 и 15 секунд, сокращённые повторы и режим только copy без sync, который удаляет в копии отсутствующие в источнике файлы. На сервере в Docker это занимает около 310 МБ памяти и до 40% одного ядра, а на крупных файлах скорость доходила до 33 МБ/с; ночной cron перезапускает копирование и подбирает то, что сервис успел вернуть.

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

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