Миграция в облако: стратегия передачи файлов

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

Инвентаризация датасета перед началом работы

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

Горячие данные (активно изменяются, к ним обращаются ежедневно) требуют одного подхода; холодные архивы (не изменялись годами) — совершенно другого. Данные, содержащие персональные данные в смысле 152-ФЗ, требуют дополнительного анализа: нужно убедиться, что целевой облачный регион соответствует требованиям Роскомнадзора о локализации данных граждан РФ на территории России.

Практическое правило: холодные данные уходят первыми, за несколько недель до финального переключения. Горячие данные переключаются в самое короткое окно. Если смешать их в одну волну — переключение растянется, а риск ошибок резко возрастёт.

Выбор транспорта под реальные сроки

Объём данных и доступная полоса пропускания диктуют транспортный путь:

До 10 ТБ — онлайн-передача. AWS DataSync, rclone, AzCopy или gsutil справятся через публичный интернет или VPN. При скорости 1 Гбит/с 10 ТБ занимают около 22 часов — приемлемо для ночного окна обслуживания.

От 10 до 500 ТБ — выделенные каналы. AWS Direct Connect, Azure ExpressRoute или аналогичный управляемый канал обеспечивают предсказуемую полосу без конкуренции с интернет-трафиком. 100 ТБ при гарантированном 1 Гбит/с — около 14 дней: планируйте начало за месяц до переключения.

Свыше 500 ТБ — физическая доставка. AWS Snowball Edge (80 ТБ на устройство), AWS Snowmobile (до 100 ПБ) или Azure Data Box Heavy (1 ПБ) отправляются физически. Пропускная способность физического диска по-прежнему обгоняет большинство интернет-каналов при таких объёмах. Учтите 1–2 недели на доставку и загрузку в расчёте сроков.

Целостность: доверяй, но проверяй контрольными суммами

Сетевая передача вносит ошибки — особенно многодневная. Никогда не считайте файл перемещённым без проверки контрольной суммы.

SHA-256 надёжен для соответствия требованиям; xxHash64 в 10 раз быстрее при отсутствии жёстких требований к криптографической стойкости — хорошо подходит для больших массивов медиафайлов. AWS DataSync проверяет контрольные суммы по умолчанию. При использовании rsync обязательно указывайте флаг --checksum; rclone — --check-first. Сохраняйте манифест в виде CSV с полями: путь, размер, контрольная сумма, временна́я метка. Манифест загружается последним и служит эталоном для постмиграционной сверки.

Минимизация простоев через дельта-синхронизацию

Финальное переключение должно быть минимальным по времени — для этого нужна предварительная объёмная копия с последующими дельта-запусками.

Типичная схема: объёмная копия завершается за 1–2 недели до переключения. Ежесуточные дельта-запуски переносят только изменившиеся файлы. В час переключения — финальный дельта-запуск для синхронизации последних изменений, затем переключение трафика.

Команды для дельта-синхронизации:

• rclone: rclone sync source: dest: --update (копирует только файлы, изменённые после последней синхронизации)
• AzCopy: azcopy sync source dest --overwrite=ifSourceNewer
• gsutil: gsutil rsync -d source gs://dest

Для баз данных PostgreSQL — pg_basebackup для начальной копии с последующей потоковой репликацией WAL до момента переключения. MySQL/MariaDB — аналогичный подход через бинарные логи. Не пытайтесь перенести активную СУБД одним снимком без схемы репликации — получите рассогласование.

Управление пропускной способностью и время переноса

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

Рекомендуемые лимиты:

• Рабочее время (9:00–18:00): 30% доступной полосы
• Ночное время (18:00–8:00): 90%
• Выходные: 100%

Настройка лимитов по инструментам:

• AzCopy: --cap-mbps 50 (дневной), запуск отдельным экземпляром с --cap-mbps 150 в ночное время
• rclone: --bwlimit 50M:100M (формат: день:ночь, определяется расписанием CRON)
• AWS DataSync: часовые ограничения полосы в настройках задачи

Перегружать канал в ночное время стоит, только если у вас нет другого трафика. В противном случае — мониторинг задержки VoIP и видеосвязи, остановка рабочих нагрузок передачи при деградации.

Обработка чувствительных данных в транзите

Минимальный уровень безопасности — TLS 1.3 для всего транзитного трафика. Но для персональных данных (152-ФЗ), медицинской документации, финансовых отчётов и коммерческой тайны — этого недостаточно.

Дополнительные меры:

• Шифрование на стороне клиента перед загрузкой: AES-256-GCM с ключами под вашим управлением (AWS KMS, Azure Key Vault, HashiCorp Vault)
• PCI DSS 4.0 требование 4.2.1 запрещает передачу данных карт по незашифрованным каналам — TLS 1.3 обязателен, документирование маршрута также
• Для разовых файлов, требующих передачи вне основного канала миграции: E2EE-ссылка через HexaTransfer позволяет отправить файл юристу, аудитору или внешнему партнёру без предоставления им доступа к облачному аккаунту

При 152-ФЗ особое внимание: если данные содержат персональные данные граждан РФ и целевой регион — зарубежный (например, ирландский регион AWS или нидерландский Azure), потребуется согласие субъектов или надлежащее правовое основание для трансграничной передачи. Уточните с юристом по ИТ-праву до начала переноса.

Репетиция переключения до самого переключения

Переключение без репетиции — билет к ночному кризису. Проведите полноценную тренировку на подмножестве данных (5–10% объёма) за 2–3 недели до финальной даты.

На что обращать внимание при репетиции:

NTFS ACL → политики S3. Права доступа Windows не переносятся напрямую в объектное хранилище. Составьте явное соответствие: группы Active Directory → политики IAM или роли. Не рассчитывайте на автоматическое преобразование.

Символические ссылки. rclone по умолчанию копирует содержимое symlink, а не ссылку. Если приложение зависит от структуры symlink — проверьте поведение на этапе репетиции.

Пути SMB-шар в конфигурациях приложений. Хардкоженые UNC-пути (\\fileserver\share\data) в конфигах приложений сломаются после переключения. Инвентаризируйте все пути до начала репетиции и замените на S3 URI или смонтированные точки.

Регистрозависимость. Linux-файловые системы и S3 чувствительны к регистру; Windows — нет. Document.pdf и document.pdf — разные объекты в S3. Конфликты, которые на Windows незаметны, проявятся после миграции.

Постмиграционная сверка

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

Процедура сверки:

1. Сравните количество объектов и суммарный объём: источник vs. назначение
2. Пробно проверьте хеши 1–5% файлов случайной выборкой — особенно крупных и критичных
3. Сверьте с манифестом, созданным на этапе инвентаризации
4. Зафиксируйте расхождения и устраните до снятия режима только чтения

Не удаляйте исходные данные до истечения 30-дневного периода. Если обнаружится пропущенный файл через неделю после переключения — возможность восстановить его из источника сэкономит много нервов.

Попробуйте на hexatransfer.com — бесплатно, без аккаунта, до 10 ГБ.