Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 59
Просмотр перечня разделов на накопителе
cat /proc/partitions
fdisk -l
Неправильный способ
Вполне себе правильный, если вы уверены, что диск жив. А если еще учесть, что дисковые массивы на рабочих станциях или рабочие станции на виртуалках нынче не редкость, то тоже вполне рабочий способ
И про netcat не забывайте. Чаще всего сам по себе образ не нужен бывает.
Я ограничился вариантами команды ls для просмотра списка устройств потому, что мне хотелось лишний раз сделать акцент на том, что каждому разделу и устройству соответствует файл. Хотя cat /proc/partitions наверное и вправду надо добавить.
А вот по поводу уверенности что диск жив — я предпочитаю перестраховаться. Особенно если я этот диск в первый раз вижу.
Что касается netcat — это наверное уже тема для отдельной статьи.
А вот по поводу уверенности что диск жив — я предпочитаю перестраховаться. Особенно если я этот диск в первый раз вижу.
Что касается netcat — это наверное уже тема для отдельной статьи.
dd if=/dev/sda2 of=win_c.img bs=1000000
ставлю параметр bs чтобы ускорить копирование. Сейчас редко пользуюсь копированием диска из-за повального внедрения raid массивов. А раньше нужно было только для миграции с одной машины на другу, вариантов с дохлым диском за все время было один или два и там dd проходил нормально.
ставлю параметр bs чтобы ускорить копирование. Сейчас редко пользуюсь копированием диска из-за повального внедрения raid массивов. А раньше нужно было только для миграции с одной машины на другу, вариантов с дохлым диском за все время было один или два и там dd проходил нормально.
Есть мнение, что лучше делать bs кратным размеру сектора диска. Т.е. где-нибудь 4096*N. Или даже (2^19)*N, если учитывать размер блоков стирания в SSD.
Короче, пшиите bs=1048576 или bs=$((1024*1024)) и будет вам щасте (заодно с количеством ноликов сложнее промахнуться).
Короче, пшиите bs=1048576 или bs=$((1024*1024)) и будет вам щасте (заодно с количеством ноликов сложнее промахнуться).
Если диск заполнен не под завязку, размер образа можно уменьшить
rus-linux.net/lib.php?name=/MyLDP/consol/dd/dd-3.html#13
Пример 14. Создание резервного образа жесткого диска:
# dd if=/dev/hda | gzip > /mnt/hdb1/system_drive_backup.img.gz
Команда dd создает образ первого жесткого диска и по конвейеру (не забудьте про стандартный вывод по умолчанию) передает программе сжатия gzip. Сжатый образ затем помещается в файл system_drive_backup.img.gz, находящийся на другом диске (hdb1). Чтобы произвести обратное действие:
# gzip -dc /mnt/hdb1/system_drive_backup.img.gz | dd of=/dev/hda
Программа gzip распаковывает (опция -d) файл, передает результат на стандартный выход (опция -c), по конвейеру данные поступают программе dd, которая записывает выходной файл (устройство /dev/hda).
Незаметно мы рассмотрели почти все значения (фильтры) операнда conv. Тут и ману конец. Но сначала несколько правил относящихся к взаимодействию операндов.
Правило 1. Все операнды обрабатываются до начала чтения входных данных. В практическом смысле это значит, что можно писать операнды в любом порядке — результат будет один. Скажем команда:
# dd if=/dev/hda of=/dev/sda conv=noerror,sync bs=4k
равносильна команде
# dd bs=4k conv=noerror,sync if=/dev/hda of=/dev/sda
Правило 2. Если операнды (кроме conv=) указаны более одного раза, будет использоваться значение из последней пары операнд=значе
rus-linux.net/lib.php?name=/MyLDP/consol/dd/dd-3.html#13
Такой образ к сожалению не получится смонтировать и посмотреть что там внутри. Его придётся сначала разжать.
Можно использовать SquashFS — специальную файловую систему для хранения файлов в сжатом виде.
И еще лайфхак: «раздвинуть» или «сжать» раздел можно с помощью gparted, параллельно смотря в details какие команды она для этого использует.
тот же gparted умеет копировать разделы. Есть загрузочный линукс Puppy, там gparted есть в стандартной поставке. Примечателен малым размером и стартует практически на любом железе.
У gparted есть один фатальный недостаток. Он, о ужас, работает в графическом режиме :).
В случае десктопа графический режим совершенно не мешает, а наоборот. И потом… Его интерфейс работает в графическом режиме, а исполнение конкретных команд идет просто в терминальной сессии.
Опять же, подсмотрев в details gparted, можно выполнить последовательность операций на сервере в терминале ручками. Хотя это уже лишнее — не надо сервер лечить с помощью dd, только если там что-то действительно очень ценное. И то… Снять образ, и закинуть данные на новый, хорошо настроенный сервер.
Опять же, подсмотрев в details gparted, можно выполнить последовательность операций на сервере в терминале ручками. Хотя это уже лишнее — не надо сервер лечить с помощью dd, только если там что-то действительно очень ценное. И то… Снять образ, и закинуть данные на новый, хорошо настроенный сервер.
Можно его консольный backend юзануть, есть не лень
parted? Там, насколько я помню, после версии 2.4 убрали возможность копирования, изменения размера и вообще всего, что требовало знаний об устройстве файловой системы. Можно конечно пользоваться старым, но мне больше нравится использовать для ресайза утилиты, разработанные для конкретных файловых систем.
Комментарий удалён — я ошибся веткой.
Хорошо, что в матчасти разобрались, а так есть специализированный дистрибутив с возможностью создания загрузочной флешки — Clonezilla
Она еще и по сети все лить умеет, и файловые системы архивировать, не трогая неиспользуемые блоки (благодаря отдельному инструменту — partimage).
Последний раз когда я интересовался partimage — возможности монтировать созданные образы ещё не было. Может конечно сейчас что-то изменилось.
sourceforge.net/projects/partclone-utils/files/?source=navbar
извиняюсь, это для partclone
извиняюсь, это для partclone
Partimage (или partclone, не помню точно) — как раз та штука, благодаря которой Clonezilla до сих пор не умеет разворачивать образ на диск меньшего размера, хотя задача сама по себе весьма тривиальна. Разумеется я имею в виду случай, когда на физический диск размером 500ГБ установлена система, занимающая 5ГБ. Clonezilla хранит данные о геометрии диска сразу в нескольких местах, в том числе и в самом образе partclone, причём в обязательно порядке сверяется с его данными вне зависимости от выставленных флагов при восстановлении. Было дело провозился несколько часов, вручную исправляя геометрию в конфигах образа клонзиллы, и даже успешно восстановил диск С, но запоролся на диске Д. Может кто сталкивался с такой проблемой?
По материалам статьи. До того, как я начал работать с клонзиллой я делал образы связкой dd и rsync — через dd копировал MBR, монтировал сам раздел, копировал его rsync'ом, и сжимал в tar-архив. Образы получались равными или меньшими по размеру, чем исходные данные, плюс с ними было удобно работать как с обычными папками в том числе модифицировать. Именно таким образом я забэкапил диск восстановления Windows 8 с новенького ноутбука (т.к. изначально не планировалось оставлять Windows, но админское чутьё заставило сделать копию). Кому будет интересно можете прочитать тут.
По материалам статьи. До того, как я начал работать с клонзиллой я делал образы связкой dd и rsync — через dd копировал MBR, монтировал сам раздел, копировал его rsync'ом, и сжимал в tar-архив. Образы получались равными или меньшими по размеру, чем исходные данные, плюс с ними было удобно работать как с обычными папками в том числе модифицировать. Именно таким образом я забэкапил диск восстановления Windows 8 с новенького ноутбука (т.к. изначально не планировалось оставлять Windows, но админское чутьё заставило сделать копию). Кому будет интересно можете прочитать тут.
Префикс s в /dev/sda используется для raid, sata-винчестеров и флешек, а префикс h для IDE-винчестеров, например /dev/hda.
А вот с монтированием образа диска целиком всё не так простоВсе очень просто:
$ /sbin/fdisk -lu disk.img
You must set cylinders.
You can do this from the extra functions menu.
Disk disk.img: 0 MB, 0 bytes
255 heads, 63 sectors/track, 0 cylinders, total 0 sectors
Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
disk.imgp1 * 63 96389 48163+ 83 Linux
disk.imgp2 96390 2056319 979965 82 Linux swap / Solaris
disk.imgp3 2056320 78140159 38041920 5 Extended
disk.imgp5 2056383 3052349 497983+ 83 Linux
disk.imgp6 3052413 10859939 3903763+ 83 Linux
disk.imgp7 10860003 68372639 28756318+ 83 Linux
disk.imgp8 68372703 76180229 3903763+ 83 Linux
disk.imgp9 76180293 78140159 979933+ 83 Linux
mount -o loop,offset=$((10860003 * 512)) disk.img /mnt
Можно еще проще утилитой kpartx она читает список разделов файла disk.img и подключает в ввиде блочных устройств в папку /dev/mapper
Так и вправду можно. Но в тексте по ссылке как раз написано, что это всё очень муторно и неудобно. Настолько неудобно, что автор сделал утилиту, которая занимается тем же, что kpartx и последние версии losetup с аргументом --partscan.
Поэтому насчёт простоты вопрос спорный.
Поэтому насчёт простоты вопрос спорный.
Решения Акронис есть и под Linux =)
— уже написали
Clonezilla на вас обиделась.
Я как-то думал на тему opensource-решения, которое бы не сильно уступало Acronis.
Вышло вот что:
— Структуру разделов сохраняем через sfdisk для mbr или sgdisk для gpt
— Загрузчик для mbr сохраняем копированием в образ всего пространства с начала диска до начала первого раздела (заодно будет вторая копия таблицы разделов)
С ФС сложнее, нужно, чтобы было как в Acronis:
— образ поддерживает сжатие на лету, а не через gzip и пайп
— в образ попадают только используемые сектора
— образ можно смонтировать и вытащить из него отдельные файлы
Делаем так:
— через qemu-img создаем образ в формате qcow2 в режиме thin-provisioning с логическим размером во весь диск
— монтируем образ в блочное устройство
— форматируем его в btrfs
— монтируем btrfs, включаем на btrfs сжатие файлов
— утилитой partclone копируем разделы (она поддерживает даже vmfs)
— размонтируем все
Получаем контейнер, который можно смонтировать, а потом через imagemount смонтировать и образ partimage. Imagemount может монтировать раздел и на запись, но нужен еще и временный файл, в который она будет скидывать изменения.
И да, посмотреть разделы на диске можно через blkid / lsblk / fsarchiver probe
Вышло вот что:
— Структуру разделов сохраняем через sfdisk для mbr или sgdisk для gpt
— Загрузчик для mbr сохраняем копированием в образ всего пространства с начала диска до начала первого раздела (заодно будет вторая копия таблицы разделов)
С ФС сложнее, нужно, чтобы было как в Acronis:
— образ поддерживает сжатие на лету, а не через gzip и пайп
— в образ попадают только используемые сектора
— образ можно смонтировать и вытащить из него отдельные файлы
Делаем так:
— через qemu-img создаем образ в формате qcow2 в режиме thin-provisioning с логическим размером во весь диск
— монтируем образ в блочное устройство
— форматируем его в btrfs
— монтируем btrfs, включаем на btrfs сжатие файлов
— утилитой partclone копируем разделы (она поддерживает даже vmfs)
— размонтируем все
Получаем контейнер, который можно смонтировать, а потом через imagemount смонтировать и образ partimage. Imagemount может монтировать раздел и на запись, но нужен еще и временный файл, в который она будет скидывать изменения.
И да, посмотреть разделы на диске можно через blkid / lsblk / fsarchiver probe
Я тут уже признал один комментарий лучшим в топике, но ваш похоже первый кандидат на победителя в номинации «Самый полезный». Странно, что я заметил его так поздно — видимо пропустил.
Единственное, что мне не совсем понятно, зачем через qemu-img создавать образ в формате qcow2 в режиме thin-provisioning с логическим размером во весь диск. Подозреваю для того, чтобы в образ попадали только используемые сектора, но не уверен. Надо читать маны наверное.
В любом случае огромное спасибо!
Единственное, что мне не совсем понятно, зачем через qemu-img создавать образ в формате qcow2 в режиме thin-provisioning с логическим размером во весь диск. Подозреваю для того, чтобы в образ попадали только используемые сектора, но не уверен. Надо читать маны наверное.
В любом случае огромное спасибо!
Во-первый в большинстве случаев достаточно одной команды dd, для любителей графического интерфейса (меня, например), в той же Ubuntu есть дисковая утилита, через которую можно и образы снимать, и заливать их обратно.
Монтируются образы открытием файла в файловом менеджере.
Чаще всё на много проще, чем кажется.
Монтируются образы открытием файла в файловом менеджере.
Чаще всё на много проще, чем кажется.
Хм. Я линуксовые разделы бэкапил простым rsync -axv в каталог на другом диске. Плюсы — даже монтировать ничего не надо, чтобы посмотреть содержимое. Иногда нужно глянуть старый конфиг или еще что-то. Точно так же подменяется содержимое целевого диска резервной копией. Главное, чтобы MBR указывал на загрузочный раздел правильно.
Автор, вы смешали в одну кучу обычное копирование и копирование с поврежденных дисков.
Когда вам удобно, вы переходите с одного на другое.
Например, вы пишете про обычное копирование и предлагаете cp, cat.
Потом вы пишете про копирование с поврежденных дисков, и тут вы не рекомендуете dd, предлагая ddrescue.
Это очень разные задачи и для них нужно использовать свои инструменты.
При работе с поврежденным разделом cp и cat так же не рекомендуются, как и dd.
Да и acronis тут тоже может быть не уместен.
А при работе с рабочим разделом, как раз лучшие инструменты — это dd, parted/gparted, partclone/partimage/ntfsclone и тот же clonezilla.
У dd параметр bs позволяет хорошо поднять скорость копирования, особенно на быстрых дисках с большим кешем.
parted/gparted позволяет это делать в пару команд.
partclone/partimage/ntfsclone позволяет ужимать раздел без всяких sparse.
А clonzilla — отличный opensourse заменитель acronis в нише livecd.
В этом минус смешивания целей — неправильно оцениваются инструменты.
Теперь представьте, как вашу статью читают новички и запоминают использовать ddrescue на рабочих разделах.
А dd станет для них «неправильной» командой.
В остальном интересно, особенно способ ужать раздел через «cat /dev/zero >» и "--sparse".
Когда вам удобно, вы переходите с одного на другое.
Например, вы пишете про обычное копирование и предлагаете cp, cat.
Потом вы пишете про копирование с поврежденных дисков, и тут вы не рекомендуете dd, предлагая ddrescue.
Это очень разные задачи и для них нужно использовать свои инструменты.
При работе с поврежденным разделом cp и cat так же не рекомендуются, как и dd.
Да и acronis тут тоже может быть не уместен.
А при работе с рабочим разделом, как раз лучшие инструменты — это dd, parted/gparted, partclone/partimage/ntfsclone и тот же clonezilla.
У dd параметр bs позволяет хорошо поднять скорость копирования, особенно на быстрых дисках с большим кешем.
parted/gparted позволяет это делать в пару команд.
partclone/partimage/ntfsclone позволяет ужимать раздел без всяких sparse.
А clonzilla — отличный opensourse заменитель acronis в нише livecd.
В этом минус смешивания целей — неправильно оцениваются инструменты.
Теперь представьте, как вашу статью читают новички и запоминают использовать ddrescue на рабочих разделах.
А dd станет для них «неправильной» командой.
В остальном интересно, особенно способ ужать раздел через «cat /dev/zero >» и "--sparse".
Дело в том, что я действительно считаю dd неправильной командой которую можно использовать только если хорошо знаешь, что делаешь. Это как с оператором goto. Дийкстра предложил считать его вредным давным давно и ныне с этим мало кто спорит. Тем не менее, goto широко используется в узких кругах с исключительно мирными целями.
Если диск хороший, то можно использовать cp, cat или dd или что-то ещё. И, за исключением отдельных случаев, ddrescue тут ничем не хуже любых других вариантов, включая dd. Важно помнить, что устройствам и разделам соответствуют файлы, а дальше дело пойдёт само :). Я вот нередко использую pv просто потому, что мне нравится ползунок.
Но что если насчёт диска полной уверенности нет? Тогда cp существенно лучше, чем dd без аргумента noerror, так как dd потенциально может испортить диск. А с аргументом noerror dd лучше чем ddrescue только тем, что в состоянии отправить результаты работы в пайп. Если вы готовы ради этой возможности отказаться от автоматической вычистки сбойных мест, то наверное у вас есть на то веские причины и вы чётко знаете, что делаете. То есть вы видимо не новичок.
А вот новичкам типа меня думаю имеет смысл знать о существовании dd но прибегать к этой программе исключительно как к последнему средству. В том числе из-за нестандартного способа передачи аргументов. ddrescue, с моей точки зрения, даёт дополнительные гарантии безопасности не привнося дискомфорта.
Ну и коротко об остальном.
parted c версии 3.0 по моему отказался от всего, что не связано непосредственно с разметкой дисков. Я считаю оно и к лучшему.
Про partclone, ntfsclone и clonezilla я упомянул в послесловии. Не сказать про них вообще было невозможно, но подробный рассказ привнёс бы изрядный кусок хаоса в статью, которая и так, как вы справедливо заметили, смешивает обычное копирование и копирование с повреждённых дисков. Кроме того хотелось описать какой-то дубовый способ, который будет работать вообще везде. В том числе поэтому в статье подробно разобран вариант с использованием losetup, хотя kpartx в общем-то решает проблему.
Если диск хороший, то можно использовать cp, cat или dd или что-то ещё. И, за исключением отдельных случаев, ddrescue тут ничем не хуже любых других вариантов, включая dd. Важно помнить, что устройствам и разделам соответствуют файлы, а дальше дело пойдёт само :). Я вот нередко использую pv просто потому, что мне нравится ползунок.
Но что если насчёт диска полной уверенности нет? Тогда cp существенно лучше, чем dd без аргумента noerror, так как dd потенциально может испортить диск. А с аргументом noerror dd лучше чем ddrescue только тем, что в состоянии отправить результаты работы в пайп. Если вы готовы ради этой возможности отказаться от автоматической вычистки сбойных мест, то наверное у вас есть на то веские причины и вы чётко знаете, что делаете. То есть вы видимо не новичок.
А вот новичкам типа меня думаю имеет смысл знать о существовании dd но прибегать к этой программе исключительно как к последнему средству. В том числе из-за нестандартного способа передачи аргументов. ddrescue, с моей точки зрения, даёт дополнительные гарантии безопасности не привнося дискомфорта.
Ну и коротко об остальном.
parted c версии 3.0 по моему отказался от всего, что не связано непосредственно с разметкой дисков. Я считаю оно и к лучшему.
Про partclone, ntfsclone и clonezilla я упомянул в послесловии. Не сказать про них вообще было невозможно, но подробный рассказ привнёс бы изрядный кусок хаоса в статью, которая и так, как вы справедливо заметили, смешивает обычное копирование и копирование с повреждённых дисков. Кроме того хотелось описать какой-то дубовый способ, который будет работать вообще везде. В том числе поэтому в статье подробно разобран вариант с использованием losetup, хотя kpartx в общем-то решает проблему.
Честно говоря, из ваших слов непонятно, в чем неправильность dd при работе с рабочим диском.
Ну и чем cat и cp лучше при битом разделе? Тем, что выдают ошибку?
Если у вас есть подозрения насчет диска, диск можно проверить на ошибки перед копированием.
И по результатам проверки, станет ясно, какая перед вами стоит задача — копирование, или спасение.
А так вы функции детектирования переносите на cat и cp (которые для этого не предназначены и могут обмануть).
Имхо, у пользователей типичный случай — у пользователя есть два рабочих жестких диска и нужно перекинуть раздел.
Например, пользователь купил более ёмкий диск и ему нужно перенести раздел со старого диска на новый.
Скорее всего на старом диске ошибок нет, диск рабочий и просто заменяется на новый.
В таком типичном случае dd отлично справляется со своей ролью, развивая бОльшую скорость, чем cp.
Ну а *clone ещё быстрее, по понятным причинам.
Если на диске идут такие ошибки, что чтение будет спотыкаться, пользователь об этом узнает ещё до копирования.
Щелкающий диск, тормоза в работе системы и т.д.
И выберет другие инструменты.
Вообще файлы устройств — это не обычные файлы, это блочные файлы.
Например, вот краткое описание типов файлов: www.linuxcenter.ru/lib/books/kostromin/gl_04_04.phtml
При работе с ними, я бы не рекомендовал использовать cp.
Вот тут cp можно назвать неправильной командой — некоторые файлы она просто не сможет скопировать.
Тут уместнее cat, или dd (как продвинутый вариант cat).
P.S.
Я тут подумал, возможно в вашей практике вам чаще приходится работать с битыми дисками?
Тогда ваша точка зрения станет более понятна.
Ну и чем cat и cp лучше при битом разделе? Тем, что выдают ошибку?
Если у вас есть подозрения насчет диска, диск можно проверить на ошибки перед копированием.
И по результатам проверки, станет ясно, какая перед вами стоит задача — копирование, или спасение.
А так вы функции детектирования переносите на cat и cp (которые для этого не предназначены и могут обмануть).
Имхо, у пользователей типичный случай — у пользователя есть два рабочих жестких диска и нужно перекинуть раздел.
Например, пользователь купил более ёмкий диск и ему нужно перенести раздел со старого диска на новый.
Скорее всего на старом диске ошибок нет, диск рабочий и просто заменяется на новый.
В таком типичном случае dd отлично справляется со своей ролью, развивая бОльшую скорость, чем cp.
Ну а *clone ещё быстрее, по понятным причинам.
Если на диске идут такие ошибки, что чтение будет спотыкаться, пользователь об этом узнает ещё до копирования.
Щелкающий диск, тормоза в работе системы и т.д.
И выберет другие инструменты.
Вообще файлы устройств — это не обычные файлы, это блочные файлы.
Например, вот краткое описание типов файлов: www.linuxcenter.ru/lib/books/kostromin/gl_04_04.phtml
При работе с ними, я бы не рекомендовал использовать cp.
Вот тут cp можно назвать неправильной командой — некоторые файлы она просто не сможет скопировать.
Тут уместнее cat, или dd (как продвинутый вариант cat).
P.S.
Я тут подумал, возможно в вашей практике вам чаще приходится работать с битыми дисками?
Тогда ваша точка зрения станет более понятна.
Да, я считаю, что в случае с разделом, у которого чисто теоретически могут быть проблемы, cp лучше dd тем, что просто прервёт работу, а не ушатает диск вусмерть. Если с разделом по какой-то причине не справилась cp то видимо придётся иcпользовать ddrescue. Поэтому лучше начать сразу с неё, так как накладные издержки вообще отсутствуют.
У меня в основном получается что типичный случай это когда я диск раньше никогда не видел. И можно конечно его проверить, но наверное он нормальный. Однако на случай, если там есть незначительные проблемы, я предпочитаю перестраховаться. И, как показывает практика, не зря. Несколько раз нарывался на проблемные устройства.
Насчёт скорости интересный вопрос. Думаю, что если задать dd неправильный размер блока, можно эту скорость сильно снизить. cp неправильный размер блока задать вроде бы нельзя. Но допустим dd настроена идеально. Любопытно каким будет выигрыш в скорости. Я об этом как-то не думал.
И хочется немного отвлечься от cp vs dd. Скажите, вы видите какие-нибудь причины использовать не ddrescue, а dd? Я придумал только большую распространённость последней, а также возможность направить результаты её работы в пайп.
У меня в основном получается что типичный случай это когда я диск раньше никогда не видел. И можно конечно его проверить, но наверное он нормальный. Однако на случай, если там есть незначительные проблемы, я предпочитаю перестраховаться. И, как показывает практика, не зря. Несколько раз нарывался на проблемные устройства.
Насчёт скорости интересный вопрос. Думаю, что если задать dd неправильный размер блока, можно эту скорость сильно снизить. cp неправильный размер блока задать вроде бы нельзя. Но допустим dd настроена идеально. Любопытно каким будет выигрыш в скорости. Я об этом как-то не думал.
И хочется немного отвлечься от cp vs dd. Скажите, вы видите какие-нибудь причины использовать не ddrescue, а dd? Я придумал только большую распространённость последней, а также возможность направить результаты её работы в пайп.
У меня практически не было ситуаций, когда нужно слить данные с битого диска, поэтому ddrescue я пользовался 1-2 раза.
Современные винты, даже десктопные, вроде бы редко обзаводятся битыми областями, если их не ронять.
У серверных винтов другая проблема — умирает контроллер и уже никакие данные не считать.
Хотя на серверных винтах обычно рейд, поэтому и данные снимать нужды почти не возникает.
Чаще образы нужно копировать при работе с виртуалками.
А там обычные операции — в стиле «dd | gzip | ssh 'cat — > file'».
Когда у рейд контроллера большая память dd bs=1g работает куда быстрее, чем без bs.
Современные винты, даже десктопные, вроде бы редко обзаводятся битыми областями, если их не ронять.
У серверных винтов другая проблема — умирает контроллер и уже никакие данные не считать.
Хотя на серверных винтах обычно рейд, поэтому и данные снимать нужды почти не возникает.
Чаще образы нужно копировать при работе с виртуалками.
А там обычные операции — в стиле «dd | gzip | ssh 'cat — > file'».
Когда у рейд контроллера большая память dd bs=1g работает куда быстрее, чем без bs.
устаревший оригинал GNU ddrescue это вы в сторону dd_rescue ( Latest version is 1.46 (2014-08-09) )киваете? а ну ка перекиньте мне гну-той версией образ в рилтайме по сети и с сжатием?)
Ваш комментарий официально признан мной лучшим комментарием в этом топике!
Я кивал именно в сторону dd_rescue. И я был совершенно не в курсе. Эта новость для меня прямо как гром с ясного неба. В общем да, неловко как-то получилось.
В своё оправдание хочу сказать, что судя по чейнджлогу, в развитии программы была длинная пауза с 2006 по 2010 или около того.
Огромное спасибо за информацию! Я изучу вопрос подробнее и, если dd_rescue действительно делает то, о чём вы говорите без каких нибудь неприятных побочных эффектов, то я добавлю упоминание об этом в статью и напишу отдельную публикацию, посвященную отличиям актуальной гнутой версии от актуальной версии оригинала.
Я кивал именно в сторону dd_rescue. И я был совершенно не в курсе. Эта новость для меня прямо как гром с ясного неба. В общем да, неловко как-то получилось.
В своё оправдание хочу сказать, что судя по чейнджлогу, в развитии программы была длинная пауза с 2006 по 2010 или около того.
Огромное спасибо за информацию! Я изучу вопрос подробнее и, если dd_rescue действительно делает то, о чём вы говорите без каких нибудь неприятных побочных эффектов, то я добавлю упоминание об этом в статью и напишу отдельную публикацию, посвященную отличиям актуальной гнутой версии от актуальной версии оригинала.
Весь вопрос в том, для чего именно нужна копия диска.
Если для того, чтобы вытаскивать оттуда файлы — то клон строго говоря не нужен. Достаточно сделать из диска squashfs — и плюшки вроде сжатия и возможности произвольного доступа будут налицо. К тому же (достаточно часто) squashfs окажется быстрее, чем клонирование (чистый io записи «копии» меньше).
Физическое клонирование может быть нужно, например, в случае потери данных — чтобы потом не спеша выковыривать их из секторов образа.
А вот sparse — это must have для ssd-дисков (особенно для разворачивания клона обратно на диск). Потому что в противном случае нулевые секторы, записанные на диск — это всё же данные, а не «незанятое место». Соответственно, они будут занимать ячейки (меньше пространства для вейеринга); они контроллер будет честно их считывать и выдавать в шину, вместо того, чтобы пускать туда дефолтный поток нулей, зная, что ячейки не заняты.
Если для того, чтобы вытаскивать оттуда файлы — то клон строго говоря не нужен. Достаточно сделать из диска squashfs — и плюшки вроде сжатия и возможности произвольного доступа будут налицо. К тому же (достаточно часто) squashfs окажется быстрее, чем клонирование (чистый io записи «копии» меньше).
Физическое клонирование может быть нужно, например, в случае потери данных — чтобы потом не спеша выковыривать их из секторов образа.
А вот sparse — это must have для ssd-дисков (особенно для разворачивания клона обратно на диск). Потому что в противном случае нулевые секторы, записанные на диск — это всё же данные, а не «незанятое место». Соответственно, они будут занимать ячейки (меньше пространства для вейеринга); они контроллер будет честно их считывать и выдавать в шину, вместо того, чтобы пускать туда дефолтный поток нулей, зная, что ячейки не заняты.
Для тех, кто перешел на рейды с lvm, ls /dev/sd* не поможет в выяснении конфигурации конечных разделов. Мне совсем недавно открыли команду lsblk — рекомендую.
Совпадение или вдохновение? :)
Не плохая сатья, но уже не актуальная, с появлением fsarchiver. Работает очень быстро, сильно сжимает и самое главное что можно снимать образа с используемых разделов.
Пример использования:
fsarchiver -e '*.log* swap /var/lib/postgresql/9.1/main/base/4339358/* /usr/src/*'
-v -a -A savefs backup.fsa
/dev/md0
/dev/mapper/vgroot-lvroot
/dev/mapper/vghome-lvhome
Создаст архив файловых систем backup.fsa с разделами md0, vgroot-lvroot, vghome-lvhome и исключит '*.log* swap /var/lib/postgresql/9.1/main/base/4339358/* /usr/src/*'
Так можно посмотреть что в архиве
fsarchiver archinfo backup.fsa
Так восстанавливаем:
fsarchiver restfs backup.fsa id=0,dest=/dev/sda1
Извлекаем образ с номером -0 (/dev/md0) на устройство /dev/sda1
Восстанавливать можно на раздел с меньшим объемом, но места должно хватать для распаковки.
ПС с lvm образа работающих разделов можно снимать при помощи snapshot-ов.
Пример использования:
fsarchiver -e '*.log* swap /var/lib/postgresql/9.1/main/base/4339358/* /usr/src/*'
-v -a -A savefs backup.fsa
/dev/md0
/dev/mapper/vgroot-lvroot
/dev/mapper/vghome-lvhome
Создаст архив файловых систем backup.fsa с разделами md0, vgroot-lvroot, vghome-lvhome и исключит '*.log* swap /var/lib/postgresql/9.1/main/base/4339358/* /usr/src/*'
Так можно посмотреть что в архиве
fsarchiver archinfo backup.fsa
Так восстанавливаем:
fsarchiver restfs backup.fsa id=0,dest=/dev/sda1
Извлекаем образ с номером -0 (/dev/md0) на устройство /dev/sda1
Восстанавливать можно на раздел с меньшим объемом, но места должно хватать для распаковки.
ПС с lvm образа работающих разделов можно снимать при помощи snapshot-ов.
Есть удобный скрипт, который позволяет сразу же ремаппить сбойные сектора (диска, откуда читаем) контроллером винта (во всяком случае, если место под ремап в служебной области осталось). Потому что практика подсказывает, что, если сектор не прочитался с первого раза — шансы его прочитать без засовывания винта в холодильник почти нулевые.
Вот он: https://techoverflow.net/blog/2015/01/07/fixing-bad-blocks-on-hdds-using-fixhdd.py/
Зеркало: https://github.com/unxed/fixhdd
Запускать так:
При этом скрипт будет висеть в памяти и раз в 5 секунд сканировать системный лог на предмет сообщений об ошибках чтения, извлекать оттуда LBA-адреса сбойных секторов и писать в эти сектора нули, чтобы контроллер винта мог смело заремаппить сектор (при чтении-с-ошибками контроллер этого сделать не может, так как это — гарантированная потеря данных, которые, возможно, всё же есть какой-то маленький шанс считать).
Опыт показывает, что в случае сбойных винтов этот способ существенно повышает вероятность того, что работа ddrescue вообще когда-нибудь завершится.
Вот он: https://techoverflow.net/blog/2015/01/07/fixing-bad-blocks-on-hdds-using-fixhdd.py/
Зеркало: https://github.com/unxed/fixhdd
Запускать так:
sudo fixhdd.py --loop /dev/sdaгде /dev/sda — (потенциально) сбойный диск, с которого читаем.
При этом скрипт будет висеть в памяти и раз в 5 секунд сканировать системный лог на предмет сообщений об ошибках чтения, извлекать оттуда LBA-адреса сбойных секторов и писать в эти сектора нули, чтобы контроллер винта мог смело заремаппить сектор (при чтении-с-ошибками контроллер этого сделать не может, так как это — гарантированная потеря данных, которые, возможно, всё же есть какой-то маленький шанс считать).
Опыт показывает, что в случае сбойных винтов этот способ существенно повышает вероятность того, что работа ddrescue вообще когда-нибудь завершится.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Копирование разделов жёсткого диска средствами GNU/Linux: как обойтись загрузочной флешкой там, где раньше нужен был Акронис