Перенос системы, что лучше, cp, tar, cpio, rsync?

использую rsync или dump в сочетании с PXE-загрузкой, достаточно быстро можно залить по сети настроенную ОС на машинку, в случае с dump время залития ОС на новую железку около 7-ми минут. Если работать локально то cp хватит. dd - долго и муторно, потеря времени большая.

XFS подходит. ZVOL подходит. Ext{2,3,4} и LVM{,2} — не подходят.

РЕСПЕКТ И УВАЖУХА

Взялся отсюда

Metadata operations in XFS have historically been slower than with other file systems, resulting in, for example, poor performance with operations such as deletions of large numbers of files. However, a new XFS feature implemented by Dave Chinner and called delayed logging, available since version 2.6.39 of the Linux kernel mainline, is claimed to resolve this;[22] performance benchmarks done by the developer in 2010 revealed performance levels to be similar to ext4 at low thread counts, and superior at high thread counts.[23]

Но это уже пять лет как неправда. Я помню тормоза при удалении действительно больших деревьев (256*256*256 каталогов, в каждом 1…3 файла), но такое любая доступная на тот момент файловая система пережёвывала весьма неторопливо. При обычной работе проблема себя если и проявляла, то очень незаметно. Хотя, у нас тогда основная нагрузка была на запись и чтение, удалялось что-то редко и обычно в фоновом режиме в рамках еженедельных чисток конюшен, может быть поэтому проблемы с удалением мало касались.

Надо было перенести сервак по сети.

Юзал tar пайпом для переноса системных файлов, сайта (кроме картинок) и т.д. Базу переносил через дамп, тем более там менялась версия mysql и делался переход с MyISAM на InnoDB. rsync юзал для 18 000 000 jpg файлов в 4 каталогах.

ФС юзал для всего этого XFS естественно, я ж её апологет.

Черные списки зачем?

Чтобы не тратить время на перенос ненужных вещей (кэши, временные файлы и т.п.).

А почему эти вещи не нужны? Живая система, в ней всё нужно (может быть).

Когда у тебя лежит чёрный список для rdiff-backup, почему бы не воспользоваться?

Потому что это не бэкап, а клонирование.

ФС юзал для всего этого XFS естественно, я ж её апологет.

Должен был использовать xfsdump/xfsrestore

На серваке с которого переносил была ext4. Не я его настраивал. Да и гонять терабайтные дампы по интернету то еще удовольствие.

cp -ax

для переноса системных файлов, сайта (кроме картинок) и т.д

Да и гонять терабайтные дампы по интернету то еще удовольствие.

А, о_О, система и сайты с картинками на одной ФС?! Вопросов больше не имею!

Там, да, всё вместе было). Ну, а на новом серваке /boot, /, /var/www и /var/lib/mysql (последний на SSD). Всё как надо.

Там чувак правильно пишет про мифы о более вероятных потерях при некорректном завершении работы. В XFS нет такого понятия, как корректное/некорректное завершение.

В районе 2006-7 года при некорректном завершении работы XFS почти гарантированно обнуляла открытые файлы, в которые массово шла запись. EXT3 такой ерундой не страдала, но зато иногда полностью запарывалась. В промышленном масштабе (1400 серверов) решено было использовать EXT3, т.к. DU/DL был значительно меньше, чем с XFS. Говорят, XFS потом починили.

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

EXT3 такой ерундой не страдала

восстановить текстовый файл? (комментарий)

Вот у ТС'а после откл. питания в не закрытом файле вдруг обнаружился мусор, а в xfs были бы 0x00. Так в чем разница?

Вот у ТС'а после откл. питания в не закрытом файле вдруг обнаружился мусор, а в xfs были бы 0x00. Так в чем разница?

Ну вот я так и сказал: проблемы в принципе были у обоих, но в масштабе 1400 регулярно глючащих серверов (по причине китайскости железа и плохого питания) данные были реже недоступны/потеряны (DU/DL) с EXT3.

rsync — если можно воткнуть в одну систему два диска.

Тоже смотрю в сторону rsync. Переносить собираюсь на SSD, поэтому дёргать диск хотелось бы как можно меньше, хотя может, для современных SSD это уже неактуально...

В общем, никакого rocket science тут нет.

Да это понятно, но какие маленькие хитрости наверняка есть, в частности, какой из предложенных ТСом методом даст максимальное быстродействие... Теоретически это dd, но его ограничения мне понятны.

Кстати, возможно, ламерский вопрос - а если 2 диска всё равно воткнуты в одну систему, какое преимущество у rsync перед обычным cp? Он как-то гарантирует, что не будет рассинхронизации в системных файлах?

tar + netcat

РЕСПЕКТ И УВАЖУХА

фубля, не пиши мне такого больше, тошнит от школоты уже.

rsync -av --exclude /proc --exclude /tmp --exclude /sys / <target>
mkdir <target>/tmp <target>/sys <target>/proc
chmod 1777 <target>/tmp

Или stage5

для современных SSD это уже неактуально

This.

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

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

Ещё там вон выше говорят, что, мол, rsync быстрее cp, потому что чтение и запись производятся одновременно. С другой стороны, я сейчас посмотрел и стал весьма удивлён тем, что ни одна из названных утилит не использует sendfile. Даже dd.

Он как-то гарантирует, что не будет рассинхронизации в системных файлах?

Что это значит?

cp быстрее rsync, последний для каждого файла, даже в пределах локальной системы высчитывает md5, для определения целостности передачи, что вызывает дикий оверхед на миллионах файлов.

man 2 sendfile

Not specified in POSIX.1-2001, nor in other standards.

Other UNIX systems implement sendfile() with different semantics and prototypes. It should not be used in portable programs.

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

последний для каждого файла, даже в пределах локальной системы высчитывает md5

Нет, конечно. По умолчанию (без ключа -c) просто сравниваются mtime и размеры.

Сравниваются mtime и размеры при построении списка передачи, потом после копирования файла, _принудительно_ вне зависимости от ключей высчитывается его md5 и сравнивается с исходным.

т.е rsync гарантирует, что исходный и результирующий файл совпадают, в отличие от cp :) Плата за это - перерасход процессорного времени в userspace, причем упирается все это в одно ядро, потому как масштабироваться не умеет, в итоге получаем дооолгое ожидание в userspace, которое перекрывает ожидание по io, повторюсь это для миллионов файлов становится очень заметно, в обычных юзкейсах, типа перенести систему не так критично.

Столкнулись с этим когда бэкапы стали переваливать по длительности за 10 часов, после анализа графиков мониторинга и исходного кода rsync выявилась такая вот постобработка, пришлось изобретать патч и получился rsync на стероидах :) Время с 10 часов сократилось до 2-х, на мониторинге - чистый iowait и ничего больше.

Спасибо.

Гм. Не знал про пост-чексумминг, спасибо.

Пробовал только cp -ax, всем доволен

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

Гонево! Файл после копирования НЕ перечитывается для проверки. md5 сумма высчитывается в процессе передачи/записи файла и в конце записи сравнивается с исходной.

Никто не говорил, что файл после копирования _перечитывается_ для проверки. Скажем так, в конце копирования md5 сумма не пересчитывается (мб двоякое понимание), а заканчивает считаться вызовом sum_end. Кому интересно, в receiver.c всё найдет.

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

потом после копирования

Именно это звучит, как «копирование закончилось, давайте посчитаем сумму прочитав записанный файл»

md5sum не упирается в процессор, а в IO, поэтому как у тебя получилось с 10-ти часов бекапа снизить до 2-ух — большая загадка.

Вот и подумай об этом

как у тебя получилось с 10-ти часов бекапа снизить до 2-ух

бухнул-уснул-проснулся увсе готово, магия.

Очень интересный текст, спасибо. Надо будет изучить вопрос. По-идее, мы ждём btrfs...

Безопасно обновить выделенный сервер (не потерять доступ и без даунтайма) (комментарий)

вот недавно был микротест ext4 vs xfs — ext4 порван как грелка

Спасибо.