Как мы перегоняем терабайт с Яндекс.Диска на Synology под присмотром Codex

Иногда домашняя инфраструктура выглядит очень спокойно. Где-то в углу стоит Synology, рядом роутер, на экране открыта вкладка с журналами, а в фоне как будто ничего не происходит.

А потом смотришь внимательнее: Synology прямо сейчас тащит из Яндекс.Диска больше терабайта данных, Codex проверяет маршрут, отдельный наблюдатель следит, чтобы трафик к Яндексу шёл ожидаемым путём, а я сижу и спрашиваю: «Стёпа, сколько процентов переписано?»

И Стёпа Codex отвечает не философски, а по делу: около 18% по объёму, ошибок 0, защита маршрута жива, Яндекс видит правильный маршрут, свободного места на диске хватает. Осталось примерно 16 часов, если Яндекс не решит устроить вечернюю драму.

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

Это продолжение истории с очисткой Яндекс.Диска

До этого уже была большая работа: я вместе с Codex разобрал Яндекс.Диск через официальный доступ Яндекса. Не через веб-интерфейс, не через ручное «открой папку, посмотри, устань», а через отдельное OAuth-приложение и Yandex Disk REST API.

Я уже писал об этом отдельно: Как я разобрал Яндекс.Диск через Codex и официальный доступ Яндекса.

Там важна была не романтика уборки, а дисциплина:

• сначала только аудит метаданных;
• ничего не скачивать;
• ничего не удалять;
• собрать карту папок;
• найти точные дубли по md5 + размер;
• отделить очевидное от спорного;
• перенести лишнее в _Quarantine, а не удалять сразу;
• перед удалением собрать опись готовности к удалению;
• удалять только подтверждённый класс, только после отдельного решения, и сначала в корзину.

В результате старый Яндекс.Диск перестал быть цифровым шкафом, где десять лет подряд кто-то складывал «временно». Появились нормальные верхние домены: _Music, _Projects, _Media, _Archive, Фабрика контента, Uplifto, НЕСПАТЬ! коллекция, _Quarantine.

Важный момент: _Quarantine не означает «мусор, можно стереть». Это зона с историей решений. Там лежат разные классы файлов: точные дубли, кандидаты на разбор, старые рабочие копии, ручные зоны. Поэтому в новом переносе мы решили: _Quarantine копируем. Это часть архива и журнал решений.

А вот .SynologyWorkingDirectory не копируем. Это служебная папка Synology-синхронизаций, а не человеческая структура Яндекс.Диска. В описи она была видна, но в чистом импорте ей делать нечего.

Зачем вообще переносить в Synology

Яндекс.Диск полезен как облако, но когда архив становится большим и важным, хочется не только платить за место, а понимать архитектуру хранения.

Часть данных может жить в облаке. Часть лучше держать локально. Часть нужно архивировать. Часть вообще надо удалить после нормальной проверки. Но для этого сначала нужно иметь управляемую копию и понятный процесс миграции.

Synology в этой истории становится не просто «сетевым диском дома». Это домашнее хранилище, включённое в общую инфраструктурную картину: локальная сеть, Tailscale/Headscale, маршрутизация, серверные контуры, резервные копии, доступы, документы.

У меня под это уже появилось отдельное инфраструктурное рабочее пространство. Там живут задачи по Synology, Headscale/Tailscale, домашней маршрутизации, Keenetic, Cloudflare/Happ, Timeweb/VPS и вообще всему, что раньше было «ну где-то там настроено».

Это выросло из той же логики, что и аудит VPS на Timeweb, о котором я писал здесь: Как я решил узнать, что вообще живет на моих серверах, и позвал Codex с фонариком.

Там история была про семь VPS: сначала API, потом SSH в режиме только чтения, потом паспорта серверов, потом риски, потом точечные изменения. Здесь похожая философия, только вместо облачных машин у нас домашний NAS и личный архив.

Степан, конечно, сказал бы скучнее:

«Это не копирование файлов. Это перенос состояния между контурами хранения с проверяемой областью, журналом выполнения и маршрутом данных».

Человеческий перевод: терабайт едет домой, но не как попало.

Сначала опись, потом копирование

Перед переносом мы не стали сразу говорить Synology: «иди и скачай всё». Сначала сделали опись активного дерева disk:/ только с метаданными.

Это снова тот же принцип: сначала считаем, потом действуем.

Опись показала активное дерево Яндекс.Диска:

• 225482 файла;
• 14509 директорий;
• примерно 1.2 TB данных;
• без корзины Яндекс.Диска;
• без скачивания содержимого файлов;
• без изменений на Яндекс.Диске.

Потом мы применили выбранную область:

• _Quarantine включить;
• .SynologyWorkingDirectory исключить;
• корзину Яндекс.Диска не трогать;
• никаких перемещений или удалений в Яндекс.Диске;
• копируем только активное дерево по описи.

Итоговая область получилась такая:

• 216178 файлов;
• 14364 директорий;
• 1301378491120 байт, то есть около 1.301 TB.

Это важный психологический момент. Когда говоришь «скопировать Яндекс.Диск», это звучит как бытовая операция. Когда говоришь «скопировать 216178 файлов по заранее собранной описи, исключив служебную директорию и сохранив карантинный контур», это уже перестаёт быть бытовой операцией и начинает пахнуть нормальной инженерией. Немного пылью из серверной, но в хорошем смысле.

Почему копирует Synology, а не MacBook

Было два варианта.

Первый: MacBook скачивает файлы из Яндекса и отправляет их на Synology по SMB или SSH.

Схема простая:

Облако Яндекс.Диска -> MacBook -> Synology

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

Второй вариант: Synology сама становится обработчиком.

Облако Яндекс.Диска -> Synology

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

Мы выбрали второй вариант.

На Synology не оказалось rclone, docker, tmux или screen, зато был python3 и nohup. Поэтому самый узкий путь без установки лишних пакетов был такой: написать обработчик на Python, который работает с Yandex Disk REST API напрямую, читает опись, скачивает файлы, проверяет размер и md5, пишет журналы в формате JSONL и умеет пропускать уже скачанное.

Токен не попал ни в git, ни в markdown, ни в чат. Он лежит в защищённой рабочей зоне на NAS с правами 600. В статье я специально не публикую точные внутренние пути и сетевые детали, потому что техническая статья не должна превращаться в карту доступа к домашней инфраструктуре.

Отдельный вопрос: а маршрут точно правильный?

В какой-то момент я спросил:

«А это сейчас точно идёт напрямую?»

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

Проверка оказалась интересной. Обычные публичные канареечные сервисы определения IP давали неоднозначную картину. Но для нас был важен не абстрактный публичный IP для любого сайта, а именно то, как Яндекс видит соединение с Synology.

Поэтому мы проверили маршрут отдельно:

• что видит Yandex Internetometer API;
• как идут маршруты до yandex.ru;
• как идут маршруты до cloud-api.yandex.net;
• как идут маршруты до downloader.disk.yandex.ru.

Вывод: публичные канареечные сервисы могли ходить через один маршрут по политике, но Яндекс видел Synology через правильный прямой маршрут. После этого мы не просто «поверили и поехали», а добавили защиту маршрута.

Теперь обработчик запускается с обязательной проверкой: перед работой и во время работы Яндекс должен видеть ожидаемый маршрут. Параллельно идёт отдельный наблюдатель. Раз в минуту он спрашивает у Яндекса: «Кто я для тебя?» Если ответ внезапно меняется, наблюдатель убивает обработчик.

Это один из моих любимых моментов во всей операции. Не «кажется, нормально», а буквально:

если Яндекс видит не тот маршрут -> остановить копирование

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

Первые ошибки были не у Яндекса, а у имён файлов

Конечно, если копируешь старый человеческий архив, проблема редко бывает только в API.

Сначала пилотный запуск прошёл нормально. Потом полный запуск тоже пошёл, но через некоторое время появились ошибки. Не из-за маршрута. Не из-за OAuth. Не из-за Яндекса. Из-за имён файлов и поведения файловой системы Synology.

Два класса проблем:

1. Очень длинные имена файлов, особенно с кириллицей. Обработчик сначала создавал временный файл рядом с целевым, добавляя суффикс. В одном месте само имя файла ещё помещалось, а имя файла плюс временный суффикс уже нет.
2. Директории с пробелами на краях имени. Такие штуки в облаке могут жить годами, а локальная файловая система и Synology начинают смотреть на них с выражением «давайте не будем».

Это прекрасная иллюстрация миграций: данные вроде «те же самые», но среда уже другая. Облако, macOS, Linux, Synology, SMB, веб-интерфейс и API могут по-разному относиться к пробелам, Unicode, длине сегмента и служебным конфликтам.

Мы остановили обработчик, поправили стратегию и продолжили.

Что изменилось:

• временные файлы переехали в отдельную рабочую папку для частичных файлов;
• имена временных файлов стали короткими именами на основе хешей;
• опасные сегменты пути нормализуются детерминированно;
• если целевой путь отличается от исходного пути, это пишется в журнал соответствий;
• старые частичные файлы и пустые конфликтные директории были убраны;
• опись повторных попыток собрали только из ошибочных строк.

Потом прогнали проблемные 44 пути, примерно 8.3 GB, и получили errors=0.

Вот это важная разница между «скрипт упал» и «миграция управляемая». Упасть может всё. Вопрос в том, есть ли журнал, область повторов, понятная причина, маленький фикс и проверка, что фикс действительно прошёл.

Как это выглядит прямо сейчас

На момент черновика копирование идёт.

Живой статус такой:

• обработчик на Synology работает;
• наблюдатель за маршрутом работает;
• текущий запуск идёт без ошибок;
• на Synology уже лежит примерно 233.8 GB завершённых файлов;
• это около 18% от общего объёма 1.301 TB;
• по количеству файлов это примерно 6305 из 216178, то есть около 2.9%;
• текущий запуск уже скачал около 86.9 GB после последнего перезапуска;
• место на /volume1 есть, свободно около 4.4 TB.

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

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

Проводник в нашем случае называется tail -f.

Что здесь на самом деле делает Codex

Снаружи можно сказать: «ИИ копирует файлы». Но это будет неточно.

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

• какая область согласована;
• что можно копировать, а что нельзя;
• где лежит опись;
• какой обработчик сейчас запущен;
• где журнал стандартного вывода;
• где журнал в формате JSONL;
• сколько скачано;
• есть ли ошибки;
• правильный ли маршрут до Яндекса;
• не попал ли секрет в документ;
• какой был последний фикс;
• что надо проверить перед следующим шагом.

Вручную всё это тоже можно делать. Но вручную такая работа быстро превращается в десять вкладок терминала, пять заметок, два скриншота и ощущение «я вроде всё помню». А ощущение «вроде» в инфраструктуре обычно стоит дороже, чем нормальный журнал.

У Codex здесь роль оператора:

1. Собрать факты.
2. Предложить безопасный вариант.
3. Получить ограниченное одобрение.
4. Запустить маленький пилот.
5. Проверить результат.
6. Запустить полный прогон.
7. Следить за маршрутами и ошибками.
8. Остановиться, когда что-то не так.
9. Починить обработчик, не ломая данные.
10. Продолжить с понятным повтором.

Это не геройская автоматизация. Это скучная, взрослая автоматизация. Мне такая нравится.

Почему это часть большого инфраструктурного сюжета

За последние недели у меня складывается очень понятный паттерн.

Сначала был аудит Timeweb VPS: серверы, API, SSH, паспорта, риски, документы. Потом Яндекс.Диск: OAuth, сканирование только метаданных, карантин, готовность к удалению, осторожные удаления. Теперь Synology: домашнее хранилище, защита маршрута, копирование по описи, повторы, журналы.

Все эти истории вроде про разные вещи. Одна про VPS, другая про облако, третья про NAS. Но внутри у них один и тот же принцип:

• не начинать с изменений;
• сначала увидеть реальность;
• отделить факты от догадок;
• записать область;
• сделать обратимый шаг;
• не печатать секреты;
• не путать «можно технически» с «можно по смыслу»;
• оставлять после себя карту, а не просто результат.

Вот это и есть для меня настоящая ценность подхода Codex-first. Не «чатик помог написать скрипт». А рабочий способ превращать цифровое хозяйство из набора случайных решений в управляемую систему.

И да, иногда эта система выглядит как человек, который в воскресенье вечером смотрит, как NAS качает 1.3 TB, и радуется строке errors=0 больше, чем нормальные люди радуются прогнозу погоды.

Что будет после копирования

Само копирование не конец истории.

После завершения нужно будет сделать нормальную сверку:

• сколько файлов ожидали;
• сколько файлов реально лежит на Synology;
• сколько байт ожидали;
• сколько байт реально записано;
• есть ли строки с ошибками в журнале JSONL;
• есть ли соответствие путей для нормализованных имён;
• нет ли незавершённых частичных файлов;
• какие файлы были пропущены как уже существующие;
• надо ли делать второй проход проверки.

И только после этого можно будет говорить: «да, активное дерево Яндекс.Диска с _Quarantine, но без .SynologyWorkingDirectory, перенесено на Synology».

Дальше появится отдельный вопрос: что делать с исходным Яндекс.Диском. Удалять? Оставлять как временную копию? Делать холодный архив? Разносить часть данных по другим хранилищам? Это уже отдельное решение, и оно не должно автоматически следовать из факта, что копия появилась.

Копия даёт свободу. Но свобода не равна немедленному удалению.

Маленький вывод

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

А дальше из этого вырос нормальный контур обработки данных для личной инфраструктуры:

• официальный доступ к Яндекс.Диску;
• аудит только метаданных;
• дубли и карантин;
• контролируемое удаление;
• Synology как домашнее хранилище;
• прямой обработчик на NAS;
• защита маршрута;
• журналы повторов;
• текущий контроль прогресса.

В старой версии мира я бы, возможно, просто открыл Finder, начал перетаскивать папки и через три часа понял, что не знаю, что уже скопировалось, что упало, почему ноутбук греется и чей это вообще был файл final_final_2.zip.

В новой версии мира я спрашиваю:

«Стёпа, как обстановка?»

А он отвечает:

«Идёт нормально. Примерно 18%. Ошибок 0. Маршрут до Яндекса правильный. MacBook терабайт не тащит. Можно писать статью, пока Synology работает».

Так и живём: одни люди смотрят сериалы, другие смотрят журналы JSONL. У каждого свои способы расслабиться.

По теме

• Статья: Как я разобрал Яндекс.Диск через Codex и официальный доступ Яндекса
• Статья: Как я решил узнать, что вообще живет на моих серверах, и позвал Codex с фонариком
• Статья: Как мы с Codex превратили хаос серверов в карту управляемой инфраструктуры

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

А дальше можно подключать Codex, Synology, API, журналы и спокойную инженерную занудность. Иногда именно она спасает терабайты от приключений.

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

Если хочется превратить такой архив или домашнюю инфраструктуру в управляемую систему с описью, журналами и обратимыми шагами — пишите в Telegram @pimenov. Это как раз тот разговор, который мне самому интересен