<?xml version="1.0" encoding="utf-8"?> 
<rss version="2.0"
  xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"
  xmlns:atom="http://www.w3.org/2005/Atom">

<channel>

<title>Аникин: заметки с тегом badblocks</title>
<link>https://anikin.pw/tags/badblocks/</link>
<description>Блог об администрировании Linux, BSD и не только</description>
<author></author>
<language>ru</language>
<generator>Aegea 11.3 (v4134)</generator>

<itunes:subtitle>Блог об администрировании Linux, BSD и не только</itunes:subtitle>
<itunes:image href="" />
<itunes:explicit></itunes:explicit>

<item>
<title>Linux recovery system Server4You manual</title>
<guid isPermaLink="false">13</guid>
<link>https://anikin.pw/all/linux-recovery-system-server4you-manual/</link>
<pubDate>Tue, 22 Oct 2013 19:36:05 +0300</pubDate>
<author></author>
<comments>https://anikin.pw/all/linux-recovery-system-server4you-manual/</comments>
<description>
Автор:  &lt;a href="http://shmelenduk.ru" target="_blank"&gt;Артем Авдонин&lt;/a&gt;&lt;p&gt;
Для чего может потребоваться загрузка вашего сервера под linux recovery system? Очевидный ответ - для проведения диагностики и процедур восстановления работоспособности ОС.

Что же из себя представляет сервер, загруженный в recovery? Это загруженный на Вашем сервере, по сети, образ linux. В нём уже установлены все основные утилиты, которые могут быть использованы при диагностике и восстановлении работоспособности сервера.

И так, у нас есть сервер в вышеупомянутом датацентре, загруженный в recovery mode.

Оглавление (постоянно обновляется)
&lt;ol&gt;
&lt;li&gt;&lt;a href="http://anikin.pw/all/linux-recovery-system-server4you-manual/#mdadm"&gt;Запуск и монтирование корневой файловой системы&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="http://anikin.pw/all/linux-recovery-system-server4you-manual/#fsck"&gt;Ошибки файловой системы&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="http://anikin.pw/all/linux-recovery-system-server4you-manual/#raid"&gt;Проблемы RAID&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="http://anikin.pw/all/linux-recovery-system-server4you-manual/#hdd"&gt;Проблемы HDD&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="http://anikin.pw/all/linux-recovery-system-server4you-manual/#troubleshoot"&gt;Сброс правил firewall&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="http://anikin.pw/all/linux-recovery-system-server4you-manual/#backup"&gt;Доступ к данным на сервере&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="http://anikin.pw/all/linux-recovery-system-server4you-manual/#passwd"&gt;Сброс root пароля&lt;/a&gt;&lt;/li&gt;
&lt;/ol&gt;
Подключаемся к серверу по ssh. В качестве имени пользователя указываем суперпользователя root, пароль указывается при отправке сервера в recovery mode.
&lt;a name="mdadm"&gt;&lt;/a&gt;
&lt;h2 style="padding-left: 30px"&gt;1. Запуск и монтирование корневой файловой системы&lt;/h2&gt;
В случае, если в системе используется RAID массив, начнём с его запуска:
&lt;pre style="padding-left: 30px"&gt;~# mdadm --assemble --run /dev/md2&lt;/pre&gt;
Эта команда запускает software RAID массив с меткой md2. На серверах s4y чаще всего md2 является rootfs (корневой файловой системой). Но не исключено, что искомым будем массив с меткой md1. Массив md0 - раздел /boot По выполнению команды вы должны увидеть:
&lt;pre style="padding-left: 30px"&gt;mdadm: /dev/md2 has been started with 2 drives.&lt;/pre&gt;
Это значит, что RAID успешно запущен. Проверим нормально ли собрался RAID:
&lt;pre style="padding-left: 30px"&gt;~# cat /proc/mdstat

Personalities : [raid1] [raid0] [raid6] [raid5] [raid4]
md2 : active raid1 sdb4[0] sda4[1]
      1456634744 blocks super 1.2 [2/2] [UU]                     

unused devices: &amp;lt;none&amp;gt;&lt;/pre&gt;
2/2 дисков добавлено в массив. Всё в порядке. В случае 1/2 или ошибок после ввода команды сборки массива обращайтесь в раздел Проблемы RAID.

Монтируем md2 в любую удобную вам точку. В данном случае я понтирую файловую систему в точку /mnt:
&lt;pre style="padding-left: 30px"&gt;~# mount /dev/md2 /mnt&lt;/pre&gt;
Удостоверимся, что то, что мы примонтировали является rootfs нашего сервера:
&lt;pre style="padding-left: 30px"&gt;~# ls /mnt
aquota.user dev initrd.img lib64 mnt root srv usr
bin etc lib lost+found opt sbin sys var
boot home lib32 media proc selinux tmp vmlinuz&lt;/pre&gt;
Видим вполне стандартное дерево каталогов корневой файловой системы linux дистрибутива. Значит md2 является rootfs Вашего сервера.

Если у Вас установлен шаблон без использования RAID, то нужно просто смонтировать /dev/sdaX, где X номер раздела с ОС.

После монтирования файловой системы можно начинать работу по диагностике проблем ОС или работать с вашими файлами.
&lt;a name="fsck"&gt;&lt;/a&gt;
&lt;h2 style="padding-left: 30px"&gt;2. Ошибки файловой системы&lt;/h2&gt;
Часто ОС не может загрузиться из за ошибок файловой системы. Что бы исключить или подтвердить и исправить данную проблему необходимо выполнить проверку файловой системы с помощью fsck. fsck &lt;strong&gt;должен&lt;/strong&gt; выполняться на отмонтированной файловой системе. Выполните раздел 1 этого руководства, исключая монтирование fs. Запустите таким образом md0 и md2 (/boot и корневую fs).

После того как массивы для проверки собраны выполняется fsck для md0 и md2:
&lt;pre&gt;~# fsck -y /dev/md2
fsck from util-linux 2.20.1
e2fsck 1.42 (29-Nov-2011)
/dev/md2 has been mounted 22 times without being checked, check forced.
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
/dev/md2: 68650/91045888 files (0.2% non-contiguous), 6396596/364158686 blocks&lt;/pre&gt;
fsck, в данном случае, выполнился без ошибок.
&lt;a name="raid"&gt;&lt;/a&gt;
&lt;h2 style="padding-left: 30px"&gt;3. Проблемы RAID&lt;/h2&gt;
Не загружающийся сервер может быть вызван не собирающимся, повреждённым, "развалившимся" RAID. Как запустить RAID указано в первой главе этой статьи. Запустите все имеющиеся у вас массивы и проверьте статистику mdstat:
&lt;pre style="padding-left: 30px"&gt;~# cat /proc/mdstat
&lt;span style="color: #222222;font-family: 'Courier 10 Pitch', Courier, monospace;line-height: 21px"&gt;~# cat /proc/mdstat
&lt;/span&gt;Personalities : [raid1] [raid0] [raid6] [raid5] [raid4]
md1 : active raid1 sdb3[0] sda3[1](F)
7999476 blocks super 1.2 [2/1] [U_]
md2 : active raid1 sdb4[0] sda4[1](F) 
1456634744 blocks super 1.2 [2/1] [U_]
md0 : active raid1 sdb2[0] sda2[1](F) 
499700 blocks super 1.2 [2/1] [U_]

unused devices: &amp;lt;none&amp;gt;&lt;/pre&gt;
Если вывод выглядит примерно так (обратите внимание на (F) и [2/1]) - это значит, что массив не собран и не работает. (F) - обозначает пометка массива как fail. [2/1] обозначает, что только один диск массива работает. Нужно удалить из массива сбойные разделы и попробовать добавить их снова:
&lt;pre style="padding-left: 30px"&gt;~# mdadm /dev/md1 -r /dev/sda3
mdadm: hot removed /dev/sda3 from /dev/md1
~# mdadm /dev/md0 -r /dev/sda2
mdadm: hot removed /dev/sda3 from /dev/md0
~# mdadm /dev/md2 -r /dev/sda4
mdadm: hot removed /dev/sda3 from /dev/md2&lt;/pre&gt;
Добавляем:
&lt;pre style="padding-left: 30px"&gt;~# mdadm /dev/md0 -a /dev/sda2&lt;/pre&gt;
Мы можем увидеть несколько ошибок и среди них
&lt;pre style="padding-left: 30px"&gt;mdadm: To make this a spare, use "mdadm --zero-superblock /dev/sda2" first.&lt;/pre&gt;
Выполняем mdadm --zero-superblock /dev/sda2 и повторяем mdadm /dev/md0 -a /dev/sda2 для каждого удаляемого выше раздела.

Проверим добавились ли разделы в массив:
&lt;pre style="padding-left: 30px"&gt;~# cat /proc/mdstat
Personalities : [raid1] [raid0] [raid6] [raid5] [raid4]
md1 : active raid1 sda3[2] sdb3[0]
 7999476 blocks super 1.2 [2/1] [U_]
 resync=DELAYED

md2 : active raid1 sda4[2] sdb4[0]
1456634744 blocks super 1.2 [2/1] [U_]
[&amp;gt;....................] recovery = 0.1% (2332928/1456634744) finish=365.5min speed=66306K/sec
md0 : active raid1 sda2[2] sdb2[0]

499700 blocks super 1.2 [2/2] [UU]

unused devices: &amp;lt;none&amp;gt;&lt;/pre&gt;
Значит RAID собирается нормально. Если на одном из этапов возникла ошибка, то стоит попробовать сначала пересоздать всю таблицу разделов, возможно её что-то покрошило. Если даже после этого RAID не собирается, то нужно проверить жёсткие диски.
&lt;a name="hdd"&gt;&lt;/a&gt;
&lt;h2 style="padding-left: 30px"&gt;4. Проблемы HDD&lt;/h2&gt;
Не загружается сервер? Не собирается RAID? Проверим диски!

Конкретная ситуация - RAID на сервере не собирается. Разделы диска sda помечены как сбойные. Нужно проверить состояние s.m.a.r.t.  этого диска.
&lt;p style="padding-left: 30px"&gt;smartctl -a /dev/sda&lt;/p&gt;
Из всего вывода нас интересует только серийный номер диска и таблица s.m.a.r.t :
&lt;pre style="padding-left: 30px"&gt;Model Family: Seagate Barracuda LP
Device Model: ST31500541AS
Serial Number: 5XW2PTK4&lt;/pre&gt;
Из таблицы интересуют только показатели, связанные с bad blocks:
&lt;pre style="padding-left: 30px"&gt;5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       23
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       15&lt;/pre&gt;
Если показатели в последнем столбце отличнны от 0, это признак нарушения поверхности диска и он подлежит замене. Если значения равны нулю, но диск в RAID добавить не удаётся (или не удаётся смонтировать, в случае с шаблоном без RAID), то нужно выполнить проверку диска на badblocks. Процедура потребует времени - от 3  до 6 часов.
&lt;pre style="padding-left: 30px"&gt;~# badblocks -v /dev/sda
Checking blocks 0 to 1465138583
Checking for bad blocks (read-only test): 0.01% done, 0:02 elapsed. (0/0/0 errors)&lt;/pre&gt;
Если во время проверки появились ошибки залогируйте их где-нибудь для передачи в техподдержку для замены диска.
&lt;a name="troubleshoot"&gt;&lt;/a&gt;
&lt;h2 style="padding-left: 30px"&gt;5. Сброс правил firewall&lt;/h2&gt;
Случайно сохранили некорректные правила iptables и установили на автозагрузку? Вам нужно примонтировать вашу файловую систему (раздел 1) и исправить/удалить правила из автозагрузки. Путь до файла будет другой:
файл бывший &lt;strong&gt;/etc/rc.local&lt;/strong&gt; будет &lt;strong&gt;/mnt/etc/rc.local&lt;/strong&gt;
&lt;a name="backup"&gt;&lt;/a&gt;
&lt;h2 style="padding-left: 30px"&gt;6. Доступ к данным&lt;/h2&gt;
Нужно просто снять бекапы? Выполняйте все действия из раздела 1. После этого Вы можете подключиться к серверу по sftp любым клиентом, например WinSCP и забрать Ваши файлы. Они будут находиться в каталоге /mnt
&lt;a name="passwd"&gt;&lt;/a&gt;
&lt;h2 style="padding-left: 30px"&gt;7. Сброс пароля&lt;/h2&gt;
Для того, что бы сбросить root пароль нужно выполнить все действия из раздела 1 и выполнить chroot на папке в которую примонтирована корневая файловая система, в данном случае это /mnt
&lt;pre style="padding-left: 30px"&gt;root@servername:~# chroot /mnt
servername:/#&lt;/pre&gt;
Теперь можно менять пароль root:
&lt;pre style="padding-left: 30px"&gt;servername:/# passwd root
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully&lt;/pre&gt;</description>
</item>


</channel>
</rss>