LINUX.ORG.RU

проблема бэкапа RAID на сервере Fujitsu-Siemens

 , ,


0

2

Дано:

1. Сервер Fujitsu Siemens PRIMERGY RX300 S3.

2. Относительно недавно перепрошивали. Проблем не было. Должны стоять последние или почти последние версии BIOS и прошивок.

3. Дисковая подсистема: изначально RAID-1 SAS 15k 73 GB x 2.

3.1. К слову, дисковый контроллер бортовых HDD такой

% lspci -nn | grep RAID
02:0e.0 RAID bus controller [0104]: LSI Logic / Symbios Logic MegaRAID SAS 1068

4. В процессе эксплуатации один из дисков вылетел и был без проблем заменён на SAS 15k 146 GB, ёмкость RAID-массива при этом не изменилась. Проблем при эксплуатации данной конфигурации также не было.

5. Потом на диске сервера начало кончаться место, и было принято решение о расширении дискового хозяйства до RAID-1 SAS 15k 146 GB x 2.

6. Как обычно делается на настольных машинах, для переезда на новый RAID для BACKUP/RESTORE был взят инструмент SystemRescueCd-4.4.0-x86 (т.е. его последняя на данный момент версия). Загрузка с этого диска была по пункту 2, т.е. docache.

6.1. Ядро такое

% uname -a
Linux sysresccd 3.10.55-std440-amd64 #2 SMP Sun Oct 5 14:08:51 UTC 2014 x86_64 Intel(R) Xeon(R) CPU E5335 @ 2.00GHz GenuineIntel GNU/Linux

7. Как был сделан BACKUP: на внешний USB HDD:

...
% cd /mnt/transcend/servname-20141101-001
% ddrescue /dev/sda sda.img sda.img.log ; \
> md5sum -b /dev/sda >dev-sda.md5 ; \
> md5sum -b sda.img >sda.img.md5 ; \
> cat *.md5

8. После того, как всё сделалось, выяснилось, что

6d4b2214002432558026240bd3e089a5 */dev/sda
4cf759c0d081e84ba445fb0f26563777 *sda.img

9. Пришла в голову идея, что виноваты передние дырки USB, с которыми вроде раньше были проблемы, или внешний USB HDD. Первый «неудачный» хард был отмонтирован и отсоединён от сервера (был присоединён в передние разъёмы USB). Был взят USB HDD другой модели и присоединён в задний разъём USB.

10. Процедура повторилась, и в результате получили с точностью до наоборот:

4cf759c0d081e84ba445fb0f26563777 */dev/sda
6d4b2214002432558026240bd3e089a5 *sda.img

11. Сравним размеры образа и диска

% ls -l 
total 71139330
-rwxrwxrwx 1 root root          43 Nov  1 23:03 dev-sda.md5
-rwxrwxrwx 1 root root 72846671872 Nov  1 22:48 sda.img
-rwxrwxrwx 1 root root         217 Nov  1 22:48 sda.img.log
-rwxrwxrwx 1 root root          42 Nov  1 23:36 sda.img.md5

% parted /dev/sda unit b print
Model: LSI MegaRAID SAS RMB (scsi)
Disk /dev/sda: 72846671872B
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start       End           Size          Type     File system  Flags
 1      1048576B    105906175B    104857600B    primary  ntfs         boot
 2      105906176B  72845623295B  72739717120B  primary  ntfs

12. Диск цел, т.к.

% cat sda.img.log
# Rescue Logfile. Created by GNU ddrescue version 1.16
# Command line: ddrescue /dev/sda sda.img sda.img.log
# current_pos  current_status
0x10F5FF0000     +
#      pos        size  status
0x00000000  0x10F6000000  +

13. Было видно, что в разные разы читал с разных дисков зеркала (моргали разные диски).

Найти:

Куда копать? Как перенести данные и систему в таком виде, в котором она сейчас есть на диске, чтобы потом можно было собрать RAID, залить образ обратно и расширить с помощью gparted?

★★★★★

Последнее исправление: Infra_HDC (всего исправлений: 1)

То есть вы хотите сказать, что если из под SystemRescueCd несколько раз подряд запустить ″md5sum /dev/sda″, то будут разные результаты?

И, если у вас сохранились оба образа на usb-дисках, сравните их, поди там разница в последнем секторе.

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

Похоже, он берет то с одного, то с другого диска, и диски между собой рассинхронизировались.

Когда делал cmp <один_образ> <другой_образ>, то получилось:

$ cat 20141102-001-to-20141101-001.cmp
/mnt/pub2/username/sshfs/servname-20141102-001/sda.img /media/TRANSCEND/servname-20141101-001/sda.img различаются: байт 8767598729, строка 49144869
Infra_HDC ★★★★★
() автор топика
Последнее исправление: Infra_HDC (всего исправлений: 2)

Почитай доки на сервер, обычно расширить массив можно более простым способом. Один диск у тебя уже 146 Гб, надо просто заменить второй диск на 146Гб, дождаться ребилда, утилитой от вендора расширить массив, потом расширить раздел в ОС. Может вообще все в онлайне получится сделать.

То, что два диска не совпадают побайтно, в принципе объяснимо. В зависимости от типа RAID-контроллера он может хранить служебную информацию на диске, и никто не обещал, что она будет совпадать для обоих дисков. К тому же, некоторые RAID-контроллеры вообще не синхронизируют диски, и операция создания массива у них проходит моментально - видно, хранят карту используемых блоков.

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

В общем, логика в этом есть: если была быстрая инициализация, и в некоторые сектора до сих пор не писали, то они, с одинаковыми номерами, могут быть разные для разных дисков, и смысла читать оттуда, куда не писал, нет никакого.

Но мы уже успели пересобрать массив. И восстанавливаем штатными средствами оффтопа ).

Infra_HDC ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.