Лучший способ скопировать большой объем данных между разделами

Лучший способ скопировать большой объем данных между разделами

Я хочу перенести данные через 2 lv сервера HP-UX. Мне нужно сделать несколько таких передач, некоторые из которых в основном двоичные (табличное пространство Oracle...), а некоторые другие — текстовые файлы (логи...). Используемый размер данных томов составляет от 100 ГБ до 1 ТБ. Кроме того, я изменю размер блока с 1 КБ на 8 КБ на некоторых из этих разделов...

Что я ищу:

  • Гарантирует целостность данных
  • Самая высокая скорость передачи данных
  • Сохраняет права собственности на файл и разрешения

Сейчас я думаю о dd, cp и rsync, но не уверен, какой из них лучше использовать и как лучше всего их использовать...

решение1

Вам не нужно использовать dd. Это для работы с одним файлом или потоком, а не со всей файловой системой.

rsync разработан для того, чтобы делать то, что вам нужно, но, как сказал предыдущий автор, и как показали мои тесты, он не самый быстрый. Это потому, что он для чего-то вроде этого: "Хорошо, я смотрю на файл A. Файл A в месте назначения? Если да, то он новее, старше, тот же?" И т. д. rsync немного сложен, потому что он должен запускаться более одного раза... как следует из названия, он для синхронизации двух местоположений.

Для выполнения того, что вам нужно, я обнаружил, что tar-копия — это быстро, легко и надежно. Tar знает о жестких ссылках. Tar знает об устройствах. Tar обрабатывает практически любую ситуацию, с которой вы столкнетесь в своей файловой системе (за исключением очень длинных путей, и, если вы не используете Gnu tar, вам, возможно, следует быть осторожнее с добавлением символа / в начало пути).

В любом случае, за последние 20 лет я добился 99,98% успеха, делая следующее:

cd /my/source; tar cf - subdirectory | (cd /destination/path; tar xf -)

...Подкаталог, который вы хотите скопировать, появится в /destination/path.

Если вы хотите следить за своим прогрессом, вы можете использовать «xvf» вместо «xf» в последней части этой строки.

...мои 0,02% сбоев произошли из-за очень длинных путей к файлам... :-(

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

НО! В вашем сообщении конкретно упоминается целостность файлов, и я извиняюсь за то, что не включил решение в свой ответ много лет назад...

После tar я просто делаю это. Притворяюсь, что я сделал

cd /path/to/source/dir; tar cf - * | (cd /path/to/dest/dir; tar xf -)

Теперь гарантию вашего файла можно оформить следующим образом:

find * -exec md5sum {} /path/to/dest/dir/{} \; > /path/to/dest/dir/md5-manifest.txt

Закончив, вы можете либо просмотреть файл манифеста, либо написать скрипт awk (оставленный в качестве упражнения для пользователя) для сравнения двухстрочного вывода команд find/md5sum.

решение2

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

решение3

Я бы рекомендовал использовать rsync, так как он имеет функции, которые специально решают большинство ваших проблем. Если вы используете соответствующие параметры (например, -aпараметр ), то все владельцы файлов, разрешения и время будут сохранены. Кроме того, rsyncавтоматически использует контрольные суммы, чтобы гарантировать, что все переданные файлы прибудут в пункт назначения в целости и сохранности, поэтому целостность данных гарантирована (предполагая успешный запуск).

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

решение4

По сути, у вас есть три варианта:

  1. Копировать весь раздел/блочное устройство
  2. Дамп всей файловой системы
  3. Скопировать данныевнутрифайловая система

Выберите один из трех вариантов в зависимости от того, что вам нужно было сделать в резервной копии, и какие результаты вы хотите получить. Для вашего конкретного случая, я думаю, что вариант № 1 (копирование блочного устройства) в сочетании сddrescueэто путь. В любом случае, давайте посмотрим на коллекцию доступных вариантов.

Случай 1: копирование раздела
ЗА: копируя целое блочное устройство, вы уверены, что ничего не осталось.
ПРОТИВ: возиться с блочными устройствами менее удобно, чем работать с файлами, выбор неправильного блочного устройства или параметров может уничтожить ваши данные.

Если вы хотите иметь бинарную копию всего блока dev, вам нужно использовать dd или подобный инструмент. Другие очень полезные инструменты:dcfldd(хэш-готовая dd-форк) иddrescue(еще более продвинутый инструмент типа dd).

Случай 2: дамп файловой системы
ЗА: копируя всю файловую систему, вы уверены, что все данные и метаданные внутри нее были зарезервированы.
ПРОТИВ: если нужно сделать резервную копию нескольких файловых систем, вам придется делать несколько проходов (один для файловой системы)
Полезный инструмент для работы с файловыми системами —FSАрхив. Более того, многие файловые системы имеют интегрированные утилиты для эффективного дампа своего содержимого (например: XFS имеет xfsdump, Ext2/3/4 используют dumpe2fs и т. д.).

Случай 3: копирование данных внутри файловой системы
ЗА: копируя данные изнутри файловой системы, вы можете очень точно выбрать, что именно резервировать. Это гарантирует быстрое время резервного копирования/восстановления и небольшие резервные образы.
ПРОТИВ: вы должны были прекрасно знать, что и как резервировать. Особое внимание следует уделять важным метаданным (например, владелец, разрешение, ACL, EA...)
Rsyncтвой лучший друг здесь.Rsnapshotиrdiff-резервное копирование— замечательные инструменты, созданные на основе rsync/librsync.Тарэто швейцарский нож любого системного администратора Unix.

Связанный контент