пробовал последние 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)…
пробовал последние 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)…
виноват, проглядел
все что, я пытаюсь сделать, это понять, насколько xfs_copy быстрее dd
но хорошо…
1024Mb / 30 секунд ~ 34.1 Mbps
и эта скорость меньше чем 50Mbps в случае с dd
зато xfs_copy копирует только полезные данные
поправьте, если ошибаюсь: если места занятого файлами на хардах меньше чем ~ 67% (34.1 / 50) то xfs_copy эфективнее, если места занятого файлами больше то эффективней получается dd
для своп раздела
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 или типа того), но еще не пробовал
недавно был повод предпочесть именно такой метод всем остальным.
преимущества:
1) dd абсолютно пофигу, какие файловые и\или операционные системы переносить
2) если не полениться забить нулями свобоное место и использовать gzip\bzip можно сделать отосительнол компактный файл бекапа
3) делал по живому из-под запущеного линукса, после однократной проверки fsck — завелось благополучно на клонированном компе
но метод dd неидеален, из видимых недостатков:
1) необходимость периодически отправлять -USR1 чтобы видеть прогресс
2) нельзя получить инкрементальный бекап
3) при создание бекап файла нельзя скипнуть своп разделы и пейджфайлы, приходится их и свободное место забивать нулями
4) размер целевого диска должен быть не меньше исходного, независимо от реально занятого фалами места
пытаюсь выяснить — какой из вариантов когда целесообразней использовать
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 — раздел линукс
это был ответ на habrahabr.ru/blogs/linux/89617/#comment_2694523
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)…
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)…
все что, я пытаюсь сделать, это понять, насколько xfs_copy быстрее dd
но хорошо…
1024Mb / 30 секунд ~ 34.1 Mbps
и эта скорость меньше чем 50Mbps в случае с dd
зато xfs_copy копирует только полезные данные
поправьте, если ошибаюсь: если места занятого файлами на хардах меньше чем ~ 67% (34.1 / 50) то xfs_copy эфективнее, если места занятого файлами больше то эффективней получается dd
сколько полезных данных было скопировано за 30 секунд?
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 или типа того), но еще не пробовал
а вообще в википедии много </а>
преимущества:
1) dd абсолютно пофигу, какие файловые и\или операционные системы переносить
2) если не полениться забить нулями свобоное место и использовать gzip\bzip можно сделать отосительнол компактный файл бекапа
3) делал по живому из-под запущеного линукса, после однократной проверки fsck — завелось благополучно на клонированном компе
но метод dd неидеален, из видимых недостатков:
1) необходимость периодически отправлять -USR1 чтобы видеть прогресс
2) нельзя получить инкрементальный бекап
3) при создание бекап файла нельзя скипнуть своп разделы и пейджфайлы, приходится их и свободное место забивать нулями
4) размер целевого диска должен быть не меньше исходного, независимо от реально занятого фалами места
2 вопроса:
1) сколько длилось копирование с ключем -d?
2) что же выполнялось за 30 секунд без ключа -d, был ли это перенос только таблицы разделов?
откуда тогда берутся сообщения на хабре
например «кульный» запрет на обои для рабочего стола
CUDA — разработка nVidia
Хотя вам не понять наверное…