| 
|  | Полезные пакеты, которые можно установить на сервер для диагностики сбоев (доп. ссылка 1) | [комментарии] |  |  | Минимальный набор пакетов  для диагностики проблем, которые рекомендуется заранее установить на серверы, чтобы не тратить время на установку дополнительных пакетов или поиск специализированных live-дистрибутивов. ...
 [Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
 
 |  |  |  |  |  | 
| 
|  | Cкрипт ddrescue-loop с функцией автоматической остановки/перезапуска диска на SATA порту (доп. ссылка 1) | Автор: gumanzoy 
[комментарии] |  |  | Cкрипт [[https://github.com/gumanzoy/ddrescue-loop ddrescue-loop v0.1]] с функцией автоматической остановки/перезапуска диска на SATA порту. ...
 [Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
 
 |  |  |  |  |  | 
| 
|  | Рекомендации по восстановлению данных со сбойного накопителя (доп. ссылка 1) | Автор: Аноним 
[комментарии] |  |  | USB флехи и SSD предмет простой: или прочиталось или нет. Шансов что при повторной попытке не читавшийся сектор прочитается - мало. Если заряд в флехе утек, то утек. Если там что-то более системное, слет таблиц трансляции, кончина (фирмвари) контроллера и прочее - ddrescue опять же не поможет. Это или спецутилиты под конкретный контроллер или подпайка к NAND и вычитывание на программаторе. Сам не сделаешь с такими вопросами. ...
 [Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
 
 |  |  |  |  |  | 
| 
|  | Как подключить в Ubuntu диски Seagate Business NAS и восстановить данные | Автор: redwire 
[комментарии] |  |  | Данное пошаговое руководство содержит мои попытки подключить диски с вышедшего из строя сигейтовского хранилища к Ubuntu и восстановить файлы с русскими именами в UTF-8. В итоге все успешно получилось.
 Некоторые шаги не нужны и просто приведены чтобы показать ход мыслей и ошибочные результаты ...
 [Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
 
 |  |  |  |  |  | 
| 
|  | Выполнение команды с отключением кеширования операций с файловой системой в Linux (доп. ссылка 1) | [комментарии] |  |  | В некоторых ситуациях необходимо выполнить операцию без влияния на кэш файловой
системы, например, скопировать данные без их попадания в кэш. Для отключения
кэша на уровне отдельных команд можно использовать утилиту nocache,
перехватывающую вызовы open и close, и выполняя принудительно системый вызов
posix_fadvise c параметром POSIX_FADV_DONTNEED.
В качестве одной из областей использования доступа к  ФС c отключением
кэширования можно отметить выполнение резервного копирования без влияния на
содержимое кэша - в обычных условиях копирование большого числа файлов вытеснит
часть других данных из кэша, при этом заранее известно, что новые данные точно
не будут востребованы в ближайшее время. Избежать оседания данных в кэше при
копировании можно выполнив следующую команду:
   ./nocache cp -a ~/ /mnt/backup/home-$(hostname)
Другим применением может быть проведение тестов с исключением влияния кэша ФС.
 |  |  |  |  |  | 
| 
|  | Выявление нагружающих дисковую подсистему процессов в Linux | Автор: Yuriy Kulikov 
[комментарии] |  |  | В Centos 5.x нет нормальной поддержки iotop, без которого трудно понять, какой процесс больше всего грузит дисковую систему.
 Но можно использовать скрипт [[http://sourceware.org/systemtap/examples/io/disktop.stp disktop.stp]], написанный для подсистемы динамической трассировки [[http://sourceware.org/systemtap/ SystemTap]]. ...
 [Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
 
 |  |  |  |  |  | 
| 
|  | Пропуск выполнения e2fsck при загрузке, через нажатие CTRL-C (доп. ссылка 1) (доп. ссылка 2) | Автор: Minoru 
[комментарии] |  |  | Согласно закону Мерфи, проверка fsck, происходящая каждые N загрузок, всегда
случается в самое неподходящее время. По умолчанию, прерывание проверки с
помощью CTRL-C заставляет fsck возвращать код ошибки, что приводит к
перемонтированию файловой системы в режиме "только чтение".
Но это легко меняется правкой /etc/e2fsck.conf:
   [options]
   allow_cancellation = true
 |  |  |  |  |  | 
| 
|  | Удаление физического раздела из LVM (доп. ссылка 1) | Автор: ffsdmad 
[комментарии] |  |  | Монитор системы в Ubuntu 9.10 показал наличие проблемы с одним диском (/dev/sdb), который включён в LVM. ...
 [Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
 
 |  |  |  |  |  | 
| 
|  | Решение проблем с удалением файлов гигантского размера в Linux (доп. ссылка 1) | [комментарии] |  |  | Попытка удаления файла, имеющего размер порядка 7 Тб, приводит к зависанию Linux сервера 
с ФС ext4 или reiser на несколько часов.
Решение: проблема исчезает при использовании файловой системы XFS.
 |  |  |  |  |  | 
| 
|  | Быстрое тестирование производительности диска во FreeBSD (доп. ссылка 1) | [комментарии] |  |  | Для быстрой оценки характеристик диска, а также получения сведений о скорости передачи данных 
и времени позиционирования головок во FreeBSD можно использовать утилиту diskinfo:
   diskinfo -t /dev/aacd0
   diskinfo -c /dev/aacd0
Для более детального анализа производительности можно использовать порт
/usr/ports/benchmarks/bonnie++
 |  |  |  |  |  | 
| 
|  | Как быстро восстановить в Linux удаленный, но еще открытый файл | [комментарии] |  |  | Если файл был случайно удален, но он еще открыт на чтение в какой-либо программе
 (например, проигрывается в медиа-плеере), то его легко восстановить из файлового дескриптора в ФС /proc ...
 [Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
 
 |  |  |  |  |  | 
| 
|  | Трассировка ввода/вывода в Linux (доп. ссылка 1) | [комментарии] |  |  | Утилита blktrace (присутствует в репозиториях Ubuntu и Debian) позволяет 
 проконтролировать какие именно данные передаются для заданного блочного устройства. ...
 [Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
 
 |  |  |  |  |  | 
| 
|  | Восстановление  файлов, удаленных с Linux (ext3) и FreeBSD разделов (доп. ссылка 1) | [комментарии] |  |  | Самый простой вариант - использование универсальной утилиты TestDisk (http://www.cgsecurity.org/wiki/TestDisk, 
 /usr/ports/sysutils/testdisk) поддерживающей множество файловых систем, 
 например, ext2, ext3, ufs, fat, NTFS. Кроме восстановления файлов TestDisk позволяет 
 находить и восстанавливать содержимое удаленных дисковых разделов. ...
 [Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
 
 |  |  |  |  |  | 
| 
|  | Как избавиться от нечитаемых секторов на диске | [комментарии] |  |  | В логе smartd появились подобные свидетельства наличия нечитаемых секторов на диске: ...
 [Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
 
 |  |  |  |  |  | 
| 
|  | Добавление информации для восстановления к архивам. | Автор: mahoro 
[комментарии] |  |  | Утилита par2 позволяет добавлять к файлам информацию для восстановления по алгоритму Рида-Соломона. 
 Это позволяет восстанавливать исходный файл в случае небольших (или даже серьезных) повреждений. 
 Делается это следующим образом: ...
 [Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
 
 |  |  |  |  |  | 
| 
|  | Как поведет себя ext3 при сбросе питания на разных стадиях работы ФС (доп. ссылка 1) | [комментарии] |  |  | Как поведет себя ext3 при крахе, из-за отключения питания машины, на разных стадиях работы ФС.
 Если питание будет отключено в момент записи и повредит сектор, то восстановления записываемой информации не будет;
 Сброс питания во время записи может привести к последующему получению случайного набора данных, но fsck должно среагировать на эту проблему;
 Если отключение питания вызвало повреждение данных в секторах, целостность данных в секторе, который успел записаться будет сохранена;
 Тем же проблемам подвержены любые другие журналируемые ФС, например XFS. |  |  |  |  |  | 
|  | 
| 
|  | Ядро 2.6.14 и OnTrack на диске | Автор: Spider84 
[обсудить] |  |  | Наткнулся на днях на грабли. Оказывается ядро 2.6.14, а я уверен и не только оно,
 не понимает автоматом OnTrack на диске и прочие ему подобные "изменятели геометрии диска".
Если к примеру ядро 2.4.29 без проблем грузится на с таким диском и при загрузке пишет что-то типа:
   hdc: hdc1[DM6:DD0] hdc2 <hdc5 hdc6>
то 2.6.14 пишет:
   
   hdc: hdc1[DM6] hdc2
и продолжает грузиться, при этом обратиться к hdc разделам нельзя, но fdisk с ними работает.
проблема решилась установкой ключа hdc=remap64 в параметрах ядра.
к примеру в lilo.conf так:
   append="hdc=remap63"
и при загрузке ядро на ура всё определит.
О более подробном списке ключей можно почитать тут: /usr/src/linux/Documentation/ide.txt строка 214
 |  |  |  |  |  | 
| 
|  | Как проверить жесткий диск используя SMART интерфейc. (доп. ссылка 1) | [комментарии] |  |  | Устанавливаем утилиту http://smartmontools.sourceforge.net/ ...
 [Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
 
 |  |  |  |  |  | 
| 
|  | Мониторинг и восстановление программного RAID в Linux | Автор: radigor 
[комментарии] |  |  | Управление программными RAID1-массивами в RHEL ...
 [Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
 
 |  |  |  |  |  | 
| 
|  | Почему после переноса Linux на другой диск LILO выдает "L 99 99..." (доп. ссылка 1) | Автор: Sergey Vlasov 
[комментарии] |  |  | При загрузке ядра LILO запоминает данные о назначении номеров BIOS для
дисков, и потом при установке 
загрузчика использует эти данные.  При смене устройства для загрузки в
настройках BIOS номера дисков
меняются (выбранный для загрузки диск получает номер 0x80), поэтому сохранённая lilo информация 
перестаёт соответствовать реальной конфигурации.
Нужно явно указать номера дисков в /etc/lilo.conf:
disk=/dev/hda
	bios=0x80
disk=/dev/hdb
	bios=0x81
 |  |  |  |  |  | 
| 
|  | Что можно сделать если на жестком диске появился bad-сектор (доп. ссылка 1) | [комментарии] |  |  | Скачать smartmontools (http://smartmontools.sourceforge.net/)
Выполнить:
   smartctl -a /dev/hda     # Посмотреть состояние
   smartctl -t long /dev/hda     # Провести тест
   smartctl -l selftest /dev/hda # Дождаться окончания теста и посмотреть результат
При необходимости воспользоваться debugfs как написано в статье по ссылке.
 |  |  |  |  |  | 
| 
|  | Как сделать бэкап таблицы разделов диска | [обсудить] |  |  | Бэкап MBR:
    dd if=/dev/hda of=mbr_backup.bin bs=1 count=512
Для восстановления всего MBR поменять if/of местами.
Таблица разделов находится в MBR по смещению 0x01BE (446) и состоит
из 4 записей по 16 байт.
Для восстановления только таблицы разделов:
    dd  if=mbr_backup.bin  of=/dev/устройство  bs=1 count=64 skip=446 seek=446
 |  |  |  |  |  | 
| 
|  | Если fsck сообщает "CANNOT FIX" и прекращает работу (доп. ссылка 1) | Автор: Oleg Polovinkin 
[обсудить] |  |  | (Во FreeBSD и Solaris)
Можно удалить дефектный inode с помощью команды clri:
    clri <файловая-система> <номер-inode>
и запустить снова fsck. При этом, к сожалению, файл теряется, но остальное спасется. 
 |  |  |  |  |  | 
| 
|  | Как попытаться восстановить данные с начавшего сбоить жесткого диска | Автор: uldus 
[комментарии] |  |  | Нужно вставить диск в заведомо рабочую машину (так как проблемы не обязательно в диске, контроллер может 
 быть виной) с достаточным свободным местом на диске чтобы вместить весть объем сбойного диска  и сделать: ...
 [Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
 
 |  |  |  |  |  | 
| 
|  | Как размонтировать занятый неизвестным процессом CDROM | [комментарии] |  |  | fuser -k -m /mnt/cdrom - убить процессы использующие /mnt/cdrom
umount /mnt/cdrom
 |  |  |  |  |  |