Arabezar Posted January 10, 2015 Share #1 Posted January 10, 2015 Живу на 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 More sharing options...
XPEH Posted January 10, 2015 Share #2 Posted January 10, 2015 Для начала попробуйте полное выключение сервера на несколько минут. Если второй диск не востановится, боюсь вас ожидают плохие новости. Link to comment Share on other sites More sharing options...
Arabezar Posted January 10, 2015 Author Share #3 Posted January 10, 2015 Я писал: Перегрузил NAS - в результате получил 1й диск в нормальном состоянии (как и был), 2й диск - не инициализирован (раньше был в состоянии Сбой, но почему-то с температурой холодного неработающего диска), 3й диск остался в режиме Сбоя. Только не упоминал, что перегружал с выключением где-то на минуту. До выключения массив состоял из трёх дисков, два из которых (2й и 3й) со Сбоем. После выключения/включения 2й диск отвалился из массива и стал со статусом Не инициализирован, 3й остался в статусе Сбой, а 1й так и остался в статусе Нормально. А плохие новости - это как? Что лучше сделать? Забэкапить данные и пересоздать массив? И повторюсь, нормальное ли это поведение массива SHR при переполнении? Link to comment Share on other sites More sharing options...
XPEH Posted January 10, 2015 Share #4 Posted January 10, 2015 Не могу сказать как SHR ведет себя при переполнении, но если удастся что то забэкапить, то лучше это сделать. Плохие новости это возможная физическая неисправность второго диска. Если форматирование не поможет и его статус с температурой не будет нормально отображаться, может потребоваться замена. Link to comment Share on other sites More sharing options...
kmx236 Posted January 27, 2015 Share #5 Posted January 27, 2015 Поймал такую же проблему, но с некоторыми оговорками. XPEnology с DSM 5.0-4458 Update 2 крутится на VMWare vSphere 5.1. Под нужды XPEnology выделен виртуальный раздел на 1Тб. На кануне не уследил за объемом свободного пространства и получил проблему в виде сбоя. Физической проблемы с диском нет. Отсюда вопрос: как убрать состояние "Только на запись" (Degraded) в котором находится DSM. Т.е. возможно ли как-то поправить через терминал это состояние или же возможно получится решить проблему сменой загрузчика и повышением версии DSM? Есть какие-то мысли на этот счет, уж больно не хочется гонять сотни гигабайт с винта на винт? Link to comment Share on other sites More sharing options...
XPEH Posted January 27, 2015 Share #6 Posted January 27, 2015 Можно попробовать chkfs Link to comment Share on other sites More sharing options...
aisman Posted January 27, 2015 Share #7 Posted January 27, 2015 Ну так если массив еще читается по SMB, то самое простое - это переписать данные в третье место, потом удалить/создать раздел и переписать обратно. Если какой-то диск не инициализируется, данные прочитать невозможно - то я бы подсоединил бы диски в другую машину, если диски определяются, то создал бы флешку с юбунтой (мини, не обязательно с иксами), и с помощью mdadm восстановил бы данные у /dev/md2. В этом случае главное чтобы диск завелся на другой машине и прочитался системой. Все остальное ерунда, у меня было как-то раз такое давно. Link to comment Share on other sites More sharing options...
kmx236 Posted January 27, 2015 Share #8 Posted January 27, 2015 Можно попробовать 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 More sharing options...
aisman Posted January 27, 2015 Share #9 Posted January 27, 2015 ну так ведь никто и не знает где этот параметр, поэтому я и сказал, что это самое простое. 1TB вечность? Вы о чем? Не обязательно писать на 413j - это будет медленно. Если сеть гигабитная, да и в основном крупные файлы - то это ~ 4 часа, если 100мбит/c, или на 413j - то больше суток, да. Но это не вечность Не знаю, я бы даже не задумывался в Вашем случае. Да и если этот параметр можно будет найти - то он будет дико зашифрофан, поди разберись. Поэтому проще переписать. Link to comment Share on other sites More sharing options...
XPEH Posted January 27, 2015 Share #10 Posted January 27, 2015 Можно попробовать chkfs Я так понимаю, что эта команда не стандартная для DSM, т.к.: > chkfs -ash: chkfs: not found Извините, опечатка. Попробуйте fsck.ext4 Link to comment Share on other sites More sharing options...
kmx236 Posted January 27, 2015 Share #11 Posted January 27, 2015 Можно попробовать 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 More sharing options...
XPEH Posted January 27, 2015 Share #12 Posted January 27, 2015 Для начала попробуйте тестовый прогон с -pfnv и посмотрите что посоветует чинить, но без настоящих изменений. Link to comment Share on other sites More sharing options...
Arabezar Posted January 30, 2015 Author Share #13 Posted January 30, 2015 Не могу сказать как 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 More sharing options...
kmx236 Posted February 5, 2015 Share #14 Posted February 5, 2015 Для начала попробуйте тестовый прогон с -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 More sharing options...
kmx236 Posted February 5, 2015 Share #15 Posted February 5, 2015 И тут я понял свой косяк Мне же проверять надо не 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 More sharing options...
kmx236 Posted November 5, 2015 Share #16 Posted November 5, 2015 Хоть и прошло ровно девять месяцев, всё же отпишусь о решении своей проблемы. Короче. Ничего не помогло. Ни проверки поверхности диска и различные диагностики, не замены загрузчиков и переустановка разных версий DSM, ни поиск параметра в системных потрохах DSM (хотя я уверен что плохо искал, ведь он наверняка есть). В итоге пришлось делать то, чего не особо-то и хотелось, т.е. переносить все данные на вновь созданный раздел. Link to comment Share on other sites More sharing options...
Recommended Posts