Назад | Перейти на главную страницу

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

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

Вещи, которые я ищу:

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

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

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

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

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

cd / my / source; tar cf - подкаталог | (cd / назначение / путь; tar xf -)

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

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

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

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

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

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

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

В основном у вас есть три варианта:

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

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

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

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

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

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