Побитовое копирование против файловой синхронизации при переносе системы на новый диск

Перенести содержимое одного накопителя на другой в Linux можно несколькими способами, но чаще всего спор сводится к двум проверенным инструментам. Один из них работает на уровне сырых блоков и снимает с диска точный слепок до последнего байта. Другой действует на уровне файлов и переносит ровно то, что реально занято данными, попутно умея синхронизировать копию с оригиналом. Это утилита побитового копирования и утилита файловой синхронизации, и выбор между ними определяет не только скорость переноса, но и безопасность всей затеи.

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

Что значит копировать диск на уровне блоков и чем это оборачивается

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

sudo dd if=/dev/sda of=/dev/sdb bs=64M status=progress

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

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

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

Почему файловая синхронизация переносит только нужное и умеет докатывать изменения

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

sudo rsync -aAXv --delete /mnt/source/ /mnt/target/

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

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

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

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

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

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

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

Тонкости переноса системного дерева, о которых легко забыть

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

sudo rsync -aAXv --delete \
  --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/swapfile"} \
  /  /mnt/target/

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

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

Перенос между машинами и проверка целостности копии

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

sudo rsync -aAXv -e ssh /mnt/source/ Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript.:/mnt/target/

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

После любого переноса разумно убедиться, что копия совпала с оригиналом. Для побитового слепка это делают сравнением контрольных сумм обоих устройств, которые при точном копировании обязаны совпасть до последнего байта.

sudo cmp /dev/sda /dev/sdb

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

Скорость переноса и узкие места

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

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

Чтобы выбор не превращался в гадание, удобно держать в голове короткий ориентир по задачам:

1. Точная копия диска целиком вместе с загрузчиком и разметкой для архива или восстановления это работа для побитового копирования;
2. Перенос данных на диск другого размера или другую файловую систему ложится на файловую синхронизацию;
3. Регулярные резервные копии с переносом только изменений это вотчина файловой синхронизации;
4. Миграция работающей системы с минимальным простоем делается файловой синхронизацией в два прогона;
5. Снятие криминалистического слепка или копирование с подозрением на сбойные секторы требует побитового подхода или его спасательного родственника.

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

Что в итоге выбрать

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

Файловая синхронизация выигрывает почти во всех сценариях повседневного переноса данных и резервного копирования. Она экономит время и место, переносит лишь нужное, докатывает изменения и куда мягче ведёт себя на живой системе. Цена этого удобства в дополнительной возне с разметкой и загрузчиком, которую приходится делать руками. Зная сильные и слабые стороны обоих, человек перестаёт бояться переноса системы и выбирает инструмент осознанно, а не наугад.