LINUX.ORG.RU
Форум — Admin  

Клонирование /dev/md0

 , ,


0

1

Всем привет,

Есть /dev/md0 на партициях /dev/sda3, /dev/sdb3. На нем висит /boot, все это на проде.

Можно ли считать вот это за бэкап:

dd if=/dev/sda3 of=/root/upgrade_backup/sda3.img
dd if=/dev/sdb3 of=/root/upgrade_backup/sdb3.img

То есть идея в том что если во время апгрейда что то пойдет не так, я загружусь в rescue и сделаю:

dd if=/mnt/root/upgrade_backup/sda3.img of=/dev/sda3
dd if=/mnt/root/upgrade_backup/sdb3.img of=/dev/sdb3

Или это полная дичь с моей стороны?

UPD: Поясню. Понятно что остальные партиции я тоже сохраняю.

★

Последнее исправление: alex07 (всего исправлений: 1)
← Centos 8, dnf reposync - локальное зеркало пакетов, что может быть проще?
Фильтруются все локальные порты →

Если md0 не смонитрован, то должно быть нормально. Ну можете его ReadOnly перевести.

mky ★★★★★
()

RAID-N

А какой там RAID? Если зеркальный, то достаточно один раздел скопирнуть.

И таки дваждую вопрос, почему бы не делать слепок всего /dev/md0? Любой LiveCD умеет собирать массивы.

Camel ★★★★★
()

dd - очень коварная утилита. Часто используется в критических ситуациях, когда сердце колотится, а пальцы дрожат. Советую всем сначала писать параметры, а потом, после визуальной проверки, дописывать dd перед параметрами. И я сам и коллеги запарывали блочные устройства. То вход с выходом перепутаешь, то номер раздела не допишешь.

anonymous
()
Ответ на: комментарий от anc

А что мешает скопировать содержимое /dev/md0 вместо использования dd ?

Я так понимаю, автор темы не хочет возиться с пересозданием массива, если что-то не так пойдет.

Serge10 ★★★★★
()
Ответ на: комментарий от Serge10

Интересно что в:

То есть идея в том что если во время апгрейда что то пойдет не так

предполагается «может пойти не так» до уровня развала массива? Думаю многое, этот массив /boot будет не один, и это будет самой последней «попоболью».
А вот с dd отдельно для каждого раздела, как писали выше, вариантов «наступить на грабли» больше. Да и просто больше ненужных действий выполнять. Но это имхо, я бы так не делал.

anc ★★★★★
()

То есть идея в том что если во время апгрейда что то пойдет не так, я загружусь в rescue и сделаю

Это должно сработать. Другой вопрос, что гораздо быстрее (и с точи зрения изготовления бекапа, и с точки зрения восстановления) ограничиться бекапом одного диска (если, конечно, raid зеркальный, впрочем, другой вариант и рассматривать глупо). Более того, можно просто на время апгрейда вывести один диск из рейда и использовать его в качестве бекапа, если что-то не так пойдет. Если же все пройдет штатно, то обнулить на резервном диске информацию о массиве 

mdadm --zero-superblock
или, если время позволяет, полностью очистить диск 
dd bs=10M if=/dev/null of=/dev/sd*
и вернуть диск в массив в качестве hotspare для восстановления избыточности.

Serge10 ★★★★★
()
Ответ на: комментарий от anc

Но это имхо, я бы так не делал.

Согласен. Гораздо быстрее скопировать нужную информацию на файловом уровне (особенно, если раздел не полностью забит). А пересоздать массив и установить загрузчик - минутное дело.

Serge10 ★★★★★
()
Ответ на: комментарий от mky

Если md0 не смонитрован, то должно быть нормально. Ну можете его ReadOnly перевести.

Ну да, понятно что сначала я его размонтирую.

alex07 ★
() автор топика
Ответ на: комментарий от anc

А что мешает скопировать содержимое /dev/md0 вместо использования dd ?

Это была первоначальная идея. Но т.к. это раздел /boot, симлинки там все вот это, решил сделать более топорно, но в то же время более просто.

alex07 ★
() автор топика
Ответ на: RAID-N от Camel

А какой там RAID? Если зеркальный, то достаточно один раздел скопирнуть.

RAID1.

И таки дваждую вопрос, почему бы не делать слепок всего /dev/md0? Любой LiveCD умеет собирать массивы.

Да скорее просто для фактора простоты и более топорного recovery. Мне надо подготовить скрипты чтобы это мог человек вообще далекий от линукса просто по методичке запустить.

alex07 ★
() автор топика
Ответ на: комментарий от slowpony

Таблицу разделов еще сохранить не забудь, и суперблок.

Этот бэкап рассчитан на то что при апгрейде стандартными средствами что то будет сломано. То есть не предполагается что кто то будет с разметкой диска играться. Суперблок, насколько я понимаю, сохраняется с помощью dd.

alex07 ★
() автор топика
Ответ на: комментарий от anonymous

dd - очень коварная утилита.

О да, этот урок я выучил на собственном тяжелом опыте.

alex07 ★
() автор топика
Ответ на: комментарий от Serge10

Я так понимаю, автор темы не хочет возиться с пересозданием массива, если что-то не так пойдет.

Ну да, я вот вчера ночью потестил. Самое простое как оказалось просто остановить массив с помощью mdadm --stop /dev/md0 и накатить dd на разделы, затем mdadm --scan --assemble.

Ну и проверку диска наверное неплохо было бы сделать после загрузки системы.

alex07 ★
() автор топика
Ответ на: комментарий от anc

предполагается «может пойти не так» до уровня развала массива?

Дело в что у меня Proxmox крутится с моей кастомной разметкой диска. Ситуация обстоит вот так:

root@sol-02:~# lsblk
NAME                            MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda                               8:0    0  7.3T  0 disk  
├─sda1                            8:1    0 1007K  0 part  
├─sda2                            8:2    0  512M  0 part  /boot/efi
├─sda3                            8:3    0  488M  0 part  
│ └─md0                           9:0    0  488M  0 raid1 /boot
└─sda4                            8:4    0  7.3T  0 part  
  └─md1                           9:1    0  7.3T  0 raid1 
    ├─pve-swap                  253:0    0    4G  0 lvm   [SWAP]
    ├─pve-root                  253:1    0   10G  0 lvm   /
    ├─pve-data_tmeta            253:2    0    1G  0 lvm   
    │ └─pve-data-tpool          253:4    0  6.3T  0 lvm   
    │   ├─pve-data              253:5    0  6.3T  0 lvm   
    │   ├─pve-vm--2100--disk--0 253:7    0  128G  0 lvm   
    │   └─pve-vm--2104--disk--0 253:8    0  128G  0 lvm   
    ├─pve-data_tdata            253:3    0  6.3T  0 lvm   
    │ └─pve-data-tpool          253:4    0  6.3T  0 lvm   
    │   ├─pve-data              253:5    0  6.3T  0 lvm   
    │   ├─pve-vm--2100--disk--0 253:7    0  128G  0 lvm   
    │   └─pve-vm--2104--disk--0 253:8    0  128G  0 lvm   
    └─pve-vz                    253:6    0    1T  0 lvm   /var/lib/vz
sdb                               8:16   0  7.3T  0 disk  
├─sdb1                            8:17   0 1007K  0 part  
├─sdb2                            8:18   0  512M  0 part  
├─sdb3                            8:19   0  488M  0 part  
│ └─md0                           9:0    0  488M  0 raid1 /boot
└─sdb4                            8:20   0  7.3T  0 part  
  └─md1                           9:1    0  7.3T  0 raid1 
    ├─pve-swap                  253:0    0    4G  0 lvm   [SWAP]
    ├─pve-root                  253:1    0   10G  0 lvm   /
    ├─pve-data_tmeta            253:2    0    1G  0 lvm   
    │ └─pve-data-tpool          253:4    0  6.3T  0 lvm   
    │   ├─pve-data              253:5    0  6.3T  0 lvm   
    │   ├─pve-vm--2100--disk--0 253:7    0  128G  0 lvm   
    │   └─pve-vm--2104--disk--0 253:8    0  128G  0 lvm   
    ├─pve-data_tdata            253:3    0  6.3T  0 lvm   
    │ └─pve-data-tpool          253:4    0  6.3T  0 lvm   
    │   ├─pve-data              253:5    0  6.3T  0 lvm   
    │   ├─pve-vm--2100--disk--0 253:7    0  128G  0 lvm   
    │   └─pve-vm--2104--disk--0 253:8    0  128G  0 lvm   
    └─pve-vz                    253:6    0    1T  0 lvm   /var/lib/vz

/dev/sd[ab]1 и /dev/sd[ab]2 вопросов не вызывают. Обычный dd. Вот тут кстати я вообще не уверен нужно ли их бэкапить. Ну раз хотим полное восстановление системы – пусть будет полное.

Про /dev/sd[ab]3 собственно вот эта тема.

Ну а /dev/pve-root это уже LVM snapshot со всеми вытекающими.

Больше вроде апгрейд ничего затронуть не должен.

UPD: Вот если интересно, картинка о том как разбит диск с моими пояснениями: https://ibb.co/6DtGmjN

alex07 ★
() автор топика
Последнее исправление: alex07 (всего исправлений: 1)
Ответ на: комментарий от Serge10

вернуть диск в массив в качестве hotspare для восстановления избыточности.

Как вариант. Но я своим работникам постоянно вбиваю в голову что RAID не является средством бэкапа ни при каких условиях. А тут получится что сам его так использую.

alex07 ★
() автор топика
Ответ на: комментарий от anc

ЯННП причем тут симлинки?

Я считаю что в данном случае работать на уровне блочного устройства как то проще. Хотя мое имхо конечно.

alex07 ★
() автор топика
Ответ на: комментарий от anonymous

udev кажется создает более осмысленные имена в dev/disk, так чуть проще с of=

anonymous
()
Ответ на: комментарий от alex07

Симлинк это такой же файл, что меняется? Это же не хардлинк который только на одном разделе будет работать.

anc ★★★★★
()
Ответ на: комментарий от alex07

Если полетит диск и потребуется замена от такого dd будет мало толку, точнее больше гемороя. Все статичные системы нормально копируются пофайлово с сохранением всех атрибутов man rsync. Естественно за исключением изменяемых данных. Тут отдельная песня. Но вроде вы не про то.

ЗЫ Ещё обратил внимание на смонтированный /boot/efi он у вас только на первом харде. Это так задумывалось?

anc ★★★★★
()
Ответ на: комментарий от anc

Если полетит диск и потребуется замена от такого dd будет мало толку, точнее больше гемороя.

Тут отдельная песня. Но вроде вы не про то.

Именно, вся эта затея предназначена для одного единственного сценария, запустить apt-get dist-upgrade и откатить систему в изначальное состояние из rescue консоли при ошибке.

Ещё обратил внимание на смонтированный /boot/efi он у вас только на первом харде. Это так задумывалось?

Нет, это последняя задача которая у меня осталась после дизайна кастомного layout для дисков proxmox.

Изначально (после стандартной установки) ситуация выглядит вот так (восстанавливаю вручную, сории за формат):

root@sol-02:~# lsblk
NAME                            MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda                               8:0    0  7.3T  0 disk  
├─sda1                            8:1    0 1007K  0 part  
├─sda2                            8:2    0  512M  0 part  /boot/efi
├─sda3                            8:3    0  488M  0 part  
    ├─pve-swap                  253:0    0    4G  0 lvm   [SWAP]
    ├─pve-root                  253:1    0   10G  0 lvm   /
    ├─pve-data_tmeta            253:2    0    1G  0 lvm   
    │ └─pve-data-tpool          253:4    0  6.3T  0 lvm   
    │   ├─pve-data              253:5    0  6.3T  0 lvm   
    ├─pve-data_tdata            253:3    0  6.3T  0 lvm   
    │ └─pve-data-tpool          253:4    0  6.3T  0 lvm   
    │   ├─pve-data              253:5    0  6.3T  0 lvm   
sdb                               8:16   0  7.3T  0 disk

Далее, вручную, я привожу layout к требуемому виду. Одна из операций это dd if=/dev/sda1 of=/dev/sdb1, ну и тоже самое с другим разделом. Насколько я помню из методички которую сам себе написал это требуется потому что в какой то момент у меня система не грузилась если не скопировать эти два раздела. Но так то я понимаю что эти разделы должны быть только на одном диске, вопрос в том с какого диска загрузится сервер, также похоже на то что один из этих разделов вообще не нужен, в зависимости от того грузимся ли с EFI или MBR.

Пока что не выяснял этот момент, буду благодарен если подскажете.

alex07 ★
() автор топика
Последнее исправление: alex07 (всего исправлений: 2)
Ответ на: комментарий от anc

А это зачем?

Ну как, если у Вас бекап на файловом уровне, то при восстановлении придется вручную разбивать диски на разделы, создавать массив, тома lvm (если используются), создавать файловые системы, и только после этого разворачивать бекап. А в случае бекапа в виде образов дисков ничего из вышеперечисленного делать не нужно.

Serge10 ★★★★★
()
Ответ на: комментарий от Serge10

Вроде речь шла только /boot. А если целиком про факап, то это стоит отдельного мануала, в части которого вы полностью правы.

anc ★★★★★
()
Ответ на: комментарий от alex07

Тому как сделать так, что бы при смерти одного диска из raid1 в софт рэйд грузилось с другого, написано много документации. gpt/mbr/efi выбирайте то что нужно вам. Гугл резиновый :)

anc ★★★★★
()
Ответ на: комментарий от anc

Тому как сделать так, что бы при смерти одного диска из raid1 в софт рэйд грузилось с другого, написано много документации.

Это понятно, просто эти партиции не формируют собой RAID. Грузиться из linux soft-raid, ни EFI, ни MBR, насколько мне известно, не умеют.

alex07 ★
() автор топика
Последнее исправление: alex07 (всего исправлений: 1)
Ответ на: комментарий от anc

А MBR тут причем?

Понятия не имею, я же говорю что еще не разбирался в вопросе. Суть в том что когда я делал методичку, если оставить эти разделы только на одном диске то система переставала грузиться, не исключено что я факапил где то в другом месте.

UPD: Но то что лично у меня, в любом случае сделано неправильно я не спорю. На это совершенно очевидно указывают такие детали как одинаковый UUID на /dev/sda2 и /dev/sdb2 к примеру.

alex07 ★
() автор топика
Последнее исправление: alex07 (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Centos 8, dnf reposync - локальное зеркало пакетов, что может быть проще?
Admin
Фильтруются все локальные порты →