Jump to content
XPEnology Community

Synology Hybrid RAID (SHR) - Сбой 2х дисков из 3х


Arabezar

Recommended Posts

Живу на DSM 5.0.4493 Update 2 с установленным на все 3 диска (2,3,4 ТБ) Synology Hybrid RAID (SHR)

Акронисом периодически бэкаплю домашний комп на NAS. Места - в обрез.

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

Скорее всего по причине переполнения случился Сбой... сразу двух дисков - 2го и 3го.

Хранилище вошло в режим Degraded.

Перегрузил NAS - в результате получил 1й диск в нормальном состоянии (как и был), 2й диск - не инициализирован (раньше был в состоянии Сбой, но почему-то с температурой холодного неработающего диска), 3й диск остался в режиме Сбоя.

Сейчас система предлагает: "... Попытайтесь выполнить резервирование данных перед удалением раздела".

На картинке - текущее состояние дисков, раньше это был единый раздел.

Вопрос: Что можно сделать? Обязательно ли удалять (пересоздавать) раздел или есть другой выход? И типичная ли это проблема при переполнении дисков? Может, не стОит более использовать SHR или это не может быть связано с SHR?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Я писал:

Перегрузил NAS - в результате получил 1й диск в нормальном состоянии (как и был), 2й диск - не инициализирован (раньше был в состоянии Сбой, но почему-то с температурой холодного неработающего диска), 3й диск остался в режиме Сбоя.

Только не упоминал, что перегружал с выключением где-то на минуту.

До выключения массив состоял из трёх дисков, два из которых (2й и 3й) со Сбоем.

После выключения/включения 2й диск отвалился из массива и стал со статусом Не инициализирован, 3й остался в статусе Сбой, а 1й так и остался в статусе Нормально.

 

А плохие новости - это как?

Что лучше сделать? Забэкапить данные и пересоздать массив?

И повторюсь, нормальное ли это поведение массива SHR при переполнении?

Link to comment
Share on other sites

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

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

Link to comment
Share on other sites

  • 3 weeks later...

Поймал такую же проблему, но с некоторыми оговорками.

XPEnology с DSM 5.0-4458 Update 2 крутится на VMWare vSphere 5.1. Под нужды XPEnology выделен виртуальный раздел на 1Тб.

 

На кануне не уследил за объемом свободного пространства и получил проблему в виде сбоя.

Физической проблемы с диском нет. Отсюда вопрос: как убрать состояние "Только на запись" (Degraded) в котором находится DSM. Т.е. возможно ли как-то поправить через терминал это состояние или же возможно получится решить проблему сменой загрузчика и повышением версии DSM? Есть какие-то мысли на этот счет, уж больно не хочется гонять сотни гигабайт с винта на винт?

788107fe87afb7ca467f94235634545d.png

0457029a8d31ebb712607db256182d7b.png

335bbc8904c06d68e584b914e1cf5fb6.png

Link to comment
Share on other sites

Ну так если массив еще читается по SMB, то самое простое - это переписать данные в третье место, потом удалить/создать раздел и переписать обратно. Если какой-то диск не инициализируется, данные прочитать невозможно - то я бы подсоединил бы диски в другую машину, если диски определяются, то создал бы флешку с юбунтой (мини, не обязательно с иксами), и с помощью mdadm восстановил бы данные у /dev/md2. В этом случае главное чтобы диск завелся на другой машине и прочитался системой. Все остальное ерунда, у меня было как-то раз такое давно.

Link to comment
Share on other sites

Можно попробовать chkfs

Я так понимаю, что эта команда не стандартная для DSM, т.к.:

> chkfs
-ash: chkfs: not found

Ну так если массив еще читается по SMB, то самое простое - это переписать данные в третье место, потом удалить/создать раздел и переписать обратно. Если какой-то диск не инициализируется, данные прочитать невозможно - то я бы подсоединил бы диски в другую машину, если диски определяются, то создал бы флешку с юбунтой (мини, не обязательно с иксами), и с помощью mdadm восстановил бы данные у /dev/md2. В этом случае главное чтобы диск завелся на другой машине и прочитался системой. Все остальное ерунда, у меня было как-то раз такое давно.

 

Да, данные читаются как и прежде, как через SMB, так и через File Station, т.е. DSM перешел в состояние "Только чтение" (с отключением всех пакетов способных генерировать данные для записи на диск), т.к. предполагает, что с жестким диском произошла беда и что его пора бы заменить. А так как при записи новых данных, по его мнению, жесткий диск может дать сбой, то он и перешел в режим "Только чтение", типа "Бекапь всё и вставляй новый диск".

НО, я то знаю, что DSM заблуждается из-за того, что произошла ошибка записи по причине заполнения виртуального диска на 100%, а сам физический диск еще имел 300Гб свободного пространства (напомню, что XPEnology работает на виртуалке VMware с виртуальным дисковым пространством, а не диском на прямую)

 

...самое простое - это переписать данные в третье место...

И почему это самое простое? У меня есть DS413j и больше Терабайта свободного места на нем, но на XPEnology установленном на виртуалке, а меня крутится не особо важная инфа, типа фильмов и сериалов, плюс различные сторонние вебсервисы, что в итоге дает 1Тб данных которые будут копироваться "вечность", а особенно папка web (учитывая тормознутость DS413j и RAID 1). Хоть этот вариант на 100% рабочий и очевидный, применить его хотело бы только в самом последнем случаи, т.е. не найдя "элегантного решения".

 

Так как известно, что физическая проблема с диском отсутствует и DSM ошибочно полагает, что диску пора идти на покой, то резонно предположить, что в системных папка DSM есть параметр который хранит состояние системы, ну или что-то на подобии этого, который и сообщает, что DSM должна перейти в режим "Только чтение".

Так если этот параметр можно поправить, то не проще ли так и сделать, а не таскать сотни гигабайт данных?

 

Если есть хотя бы предположение в какую сторону капать, то не стесняйтесь высказать его.

Link to comment
Share on other sites

ну так ведь никто и не знает где этот параметр, поэтому я и сказал, что это самое простое. 1TB вечность? Вы о чем? Не обязательно писать на 413j - это будет медленно. Если сеть гигабитная, да и в основном крупные файлы - то это ~ 4 часа, если 100мбит/c, или на 413j - то больше суток, да. Но это не вечность :smile: Не знаю, я бы даже не задумывался в Вашем случае. Да и если этот параметр можно будет найти - то он будет дико зашифрофан, поди разберись. Поэтому проще переписать.

Link to comment
Share on other sites

Можно попробовать chkfs

Я так понимаю, что эта команда не стандартная для DSM, т.к.:

> chkfs
-ash: chkfs: not found

Извините, опечатка. Попробуйте

fsck.ext4

Link to comment
Share on other sites

Можно попробовать chkfs

Я так понимаю, что эта команда не стандартная для DSM, т.к.:

> chkfs
-ash: chkfs: not found

Извините, опечатка. Попробуйте

fsck.ext4

А не подскажете с каким ключом и параметрами?

Usage: fsck.ext4 [-panyrcdfvtDFV] [-b superblock] [-B blocksize]
	[-I inode_buffer_blocks] [-P process_inode_size]
	[-l|-L bad_blocks_file] [-C fd] [-j external_journal]
	[-E extended-options] device

Emergency help:
-p                   Automatic repair (no questions)
-n                   Make no changes to the filesystem
-y                   Assume "yes" to all questions
-c                   Check for bad blocks and add them to the badblock list
-f                   Force checking even if filesystem is marked clean
-v                   Be verbose
-b superblock        Use alternative superblock
-B blocksize         Force blocksize when looking for superblock
-j external_journal  Set location of the external journal
-l bad_blocks_file   Add to badblocks list
-L bad_blocks_file   Set badblocks list

Link to comment
Share on other sites

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

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

Поменял по гарантии 2 диска из 3 в SHR. Восстанавливал обычным копированием, - у друга взял новый 4ТБ винт, создал 2й раздел в NAS, слил туда бОльшую часть инфы, остальное - по USB на внешние диски по 500ГБ. Потом заменил 2 диска, пересоздал SHR на всех 3х дисках, слил инфу обратно.

Очень рад, что восстановилось почти всё из почти 5 ТБ (SHR=2+3+4). Это при том, что 3ТБ полностью отвалился (не инициализирован, на нём оказалось больше всего бэдов), а 4ТБ находился в состоянии опасности (S.M.A.R.T.), весь массив - в состоянии "Только чтение". Протухло буквально 3-4 файла.

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

В общем, легко отделался )))

 

P.S. Вспомнилось: Админы делятся на два типа: те, кто ещё не делает бэкапы, и те, кто уже делает. ))

P.P.S. Однако, не хочу верить, что переполнение SHR приводит к таким результатам...

P.P.P.S. Ещё заметил, что 4 ТБ винт (проинициализированный с GPT и отформатированный в NTFS) не подцепился через USB, хотя 1 ТБ собратья цепляются без проблем. У всех так?

Link to comment
Share on other sites

Для начала попробуйте тестовый прогон с -pfnv и посмотрите что посоветует чинить, но без настоящих изменений.

Что-то никак не получается.

Остановил все ненужные службы командной syno_poweroff_task

Было

> df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/md0						2451064    726308   1622356  31% /
/tmp							512244       960    511284   0% /tmp
/dev/vg1000/lv					1052232404 934668000 117462004  89% /volume1
/volume1/@optware				1052232404 934668000 117462004  89% /opt
/volume1/OpenKM/repository		1052232404 934668000 117462004  89% /var/packages/OpenKM/target/OpenKM/repository
/volume1/OpenKM/repository		1052232404 934668000 117462004  89% /var/packages/OpenKM/target/OpenKM/repository
/dev/vg1001/lv					26302660    246084  25954176   1% /volume2

> syno_poweroff_task
synologrotated stop/waiting
initctl: Unknown instance: 
initctl: Unknown instance: 
webstation-httpd-conf-writer stop/waiting
afpd stop/waiting
synomkflvd stop/waiting
ftpd stop/waiting
php-fpm stop/waiting
initctl: Unknown instance: 
nmbd stop/waiting
sshd stop/waiting
smbd stop/waiting
synomkthumbd stop/waiting
crond stop/waiting
ntpd stop/waiting
nginx stop/waiting
cnid_metad stop/waiting
synobackupd stop/waiting
syslog-acc stop/waiting
img_backupd stop/waiting
httpd-user stop/waiting
nfsd-adapter stop/waiting

Стало

> df                   
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/md0		   2451064    725980   1622684  31% /
/tmp			   512244       292    511952   0% /tmp

 

Выполняем команду на проверку без изменений:

> e2fsck -v -n -f /dev/md0
e2fsck 1.42.6 (21-Sep-2012)
Warning!  /dev/md0 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong (433068, counted=431271).
Fix? no

Free inodes count wrong (120930, counted=120970).
Fix? no


      34718 inodes used (22.31%, out of 155648)
        157 non-contiguous files (0.5%)
         16 non-contiguous directories (0.0%)
            # of inodes with ind/dind/tind blocks: 0/0/0
            Extent depth histogram: 30269/32
     189476 blocks used (30.44%, out of 622544)
          0 bad blocks
          1 large file

      26916 regular files
       2877 directories
        151 character device files
       2047 block device files
          0 fifos
       1162 links
       2670 symbolic links (2163 fast symbolic links)
          8 sockets
------------
      35831 files

 

Теперь выполняем с изменениями на диске:

> e2fsck -v -f -y /dev/md0
e2fsck 1.42.6 (21-Sep-2012)
/dev/md0 is mounted.
e2fsck: Cannot continue, aborting.

Говорит что не желает продолжать видимо из-за

because doing a read-only filesystem check

 

Есть еще какие-нибудь мысли на эту тему?

 

Кстати, обновил загрузчик и версию DSM (в пределах 5.0) - не помогло. что ожидаемо.

Link to comment
Share on other sites

И тут я понял свой косяк :smile: Мне же проверять надо не md0, а /dev/vg1000/lv!

 

> e2fsck -v -n -f /dev/vg1000/lv
e2fsck 1.42.6 (21-Sep-2012)
Warning!  /dev/vg1000/lv is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Unattached inode 273472
Connect to /lost+found? no

Unattached inode 273475
Connect to /lost+found? no

Unattached inode 278585
Connect to /lost+found? no

Unattached inode 278593
Connect to /lost+found? no

Pass 5: Checking group summary information
Block bitmap differences:  +1084119 +1084174 -1147301 -1251329
Fix? no

Free blocks count wrong for group #3 (1611, counted=1604).
Fix? no

Free blocks count wrong for group #33 (89, counted=91).
Fix? no

Free blocks count wrong for group #35 (9769, counted=9768).
Fix? no

Free blocks count wrong for group #36 (6633, counted=6625).
Fix? no

Free blocks count wrong for group #38 (6160, counted=6159).
Fix? no

Free blocks count wrong for group #817 (32766, counted=32767).
Fix? no

Free blocks count wrong for group #1034 (95, counted=94).
Fix? no

Free blocks count wrong for group #1476 (108, counted=107).
Fix? no

Free blocks count wrong for group #2171 (3816, counted=3862).
Fix? no

Free blocks count wrong for group #2807 (11655, counted=11330).
Fix? no

Free blocks count wrong for group #5954 (20572, counted=20571).
Fix? no

Free blocks count wrong (29391101, counted=29390796).
Fix? no

Inode bitmap differences:  +273472 +273475 +278585 +278593
Fix? no

Free inodes count wrong for group #33 (0, counted=2).
Fix? no

Free inodes count wrong for group #34 (3761, counted=3767).
Fix? no

Free inodes count wrong for group #816 (8190, counted=8191).
Fix? no


1.42.6-3810: ********** WARNING: Filesystem still has errors **********


     506417 inodes used (0.76%, out of 66813952)
       1488 non-contiguous files (0.3%)
         98 non-contiguous directories (0.0%)
            # of inodes with ind/dind/tind blocks: 0/0/0
            Extent depth histogram: 501671/778/27
  237861635 blocks used (89.00%, out of 267252736)
          0 bad blocks
        106 large files

     421074 regular files
      80347 directories
          1 character device file
          0 block device files
          0 fifos
        479 links
       4990 symbolic links (3936 fast symbolic links)
          0 sockets
------------
     506887 files

Link to comment
Share on other sites

  • 9 months later...

Хоть и прошло ровно девять месяцев, всё же отпишусь о решении своей проблемы. Короче. Ничего не помогло. Ни проверки поверхности диска и различные диагностики, не замены загрузчиков и переустановка разных версий DSM, ни поиск параметра в системных потрохах DSM (хотя я уверен что плохо искал, ведь он наверняка есть). В итоге пришлось делать то, чего не особо-то и хотелось, т.е. переносить все данные на вновь созданный раздел.

Link to comment
Share on other sites

×
×
  • Create New...