dump/restore: epic fail

Я переезжаю tarом + восстанавливаю загрузчик просто потом, с правкой fstab.

Право, даже не знаю чем теперь переезжать...

Создать ФС на новом винте, перенести данные обычным mv, установить загрузчик.

Оффтопик: а вот если бы использовался LVM, такого вопроса не возникло бы.

Почему? Каким образом LVM облегчит труды? :)

pvmove. Перенос тома на другой диск вживую

вот таким: http://www.centos.org/docs/5/html/Cluster_Logical_Volume_Manager/move_new_ex4...

Я переношу файловую систему rsync. потом остается записать загрузчик, но это мелочи.

Ага, в целом не плохо. Я хочу правда нечто другое - для backup я думаю особо это не поможет. И тут минус в том, что это move операция, тогда как dd и всё прочее, это всё же copy, т.е. на прежнем винте система остаётся.

rsync или cp + установка загрузчика, а лучше zfs.

И тут минус в том, что это move операция, тогда как dd и всё прочее, это всё же copy, т.е. на прежнем винте система остаётся.

Никто не мешает создать логический том ( LV ) того же размера и сделать dd. Плюс есть snapshot'ы

Так dd можно и без lvm сделать. Снепшоты это не о том, это о получение консистентной резервной копии на уровне файловой системы, т.е. через tar к примеру.

snapshot - это снимок состояния LV, на который можно откатиться.

Да ну уж... Кто-ж так делает? Обычно его создают на время пока получают backup на уровне фс, а после удаляют.

rsync не различает смонтированые каталоги. Поэтому же и cp тож не очень подходит. А дамп дампает блочное устройство а не каталожек.

А как борешься с монтированными разделами?

Примерно так:

tar czpf /backup.tgz --exclude=/backup.tgz --exclude=/proc/* --exclude=/media/* --exclude=/dev/* --exclude=/mnt/* --exclude=/sys/* --exclude=/tmp/* --exclude=/run/* --exclude=/lost+found /

чего только люди не придумают что бы только не пользоваться дампом :)

Вопрос был о лайв миграции. Мне некуда терабайтный тарбол положить.

Так можно направить вывод на сторонний ssh сервер.

Dump это хорошо, но я так понимаю, если у тебя винт терабайтный а там данных только на 100 гб. ты дампом получишь всё одно террабайт. А я получу менее 100гб. т.к. tar ещё сжимать умеет.

Более того, tar я могу восстановить и на раздел меньшего размера.

Вопрос был о лайв миграции. Мне некуда терабайтный тарбол положить.

Никто же не мешает отправить выдачу tar в pipe, а на другом конце pipe запустить другой tar:

tar cf - | (cd $WHATEVER; tar xvf -)

Да, пасиба, это я в курсе :)

Тогда я не понял про «некуда положить».

Чуваг, у меня уже жатый контент, так что терабай это терабайт :) И нет у меня стороннего ssh сервера... И да, dump эт не дд, ты точно так же можешь восстанавливать на меньшие разделы.

Там товарисч предложил миграцию через тарбол :)

Ааа, сори, да я dump c dd попутал... Покажи как dumpишь.

да как обычно

dump -0anu -f- / | restore -r -f-

ух ты :) Забавный косяк... Это не работает если таблица GPTшная... На ДОС разметке взлетело... Магия...

так пробовал?

cd /path && dump -f- | restore -rf-

да, с GPT какие-то проблемы помнится есть в этом плане.

rsync не различает смонтированые каталоги. Поэтому же и cp тож не очень подходит. А дамп дампает блочное устройство а не каталожек.

да неужели?

 -x, --one-file-system       don't cross filesystem boundaries

хм... да, искал по партишн а не по файлсистем...