Миграция с облачного Mac mini до конца аренды: резервное копирование и перенос среды

周五下午的对话要改写成俄语正文，标题层级与锚点保持一致。

Почему миграция часто проваливается перед истечением аренды

В пятницу днём коллега, отвечающий за релизы, написал в чат: «Наш Mac mini с помесячной арендой заканчивается в следующую среду — что делать с сертификатами, данными симуляторов и кешем Homebrew?» Никто не смог сразу назвать полный список — это классический признак провальной миграции. Облачный Mac mini удобен в работе, но многие настройки живут в состоянии «пользуюсь и забываю, где это лежит», и только в момент завершения аренды выясняется, что нужное разбросано по десяткам каталогов.

Большинство понимает «миграцию» как «скопировать папку с проектом обратно на локальную машину», но на самом деле сборку чаще всего блокируют скрытые конфигурации: ключи развёртывания, выпущенные в ~/.ssh, сертификаты дистрибуции в Keychain, инкрементальный индекс сборки в ~/Library/Developer/Xcode/DerivedData, а также кеш-пути, которые различные инструменты незаметно пишут в домашнюю директорию пользователя. В повседневной работе это незаметно, но как только машина освобождается по истечении срока, вернуть это уже невозможно.

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

Инвентаризация активов перед миграцией: что обязательно нужно забрать

Сначала разделим то, что нужно перенести, на две категории — само разделение уже снижает риск что-то упустить.

Конфигурация среды разработки

Сюда входят конфигурация shell (.zshrc/.zprofile), SSH-ключи и known_hosts, глобальная конфигурация и учётные данные Git, сертификаты подписи и профили обеспечения Xcode, а также записи Keychain, экспортированные командой security. Эти файлы небольшие по объёму, но критически важны — рекомендуется собрать их в отдельный архив.

Проекты и кеш зависимостей

Сюда входят репозитории кода (теоретически всё должно быть на удалённом сервере, но локальные непроталкнутые ветки нужно проверить отдельно), локальный кеш CocoaPods и SwiftPM, список установленных пакетов Homebrew (экспорт Brewfile через brew bundle dump гораздо выгоднее, чем копирование целиком /opt/homebrew), а также файлы блокировки версий вроде Podfile.lock и .xcode-version.

Трёхуровневая стратегия резервного копирования: инкрементальный rsync + tar-архив + скачивание снапшота

Не стоит полагаться на один-единственный метод — устойчивость даёт только комбинация трёх уровней.

Инкрементальная синхронизация с rsync

Запускается с локальной машины и синхронизирует ключевые каталоги с Mac mini на локальный диск или точку монтирования объектного хранилища:

rsync -avz --delete \
  --exclude 'DerivedData' \
  --exclude 'node_modules' \
  dev@hk1.oncemini.com:~/projects/ \
  ~/backup/mac-mini-hk1/projects/

Исключение каталогов вроде DerivedData и node_modules, которые можно пересобрать заново, сокращает время синхронизации с десятков минут до нескольких минут. Рекомендуется запускать синхронизацию ежедневно начиная за неделю до окончания аренды, а не выполнять её впервые в последний день — время первой полной синхронизации почти всегда недооценивают.

Упаковка неизменяемого архива

Для сертификатов, ключей и прочих данных, которые редко меняются, но потерять их категорически нельзя, соберите отдельный зашифрованный архив:

tar czf keychain-backup.tar.gz \
  ~/Library/Keychains \
  ~/.ssh
gpg -c keychain-backup.tar.gz

Зашифрованный архив далее передаётся через rsync или скачивается напрямую — это позволяет избежать попадания секретов в открытом виде на промежуточные узлы передачи.

Скачивание снапшота платформы как последний резерв

Если первые два уровня не успели завершиться из-за проблем с сетью, скачивание полного снапшота машины из консоли управления может служить последней страховкой — но объём нужно оценить заранее. Системный диск на 512 ГБ при домашней пропускной способности может скачиваться несколько часов, поэтому обязательно оставляйте запас времени и не начинайте загрузку в последние часы перед истечением аренды.

Частые ошибки и контрольный список

• Забыли экспортировать Brewfile через brew bundle dump — на новой машине приходится устанавливать софт по памяти, версии не совпадают.
• Скопировали только код проекта, но не локальные переменные окружения из .env — сборка на новой машине падает из-за отсутствующей конфигурации.
• Запустили rsync с правами обычного пользователя и упустили доступ к системным сертификатам, из-за чего архив получился неполным без каких-либо сообщений об ошибке.
• Начали скачивание снапшота за несколько часов до истечения срока и не успели из-за колебаний пропускной способности.
• Не отозвали ключи и токены на старой машине после миграции — после окончания аренды эти учётные данные теоретически остаются действительными, что создаёт риск безопасности; их нужно активно отзывать во время последнего входа на машину.

Проверка холодного старта на новой машине после миграции

Перенос данных — это не конец процесса, нужно провести полную проверку в новой среде, чтобы завершить миграцию:

brew bundle install --file=Brewfile
pod install --repo-update
xcodebuild -workspace App.xcworkspace \
  -scheme App -configuration Release \
  clean build
shasum -a 256 build/App.app/App

Сравните вывод shasum для старой и новой сборки — только совпадение подтверждает, что миграция действительно завершена. Этот шаг часто пропускают, но именно он — единственное объективное доказательство того, что среда не потеряла ничего, и он гораздо надёжнее, чем субъективное «кажется, всё работает».

Часто задаваемые вопросы