Упала шляпа - упала на пол. Восстановления данных с помощью FSСK.

King аватар
Опубликовано King в Пт, 15/01/2010 - 00:35

В роли шляпы тут подсуетился сервер под управлением Мандривы 2008.1.
Упал и все тут. Видно, компании Intel не нравились решения на платформе VIA, и она вошла в альянс с Торвальдсом, который заложил в VIA-дрова такие бэк-мины, которые обрушивают сервера на VIA хоть и не часто, но зато в самое неподходящее время (часть из этого утверждения - шутка )

После поднятия сервера и прогона FSCK встал неувядающий вопрос - что с этим мусором делать?

  1. # fsck -v -n /dev/sda3
  2. fsck 1.40.8 (13-Mar-2008)
  3. e2fsck 1.40.8 (13-Mar-2008)
  4. Warning!  /dev/sda3 is mounted.
  5. Warning: skipping journal recovery because doing a read-only filesystem check.
  6. /dev/sda3 contains a file system with errors, check forced.
  7. Pass 1: Checking inodes, blocks, and sizes
  8. Inodes that were part of a corrupted orphan linked list found.  Fix? no
  9.  
  10. Inode 229827 was part of the orphaned inode list.  IGNORED.
  11. Inode 229828 was part of the orphaned inode list.  IGNORED.
  12. Deleted inode 229829 has zero dtime.  Fix? no
  13.  
  14. Inode 229830 was part of the orphaned inode list.  IGNORED.
  15. Inode 229831 was part of the orphaned inode list.  IGNORED.
  16. Inode 229832 was part of the orphaned inode list.  IGNORED.
  17. Inode 229833 was part of the orphaned inode list.  IGNORED.
  18. Inode 229834 was part of the orphaned inode list.  IGNORED.
  19. Inode 229840 was part of the orphaned inode list.  IGNORED.
  20. Inode 229842 was part of the orphaned inode list.  IGNORED.
  21. Inode 229847 was part of the orphaned inode list.  IGNORED.
  22. Inode 229860 was part of the orphaned inode list.  IGNORED.
  23. Pass 2: Checking directory structure
  24. Pass 3: Checking directory connectivity
  25. Pass 4: Checking reference counts
  26. Pass 5: Checking group summary information
  27. Block bitmap differences:  -918019 -923649 -(927744--927745) -929792 -931843 -937985 -937987 -940033 -944128
  28. Fix? no
  29.  
  30. Free blocks count wrong (4778377, counted=4778374).
  31. Fix? no
  32.  
  33. Inode bitmap differences:  -(229827--229834) -229840 -229842 -229847 -229860
  34. Fix? no
  35.  
  36. /dev/sda3: ********** WARNING: Filesystem still has errors **********
  37.  
  38.    85838 inodes used (6.54%)
  39.      658 non-contiguous inodes (0.8%)
  40.          # of inodes with ind/dind/tind blocks: 2734/26/0
  41.   464503 blocks used (8.86%)
  42.        0 bad blocks
  43.        1 large file
  44.  
  45.    55030 regular files
  46.     5334 directories
  47.     3393 character device files
  48.    13603 block device files
  49.        1 fifo
  50.      817 links
  51.     8452 symbolic links (8449 fast symbolic links)
  52.        4 sockets
  53. --------
  54.    86634 files
  55. #

1. Понятное, что самое простое - вместо "N" ответить "Y", и тогда все будет исправлено и почикано в лучшем виде.
Якобы. Поэтому все-таки прежде чем чикать, хотелось бы прежде узнать - какие файлы реально пострадали? Чтобы их лучше сразу выбросить, чем хранить и потом иметь проблемы с их использованием.

2. Если кто-то помнит, в винде когда-то была такая утилита от лаборатории "Диалог-Наука" - Adinf32, которая по запросу или шедулеру проверяла контрольные суммы файлов на жестком диске. Т.е. проверяла их целостность и сохранность - очень важное свойство архивов.
У Касперского, кажется, тоже был подобный проект, Inspector, или как-то иначе.

Что из аналогов есть в нашем любимом линуксе?

PS. Написать скрипт, который только проверяет контрольные суммы файлов, не составляет труда, но по сравнению с расширенными возможностями указанных утилит это очень мало.

Самый безопасный и простой рецепт, которым можно проверить дисковые разделы, в том числе и системный рутовский, и исправить найденные в файловой системе ошибки, обнаружился в команде shutdown:

  1.  shutdown -r -F now

здесь ключ -F после перезагрузки системы принудительно запустит утилиту fsck на тщательную проверку файловых систем имеющихся разделов.

Ваша оценка: Ничего Средняя оценка: 9 (3 votes)
Опубликовано messenger в Чт, 04/03/2010 - 12:27.

Статейка есть гуд спасибки!

Chawoosh аватар
Опубликовано Chawoosh в Пнд, 26/07/2010 - 15:14.

Мда, не заметил раньше...
Как всегда под'.... в сторону якобы лучшего линукса
А по сути: СЕРВЕР на железе от VIA - ЭТО НОНСЕНС. Моё имхо вообще, что этой фирме целиком место в корзине (которая Trash).

King аватар
Опубликовано King в Пнд, 26/07/2010 - 20:21.

А что же по понимаете под сервером - непременно монстрообразный стоечный HP, жрущий энергию почище кипятильника и потому ревущий всеми шестью кулерами ночи напролет?
У нас и такие есть, под CentOS, но совсем для других задач.

Сервер - это содержание, а не форма. Идею использования промышленных VIA в шлюзовых серверах придумал не я - позаимствовал у одного хостера, который забил все стойки этими серверами и они работают у него свыше 6 лет, говорит, выходов из строя практически не было, зато экономия электроэнергии огромная.
Хостинг этот, конечно, своеобразный - вместо того, чтобы ставить десятки монстров, там установили сотни VIA.
Зато в таком решении каждому клиенту - персональный дедик. Мощности, конечно, не те, но такие задачи и не ставились, тут своя особоя ниша спроса и реализации.

Вы видимо, просто не знаете, что такое промышленные VIA, а потому так иронично относитесь к ним.

Chawoosh аватар
Опубликовано Chawoosh в Чт, 29/07/2010 - 07:43.

Знаю, но фирму терпеть не могу.
В наших краях пошли другим путём - облака на базе нормальных серверов, каждому клиенту - по потребностям.
Если сервер стоит в нормально кондиционированной комнате, он своими турбинами не ревёт, поверьте. Только при рестарте.

Опубликовано Mogidin в Вс, 17/10/2010 - 13:08.

Поэтому все-таки прежде чем чикать, хотелось бы прежде узнать - какие файлы реально пострадали?

Восстановление файла с поврежденного ext3 раздела

http://linux-sam.blogspot.com/2009/03/ext3.html

Опубликовано Гость в Чт, 25/06/2020 - 16:43.

Не факт, что на сервере проблемы с дисковой системой. Посмотрите тред
https://www.redhat.com/archives/ext3-users/2002-July/msg00155.html

RSS-материал