pharao 1 апр 2010 в 12:25

Клонирование системного диска штатными средствами Linux за 30 секунд

2 мин

45K

Настройка Linux *

+36

Комментарии 49

bondbig 1 апр 2010 в 12:35

я использую по старинке 'dd if=/dev/blabla1 of=/dev/blabla2'

tony 1 апр 2010 в 13:20

метод прекрасен, но, мягко выражаесь, не очень быстр.

bondbig 1 апр 2010 в 13:28

может быть. Давно не приходилось применять. Но помню, что скорость упиралась в физическую возможность самого медленного из дисков.

tony 1 апр 2010 в 13:48

не только, ещё имеет значение параметр bs = blocksize, если его не указывать, то 10Г будут копироваться целую вечность.

bondbig 1 апр 2010 в 13:57

Ну да, я помню выставлял от 4 до 32K, по ситуации

ludenus 1 апр 2010 в 16:26

при указанном bs=4k старый диск 80Gb копировался 28 минут

bondbig 1 апр 2010 в 17:03

~50 Мбайт/c, неплохо, на самом деле. Видимо это был предел вашего диска, или нужно было попробовать еще увеличить bs.

egorF 2 апр 2010 в 16:29

bs=1M решает.

tony 2 апр 2010 в 18:20

bs=8m получше будет, как то раз тестил ради интереса скорости;)

ludenus 1 апр 2010 в 16:40

недавно был повод предпочесть именно такой метод всем остальным.
преимущества:
1) dd абсолютно пофигу, какие файловые и\или операционные системы переносить
2) если не полениться забить нулями свобоное место и использовать gzip\bzip можно сделать отосительнол компактный файл бекапа
3) делал по живому из-под запущеного линукса, после однократной проверки fsck — завелось благополучно на клонированном компе

но метод dd неидеален, из видимых недостатков:
1) необходимость периодически отправлять -USR1 чтобы видеть прогресс
2) нельзя получить инкрементальный бекап
3) при создание бекап файла нельзя скипнуть своп разделы и пейджфайлы, приходится их и свободное место забивать нулями
4) размер целевого диска должен быть не меньше исходного, независимо от реально занятого фалами места

g1itch 1 апр 2010 в 19:40

Именно по живому лучше использовать всяческие *dump — там это предусмотрено и перед клонированием делается мгновенная копия (на xfs и ufs точно). + за счет знания особенностей ФС они быстрее dd.

НЛО прилетело и опубликовало эту надпись здесь

ludenus 2 апр 2010 в 11:02

для своп раздела
dd if=/dev/zero of=/dev/sdaXX bs=4k
где sdaXX — линуксовый своп раздел

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

dd if=/dev/zero of=/mnt/windows/zeroes.tmp bs=4k
потом удаляешь файл

то же самое со свободным местом делать можно на линуксовых ext разделах

единственное неудобство в случае с своп разделом — в том, что после забивания нулями полностью мы забиваем нулями в том числе и ту информацию, которая сообщает линуксу, что это своп раздел (uuid затирается) поэтому мне его пришлось отформатировать заново gparted-ом и прописывать вручную uuid своп раздела в склонированном fstab-е. Думаю, что этого неудобства можно избежать, не перезаписывая первые 512 байт своп раздела при забивании его нулями (skip=512 или типа того), но еще не пробовал

а вообще в википедии много </а>

НЛО прилетело и опубликовало эту надпись здесь

ludenus 2 апр 2010 в 14:24

а в чем разница?

mount -t ext3 /mnt/mountpoint /dev/sdaXX

dd if=/dev/zero of=/mnt/mountpoint/zeroes.tmp bs=4k

rm -f /mnt/mountpoint/zeroes.tmp

где sdaXX — раздел линукс

stasikos 7 апр 2010 в 20:10

mkswap /dev/sdчототам?

tamerlan311 2 апр 2010 в 18:33

>> необходимость периодически отправлять -USR1 чтобы видеть прогресс

dd_rescue Решает!

akral 2 апр 2010 в 20:26

1) необходимость периодически отправлять -USR1 чтобы видеть прогресс

dd if=/dev/sda | pv | dd of=/dev/sdb

Vile55 1 апр 2010 в 16:52

Иногда лучше использовать dd_rescue…

ludenus 1 апр 2010 в 16:30

— копируем xfs_copy с ключом -d (делаем полное клонирование, включая UUID)

2 вопроса:
1) сколько длилось копирование с ключем -d?
2) что же выполнялось за 30 секунд без ключа -d, был ли это перенос только таблицы разделов?

pharao 1 апр 2010 в 18:15

-d не влияет на скорость копирования.
30 секунд выполнялось все, а именно от sfdisk до grub.

ludenus 2 апр 2010 в 11:06

2. xfs_copy копирует полезные данные

сколько полезных данных было скопировано за 30 секунд?

pharao 2 апр 2010 в 11:11

в топике написано * разделы /dev/sda[1,5-7] (общая полезная информация ~1GB)

ludenus 2 апр 2010 в 12:33

виноват, проглядел
все что, я пытаюсь сделать, это понять, насколько xfs_copy быстрее dd

но хорошо…
1024Mb / 30 секунд ~ 34.1 Mbps
и эта скорость меньше чем 50Mbps в случае с dd
зато xfs_copy копирует только полезные данные

поправьте, если ошибаюсь: если места занятого файлами на хардах меньше чем ~ 67% (34.1 / 50) то xfs_copy эфективнее, если места занятого файлами больше то эффективней получается dd

pharao 2 апр 2010 в 13:36

Согласитесь что xfs_copy и dd можно сравнивать на одном и том же винчестере/системе.
Возможно, крейсерская скорость этого винчестера вовсе не 50Mbps.
Логически рассуждая, при одинаковой пропускной способности винчестера,
программа, которая копирует не все подряд, должна работать быстрее.

ludenus 2 апр 2010 в 14:28

соглашусь, сравнивать можно

пытаюсь выяснить — какой из вариантов когда целесообразней использовать

xdemon 1 апр 2010 в 16:44

я бы предпочел generic-way — rsync archive. Не везде же xfs…

Throwable 1 апр 2010 в 16:54

Зачастую новый диск по объему больше, поэтому таблицы разделов не совпадают. Поддерживает ли XFS увеличение после копирования на бОльший раздел?

alex_www 1 апр 2010 в 17:08

xfs_growfs увеличивает смоттированую XFS

НЛО прилетело и опубликовало эту надпись здесь

mvgolubev 2 апр 2010 в 11:15

Эти вишнёвые пимпочки на различных компонентах серверов HP означают, что данный девайс можно выдёргивать и втыкать на горячую. Видишь вишнёвую защёлку на SAS-диске, на блоке питания, на корпусном вентиляторе и т.д. — знай, hotswap supported!

НЛО прилетело и опубликовало эту надпись здесь

mvgolubev 2 апр 2010 в 11:24

По наличию защёлки понятно, что можно вытаскивать.
Но по её цвету понятно, что это можно делать прямо при работающем сервере.
И на картинке вытаскивают не «блок с диском», а это сам SAS-диск у HP-серверов такой с защёлкой.

НЛО прилетело и опубликовало эту надпись здесь

non7top 1 апр 2010 в 17:31

tar -c и tar -x хорошо себя зарекомендовало потому что абсолютно универсально.нужно только создать и замонтировать разделы. мы делали v2p, p2v, v2v и p2p по одной и той же схеме.

Paskal 1 апр 2010 в 17:46

Мне одному всё приведённое (кроме dd в какой-то мере) кажется нетривиальным и не сильно повторяемым способом клонирования?
Гуру, существуют ли 2-click приложения для этого дела?

bondbig 1 апр 2010 в 17:53

откройте для себя Acronis TrueImage. Но это не СПО.

d1m 1 апр 2010 в 22:35

partimage

ludenus 2 апр 2010 в 12:42

пробовал последние 2 версии (одну в составе systemrescuecd, другую из репозитория 12 федоры), пришел к выводу, что partimage ненадежен
3 из 5 бекапов виндовых ntfs разделов не накатываются
все с разными ошибками при попытке восстановиться из

кстати об одной из частых ошибок упоминается на sourceforge странице проекта
sourceforge.net/projects/partimage/
...failed to restore the partition with the «Can't Read Block 0 from Image» error (many users have the same problem — just google it)…

d1m 3 апр 2010 в 10:46

Я чаще всего делаю снапшот lvm-ом, монтирую, делаю тарбол и его уношу куда-нибудь. Но да, решение не самое лучшее.

nojoke 1 апр 2010 в 18:03

Ну не знаю. Я просто диск из Raid-1 дергаю, и получается копия. :)
Даунтайм у сервера — 0. :)

pgrishin 1 апр 2010 в 18:57

с поврежденной файловой системой

bondbig 1 апр 2010 в 19:11

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

pgrishin 1 апр 2010 в 19:49

в этом и смысл коммента nojoke, да и ребилд либо короткий напрягающий, либо длительный не напрягающий )

файловая система повредится с высокой долей вероятности, и хорошо бы это была не, например, БД.