pharao Apr 1 2010 at 16:25

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

2 min

42K

Configuring Linux*

+36

Comments 49

bondbig Apr 1 2010 at 16:35

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

+27

tony Apr 1 2010 at 17:20

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

bondbig Apr 1 2010 at 17:28

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

tony Apr 1 2010 at 17:48

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

bondbig Apr 1 2010 at 17:57

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

ludenus Apr 1 2010 at 20:26

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

bondbig Apr 1 2010 at 21:03

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

egorF Apr 2 2010 at 20:29

bs=1M решает.

tony Apr 2 2010 at 22:20

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

ludenus Apr 1 2010 at 20:40

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

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

g1itch Apr 1 2010 at 23:40

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

UFO just landed and posted this here

ludenus Apr 2 2010 at 15: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 или типа того), но еще не пробовал

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

UFO just landed and posted this here

ludenus Apr 2 2010 at 18: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 Apr 8 2010 at 00:10

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

tamerlan311 Apr 2 2010 at 22:33

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

dd_rescue Решает!

akral Apr 3 2010 at 00:26

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

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

Vile55 Apr 1 2010 at 20:52

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

ludenus Apr 1 2010 at 20:30

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

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

pharao Apr 1 2010 at 22:15

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

ludenus Apr 2 2010 at 15:06

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

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

-1

pharao Apr 2 2010 at 15:11

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

ludenus Apr 2 2010 at 16:33

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

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

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

pharao Apr 2 2010 at 17:36

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

ludenus Apr 2 2010 at 18:28

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

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

xdemon Apr 1 2010 at 20:44

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

Throwable Apr 1 2010 at 20:54

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

alex_www Apr 1 2010 at 21:08

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

UFO just landed and posted this here

mvgolubev Apr 2 2010 at 15:15

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

UFO just landed and posted this here

mvgolubev Apr 2 2010 at 15:24

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

UFO just landed and posted this here

non7top Apr 1 2010 at 21:31

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

Paskal Apr 1 2010 at 21:46

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

-1

bondbig Apr 1 2010 at 21:53

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

d1m Apr 2 2010 at 02:35

partimage

ludenus Apr 2 2010 at 16: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 Apr 3 2010 at 14:46

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

nojoke Apr 1 2010 at 22:03

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

pgrishin Apr 1 2010 at 22:57

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

bondbig Apr 1 2010 at 23:11

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

pgrishin Apr 1 2010 at 23:49

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

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