Linux на Linux, 10 ТБ перевод?

9

Я рассмотрел все предыдущие подобные вопросы, но ответы, казалось, были повсюду, и никто не перемещал много данных (100 ГБ отличается от 10 ТБ).

У меня есть около 10 ТБ, которые мне нужно перенести с одного RAID-массива на другой, гигабитный Ethernet, бесплатная энциклопедия, файловые системы XFS . Больше всего меня беспокоит то, что передача умирает на полпути, и я не могу вернуться легко. Скорость была бы хорошей, но обеспечение передачи намного важнее.

Обычно я просто использую tar & netcat, но RAID-массив, с которого я перехожу, в последнее время был очень ненадежным, и мне нужно иметь возможность восстановить и возобновить работу, если он перестал работать в середине процесса. Должен ли я смотреть на rsync ?

Рассматривая это немного подробнее, я думаю, что rsync может быть слишком медленным, и я бы хотел избежать этого, если оно займет 30 дней или более. Поэтому сейчас я ищу предложения о том, как отслеживать / возобновлять передачу с помощью Netcat .

— lostincode
источник

Иногда мне нужно выполнять передачу больших файлов (но не 10 ТБ;) rsync имеет много флагов, некоторые из которых могут повлиять на производительность передачи больших файлов (я думаю, что --checksum и --archive могут, например, замедлить работу. будет иметь большое значение при переводе 10 ТБ.) Кто-нибудь может порекомендовать хорошие варианты, которые помогут оптимизировать производительность передачи такого большого файла? Поможет ли тюнинг --block-size=SIZE?

— Стефан Ласевский

есть ли вообще удалить ssh?

— lostincode

1

настроить rsyncd на принимающей стороне? нет необходимости в ssh

— cpbills

3

Запустите демон rsync на принимающей стороне, а также на стороне отправителя.

— Приостановлено до дальнейшего уведомления.

2

Если вы не можете настроить демон rsync с одной стороны и зависаете с SSH, вы можете уменьшить накладные расходы на шифрование с помощью менее надежного шифрования, например: rsync -avz -e 'ssh -c arcfour' SOURCE DEST

— David

14

да, rsync

за пределами Oddball, асинхронные функции DRBD вышли недавно.

— cagenut
источник

1

+1 для Rsync. Король межсистемных переводов в Linux.

— Grufftech

+1, rsync (и его аналог для Windows DeltaCopy) - вот конец общего эффективного дублирования файлов между серверами.

— Крис С

1

+1 для rsync, но я бы добавил, что может быть быстрее сделать это «локально» через монтирование NFS вместо того, чтобы нести издержки на протокол rsync или SSH.

— Джеймс Снерингер

2

Никогда не стоит недооценивать пропускную способность универсала, полного лент. 10 ТБ было бы возможно с относительно дешевым оборудованием NAS потребительского уровня, если бы вы могли разделить его на (скажем, 2 ТБ) куски. Если это одноразовый процесс, то можно выполнить полуручный процесс, а NAS объемом 2 ТБ стоит всего несколько сотен долларов.

Если вам нужен постоянный процесс, вы можете настроить RSYNC после того, как сделали начальную передачу.

— ConcernedOfTunbridgeWells
источник

В первоначальном вопросе говорилось, что это уже через локальную сеть.

— Ладададада

1

Что кажется слишком медленным и / или ненадежным для целей ОП.

— ConcernedOfTunbridgeWells

2

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

https://gist.github.com/rcoup/5358786

— Пьер Бергдольт
источник

0

Вы можете попробовать настроить FTP-сервер на сервере с копируемыми данными и использовать клиент FTP с «резюме» на принимающей стороне. Я использую сервер и клиент Filezilla и довольно часто использую функцию «возобновить» клиента, и она всегда работала без помех.

— jamesbtate
источник