Восстановление *nix-систем после сбоя. Linux восстановление файловой системы


Как восстановить файловую систему в fsck

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

Но если питание выключается неожиданно, часть данных теряется, и могут быть потерянны важные данные, что приведет к повреждению самой файловой системы. В этой статье мы рассмотрим как восстановить файловую систему fsck, для нескольких популярных файловых систем, а также поговорим о том, как происходит восстановление ext4.

Содержание статьи:

Немного теории

Как вы знаете файловая система содержит всю информацию обо всех хранимых на компьютере файлах. Это сами данные файлов и метаданные, которые управляют расположением и атрибутами файлов в файловой системе. Как я уже говорил, данные не сразу записываются на жесткий диск, а некоторое время находятся в оперативной памяти и при неожиданном выключении, за определенного стечения обстоятельств файловая система может быть повреждена.

Современные файловые системы делятся на два типа - журналируемые и нежурналируемые. Журналиуемые файловые системы записывают в лог все действия, которые собираются выполнить, а после выполнения стирают эти записи. Это позволяет очень быстро понять была ли файловая система повреждена. Но не сильно помогает при восстановлении. Чтобы восстановить файловую систему linux необходимо проверить каждый блок файловой системы и найти поврежденные сектора.

Для этих целей используется утилита fsck. По сути, это оболочка для других утилит, ориентированных на работу только с той или иной файловой системой, например, для fat одна утилита, а для ext4 совсем другая.

В большинстве систем для корневого раздела проверка fsck запускается автоматически, но это не касается других разделов, а также не сработает если вы отключили проверку.

Основы работы с fsck

В этой статье мы рассмотрим ручную работу с fsck. Возможно, вам понадобиться LiveCD носитель, чтобы запустить из него утилиту, если корневой раздел поврежден. Если же нет, то система сможет загрузиться в режим восстановления и вы будете использовать утилиту оттуда. Также вы можете запустить fsck в уже загруженной системе. Только для работы нужны права суперпользователя, поэтому выполняйте ее через sudo.

А теперь давайте рассмотрим сам синтаксис утилиты:

$ fsck [опции] [опции_файловой_системы] [раздел_диска]

Основные опции указывают способ поведения утилиты, оболочки fsck. Раздел диска - это файл устройства раздела в каталоге /dev, например, /dev/sda1 или /dev/sda2. Опции файловой системы специфичны для каждой отдельной утилиты проверки.

А теперь давайте рассмотрим самые полезные опции fsck:

  • -l - не выполнять другой экземпляр fsck для этого жесткого диска, пока текущий не завершит работу. Для SSD параметр игнорируется;
  • -t - задать типы файловых систем, которые нужно проверить. Необязательно указывать устройство, можно проверить несколько разделов одной командой, просто указав нужный тип файловой системы. Это может быть сама файловая система, например, ext4 или ее опции в формате opts=ro. Утилита просматривает все файловые системы, подключенные в fstab. Если задать еще и раздел то к нему будет применена проверка именно указанного типа, без автоопределения;
  • -A - проверить все файловые системы из /etc/fstab. Вот тут применяются параметры проверки файловых систем, указанные в /etc/fstab, в том числе и приоритетность. В первую очередь проверяется корень. Обычно используется при старте системы;
  • -C - показать прогресс проверки файловой системы;
  • -M - не проверять, если файловая система смонтирована;
  • -N - ничего не выполнять, показать, что проверка завершена успешно;
  • -R - не проверять корневую файловую систему;
  • -T - не показывать информацию об утилите;
  • -V - максимально подробный вывод.

Это были глобальные опции утилиты. А теперь рассмотрим опции для работы с файловой системой, их меньше, но они будут более интересны:

  • -a - во время проверки исправить все обнаруженные ошибки, без каких-либо вопросов. Опция устаревшая и ее использовать не рекомендуется;
  • -n - выполнить только проверку файловой системы, ничего не исправлять;
  • -r - спрашивать перед исправлением каждой ошибки, используется по умолчанию для файловых систем ext;
  • -y - отвечает на все вопросы об исправлении ошибок утвердительно, можно сказать, что это эквивалент a.
  • -c - найти и занести в черный список все битые блоки на жестком диске. Доступно только для ext3 и ext4;
  • -f - принудительная проверка файловой системы, даже если по журналу она чистая;
  • -b - задать адрес суперблока, если основной был поврежден;
  • -p - еще один современный аналог опции -a, выполняет проверку и исправление автоматически. По сути, для этой цели можно использовать одну из трех опций: p, a, y.

Теперь мы все разобрали и вы готовы выполнять восстановление файловой системы linux. Перейдем к делу.

Как восстановить файловую систему в fsck

Допустим, вы уже загрузились в LiveCD систему или режим восстановления. Ну, одним словом, готовы к восстановлению ext4 или любой другой поврежденной ФС. Утилита уже установлена по умолчанию во всех дистрибутивах, так что устанавливать ничего не нужно.

Восстановление файловой системы

Если ваша файловая система находится на разделе с адресом /dev/sda1 выполните:

sudo fsck -y /dev/sda1

Опцию y указывать необязательно, но если этого не сделать утилита просто завалит вас вопросами, на которые нужно отвечать да.

Восстановление поврежденного суперблока

Обычно эта команда справляется со всеми повреждениями на ура. Но если вы сделали что-то серьезное и повредили суперблок, то тут fsck может не помочь. Суперблок - это начало файловой системы. Без него ничего работать не будет.

Но не спешите прощаться с вашими данными, все еще можно восстановить. С помощью такой команды смотрим куда были записаны резервные суперблоки:

sudo mkfs -t ext4 -n /dev/sda1

На самом деле эта команда создает новую файловую систему. Вместо ext4 подставьте ту файловую систему, в которую был отформатирован раздел, размер блока тоже должен совпадать иначе ничего не сработает. С опцией -n никаких изменений на диск не вноситься, а только выводится информация, в том числе о суперблоках.

Теперь у нас есть шесть резервных адресов суперблоков и мы можем попытаться восстановить файловую систему с помощью каждого из них, например:

sudo fsck -b 98304 /dev/sda1

После этого, скорее всего, вам удастся восстановить вашу файловую систему. Но рассмотрим еще пару примеров.

Проверка чистой файловой системы

Проверим файловую систему, даже если она чистая:

sudo fsck -fy /dev/sda1

Битые сектора

Или еще мы можем найти битые сектора и больше в них ничего не писать:

sudo fsck -c /dev/sda1

Установка файловой системы

Вы можете указать какую файловую систему нужно проверять на разделе, например:

sudo fsck -t ext4 /dev/sdb1

Проверка всех файловых систем

С помощью флага -A вы можете проверить все файловые системы, подключенные к компьютеру:

sudo fsck -A -y

Но такая команда сработает только в режиме восстановления, если корневой раздел и другие разделы уже примонтированы она выдаст ошибку. Но вы можете исключить корневой раздел из проверки добавив R:

sudo fsck -AR -y

Или исключить все примонтированные файловые системы:

sudo fsck -M -y

Также вы можете проверить не все файловые системы, а только ext4, для этого используйте такую комбинацию опций:

sudo fsck -A -t ext4 -y

Или можно также фильтровать по опциям монтирования в /etc/fstab, например, проверим файловые системы, которые монтируются только для чтения:

sudo fsck -A -t opts=ro

Проверка примонтированных файловых систем

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

sudo mount -o remount,ro /dev/sdb1

А теперь проверка файловой системы fsck в принудительном режиме:

sudo fsck -fy /dev/sdb1

Просмотр информации

Если вы не хотите ничего исправлять, а только посмотреть информацию, используйте опцию -n:

sudo fsck -n /dev/sdb1

Выводы

Вот и все, теперь вы знаете как выполняется восстановление файловой системы ext4 или любой другой, поддерживаемой в linux fsck. Если у вас остались вопросы, спрашивайте в комментариях!

На десерт сегодня видео на английском про различия файловых систем ext4 и xfs, как обычно, есть титры:

https://www.youtube.com/watch?v=pECp066gGcY

Оцените статью:

Загрузка...

losst.ru

Работа с файловой системой Linux

Во время выполнения различных задач по администрированию системы может понадобится работать с файловой системой Linux, форматировать разделы, изменять их размер конвертировать файловые системы, может понадобиться дефрагментация в Linux или восстановление файловых систем. Многие из этих действий выполняются в графическом интерфейсе, многие и вовсе автоматически. Но может возникнуть ситуация, в которой придется делать все через терминал. Также при администрировании удаленных серверов работать с ними приходится только через ssh, а это означает недоступность графического интерфейса.

В этой статье мы рассмотрим как выполняется работа с файловой системой Linux в терминале. За основу возьмем семейство файловых систем ext2/3/4, так как они самые распространенные среди большого многообразия дистрибутивов Linux.

Содержание статьи:

Основные команды

Для управления файловой системой ext в Linux используется целый набор команд из пакета e2progs. Сюда входят как команды для управления флагами файлов, создания и изменения файловых систем, так и утилиты для отладки файловой системы.

Рассмотрим основные утилиты, которые будем использовать:

  • badblocks - если у вас старый жесткий диск и на нем накопилось много битых блоков, вы можете с помощью этой утилиты пометить их все на уровне файловой системы, чтобы больше не использовать.
  • e2label - позволяет изменить метку раздела с файловой системой ext.
  • fsck - проверка файловой системы linux и исправление найденных ошибок
  • mkfs - позволяет создать файловую систему Linux.
  • resize2fs - изменить размер раздела с файловой системой
  • tune2fs - позволяет изменить файловую систему Linux, настроить ее параметры.

А теперь будет рассмотрена работа с файловой системой linux на примерах.

Работа с файловой системой в Linux

Перед тем как переходить к работе с реальным жестким диском важно попрактиковаться. Если сменить метку или проверить на битые сектора можно и рабочий диск, то создавать новую файловую систему, изменять ее размер, рискуя потерять данные на реальном диске не рекомендуется. Можно отделить небольшой раздел диска для экспериментов с помощью Gparted и выполнять все действия в нем. Допустим, у нас этот раздел будет называться /dev/sda6.

Создание файловой системы

Создать файловую систему linux, семейства ext, на устройстве можно с помощью команды mkfs. Ее синтаксис выглядит следующим образом:

sudo mkfs -t тип устройство

Доступны дополнительные параметры:

  • -с - проверить устройство на наличие битых секторов
  • -b - размер блока файловой системы
  • -j - использовать журналирование для ext3
  • -L - задать метку раздела
  • -v - показать подробную информацию о процессе работы
  • -V - версия программы

Создаем файловую систему на нашем устройстве. Будем создавать ext3:

 sudo mkfs -t ext4 -L root /dev/sda6

Creating filesystem with 7847168 4k blocks and 1962240 inodes

Filesystem UUID: 3ba3f7f5-1fb2-47af-b22c-fa4ca227744aSuperblock backups stored on blocks:32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,4096000

Allocating group tables: doneWriting inode tables: doneCreating journal (32768 blocks): doneWriting superblocks and filesystem accounting information: done  

Изменение метки файловой системы

Утилита e2label позволяет изменить или посмотреть метку раздела диска. Принимает всего два параметра - устройство и новую метку если нужно.

Смотрим метку:

sudo e2label /dev/sda6

root

Устанавливаем новую:

sudo e2label /dev/sda6 root1

Настройка файловой системы linux

Различные параметры файловой системы, такие как размер блока данных, иноды или зарезервированное место под данные пользователя root можно настроить. Для этого существует утилита tune2fs.

Синтаксис команды очень прост:

$ tune2fs опции устройство

Поддерживаются следующие опции:

  • -j - создать файл журнала. Позволяет превратить файловую систему ext2 в ext3.
  • -J - настроить параметры журнала
  • -l - получить содержимое суперблока
  • -L - изменить метку раздела
  • -m - изменить процент дискового пространства, зарезервированного для суперпользователя
  • -M - изменить последнюю папку монтирования
  • -U - задать UUID файловой системы
  • -C - изменить значение счетчика монтирования
  • -T - изменить последнюю дату проверки файловой системы
  • -с - изменить периодичность проверок файловой системы с помощью fsck
  • -O - изменить опции файловой системы.

Изменить размер зарезервированного места для суперпользователя до пяти процентов:

sudo tune2fs -m 5 /dev/sda6

Setting reserved blocks percentage to 5% (392358 blocks)

Посмотреть информацию из суперблока, эта команда показывает всю доступную информацию параметрах файловой системы:

Filesystem volume name:   rootLast mounted on:          /Filesystem UUID:          3ba3f7f5-1fb2-47af-b22c-fa4ca227744aFilesystem magic number:  0xEF53Filesystem revision #:    1 (dynamic)Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isizeFilesystem flags:         signed_directory_hashDefault mount options:    user_xattr aclFilesystem state:         cleanErrors behavior:          ContinueFilesystem OS type:       Linux

Изменить счетчик количества монитрований:

tune2fs -C 0 /dev/sda6

Setting current mount count to 0

Думаю тут смысл понятен, нужно только немного со всем этим поэкспериментировать.

С помощью опции -O мы вообще можем превратить нашу ext3 в ext4 следующей командой:

sudo tune2fs -O extents,uninit_bg,dir_index

После этого действия нужно выполнить проверку файловой системы на ошибки в fsck. Подробнее об этом поговорим ниже.

sudo fsck -np /dev/sda6

Таким образом вы можете изменить файловую систему linux, и настроить по своему усмотрению любые ее параметры.

Изменение размера файловой системы Linux

Раньше такая функция поддерживалась в утилите parted, но потом ее убрали и для этого действия приходится использовать утилиту из набора e2fsprogs - resize2fs.

Запустить утилиту очень просто. Ей нужно передать всего два параметра:

$ resize2fs [опции] устройство размер

Доступны также опции:

  • -M уменьшить файловую систему до минимального размера
  • -f - принудительное изменение, не смотря на потерю данных
  • -F - очистить буфер файловой системы

Размер передается, как и во многих других утилитах, целым числом с указанием единиц измерения, например, 100М или 1G.

Для примера уменьшим размер нашего раздела до 400 Мегабайт:

sudo resize2fs /dev/sda6 400M

Resizing the filesystem on /dev/sda7 to 102400 (4k) blocks.The filesystem on /dev/sda7 is now 102400 blocks long

Проверка файловой системы Linux

При неправильном отключении носителей или неожиданном отключении питания, файловая система Linux может быть повреждена. Обычно проверка корневой файловой системы и домашнего каталога на ошибки выполняется во время загрузки. Но если эта проверка не была выполнена или нужно поверить другой носитель, придется все делать вручную. Для этого есть утилита fsck.

Синтаксис fsck:

$ fsck [опции] устройство

Опции программы:

  • -p - автоматическое восстановление
  • -n - только проверка, без восстановления
  • -y - ответить да на все запросы программы
  • -с - проверить на битые сектора (аналог badblocks
  • -f - принудительная проверка, даже если раздел помечен как чистый
  • -j - внешний журнал файловой системы

Проверка файловой системы Linux выполняется такой командой, проверим диск /dev/sda6, заметьте, что диск должен быть не примонтирован:

sudo fsck -a /dev/sda6

root: clean, 11/32704 files, 37901/102400 blocks

 Дефрагментация файловой системы

Хотя и фрагментация нехарактерное явление для файловых систем семейства ext, при очень интенсивном использовании может накапливаться фрагментированость, что будет замедлять работу файловой системы. Для дефрагментации можно использовать стандартную утилиту e4defrag. Просто выполните:

e4defrag /dev/sda6

Чтобы проверить нужна ли дефрагментация в Linux выполните эту же команду с опцией -c:

Total/best extents                             26247/24953Average size per extent                        1432 KBFragmentation score                            0[0-30 no problem: 31-55 a little bit fragmented: 56- needs defrag]This device (/dev/sda6) does not need defragmentation.Done.

В поле Fragmentation score отображен процент фрагментации, как видите, у меня 0, нормой считается до 30, 31-55 небольшие проблемы, и больше 56 - нужна дефрагментация.

Выводы

В одной из предыдущих статей мы рассмотрели как выполняется разметка диска с помощью parted. Из этой статьи вы узнали все что нужно о работе с файловой системой. Теперь у вас не возникнет проблем если у вас вдруг не будет доступа к графическим утилитам и нужно будет исправлять ошибки или настраивать файловую систему. Если остались вопросы, спрашивайте в комментариях!

Оцените статью:

Загрузка...

losst.ru

Как восстановить файловую систему в fsck

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

Но если питание выключается неожиданно, часть данных теряется, и могут быть потерянны важные данные, что приведет к повреждению самой файловой системы. В этой статье мы рассмотрим как восстановить файловую систему fsck, для нескольких популярных файловых систем, а также поговорим о том, как происходит восстановление ext4.

Немного теории

Как вы знаете файловая система содержит всю информацию обо всех хранимых на компьютере файлах. Это сами данные файлов и метаданные, которые управляют расположением и атрибутами файлов в файловой системе. Как я уже говорил, данные не сразу записываются на жесткий диск, а некоторое время находятся в оперативной памяти и при неожиданном выключении, за определенного стечения обстоятельств файловая система может быть повреждена.

Современные файловые системы делятся на два типа - журналируемые и нежурналируемые. Журналиуемые файловые системы записывают в лог все действия, которые собираются выполнить, а после выполнения стирают эти записи. Это позволяет очень быстро понять была ли файловая система повреждена. Но не сильно помогает при восстановлении. Чтобы восстановить файловую систему linux необходимо проверить каждый блок файловой системы и найти поврежденные сектора.

Для этих целей используется утилита fsck. По сути, это оболочка для других утилит, ориентированных на работу только с той или иной файловой системой, например, для fat одна утилита, а для ext4 совсем другая.

В большинстве систем для корневого раздела проверка fsck запускается автоматически, но это не касается других разделов, а также не сработает если вы отключили проверку.

Основы работы с fsck

В этой статье мы рассмотрим ручную работу с fsck. Возможно, вам понадобиться LiveCD носитель, чтобы запустить из него утилиту, если корневой раздел поврежден. Если же нет, то система сможет загрузиться в режим восстановления и вы будете использовать утилиту оттуда. Также вы можете запустить fsck в уже загруженной системе. Только для работы нужны права суперпользователя, поэтому выполняйте ее через sudo.

А теперь давайте рассмотрим сам синтаксис утилиты:

$ fsck [опции] [опции_файловой_системы] [раздел_диска]

Основные опции указывают способ поведения утилиты, оболочки fsck. Раздел диска - это файл устройства раздела в каталоге /dev, например, /dev/sda1 или /dev/sda2. Опции файловой системы специфичны для каждой отдельной утилиты проверки.

А теперь давайте рассмотрим самые полезные опции fsck:

  • -l - не выполнять другой экземпляр fsck для этого жесткого диска, пока текущий не завершит работу. Для SSD параметр игнорируется;
  • -t - задать типы файловых систем, которые нужно проверить. Необязательно указывать устройство, можно проверить несколько разделов одной командой, просто указав нужный тип файловой системы. Это может быть сама файловая система, например, ext4 или ее опции в формате opts=ro. Утилита просматривает все файловые системы, подключенные в fstab. Если задать еще и раздел то к нему будет применена проверка именно указанного типа, без автоопределения;
  • -A - проверить все файловые системы из /etc/fstab. Вот тут применяются параметры проверки файловых систем, указанные в /etc/fstab, в том числе и приоритетность. В первую очередь проверяется корень. Обычно используется при старте системы;
  • -C - показать прогресс проверки файловой системы;
  • -M - не проверять, если файловая система смонтирована;
  • -N - ничего не выполнять, показать, что проверка завершена успешно;
  • -R - не проверять корневую файловую систему;
  • -T - не показывать информацию об утилите;
  • -V - максимально подробный вывод.

Это были глобальные опции утилиты. А теперь рассмотрим опции для работы с файловой системой, их меньше, но они будут более интересны:

  • -a - во время проверки исправить все обнаруженные ошибки, без каких-либо вопросов. Опция устаревшая и ее использовать не рекомендуется;
  • -n - выполнить только проверку файловой системы, ничего не исправлять;
  • -r - спрашивать перед исправлением каждой ошибки, используется по умолчанию для файловых систем ext;
  • -y - отвечает на все вопросы об исправлении ошибок утвердительно, можно сказать, что это эквивалент a.
  • -c - найти и занести в черный список все битые блоки на жестком диске. Доступно только для ext3 и ext4;
  • -f - принудительная проверка файловой системы, даже если по журналу она чистая;
  • -b - задать адрес суперблока, если основной был поврежден;
  • -p - еще один современный аналог опции -a, выполняет проверку и исправление автоматически. По сути, для этой цели можно использовать одну из трех опций: p, a, y.

Теперь мы все разобрали и вы готовы выполнять восстановление файловой системы linux. Перейдем к делу.

Как восстановить файловую систему в fsck

Допустим, вы уже загрузились в LiveCD систему или режим восстановления. Ну, одним словом, готовы к восстановлению ext4 или любой другой поврежденной ФС. Утилита уже установлена по умолчанию во всех дистрибутивах, так что устанавливать ничего не нужно.

Восстановление файловой системы

Если ваша файловая система находится на разделе с адресом /dev/sda1 выполните:

Опцию y указывать необязательно, но если этого не сделать утилита просто завалит вас вопросами, на которые нужно отвечать да.

Восстановление поврежденного суперблока

Обычно эта команда справляется со всеми повреждениями на ура. Но если вы сделали что-то серьезное и повредили суперблок, то тут fsck может не помочь. Суперблок - это начало файловой системы. Без него ничего работать не будет.

Но не спешите прощаться с вашими данными, все еще можно восстановить. С помощью такой команды смотрим куда были записаны резервные суперблоки:

$ sudo mkfs -t ext4 -n /dev/sda1

На самом деле эта команда создает новую файловую систему. Вместо ext4 подставьте ту файловую систему, в которую был отформатирован раздел, размер блока тоже должен совпадать иначе ничего не сработает. С опцией -n никаких изменений на диск не вноситься, а только выводится информация, в том числе о суперблоках.

Теперь у нас есть шесть резервных адресов суперблоков и мы можем попытаться восстановить файловую систему с помощью каждого из них, например:

$ sudo fsck -b 98304 /dev/sda1

После этого, скорее всего, вам удастся восстановить вашу файловую систему. Но рассмотрим еще пару примеров.

Проверка чистой файловой системы

Проверим файловую систему, даже если она чистая:

$ sudo fsck -fy /dev/sda1

Битые сектора

Или еще мы можем найти битые сектора и больше в них ничего не писать:

Установка файловой системы

Вы можете указать какую файловую систему нужно проверять на разделе, например:

$ sudo fsck -t ext4 /dev/sdb1

Проверка всех файловых систем

С помощью флага -A вы можете проверить все файловые системы, подключенные к компьютеру:

Но такая команда сработает только в режиме восстановления, если корневой раздел и другие разделы уже примонтированы она выдаст ошибку. Но вы можете исключить корневой раздел из проверки добавив R:

Или исключить все примонтированные файловые системы:

Также вы можете проверить не все файловые системы, а только ext4, для этого используйте такую комбинацию опций:

$ sudo fsck -A -t ext4 -y

Или можно также фильтровать по опциям монтирования в /etc/fstab, например, проверим файловые системы, которые монтируются только для чтения:

$ sudo fsck -A -t opts=ro

Проверка примонтированных файловых систем

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

$ sudo mount -o remount,ro /dev/sdb1

А теперь проверка файловой системы fsck в принудительном режиме:

$ sudo fsck -fy /dev/sdb1

Просмотр информации

Если вы не хотите ничего исправлять, а только посмотреть информацию, используйте опцию -n:

Выводы

Вот и все, теперь вы знаете как выполняется восстановление файловой системы ext4 или любой другой, поддерживаемой в linux fsck. Если у вас остались вопросы, спрашивайте в комментариях!

xpressdnepr.blogspot.com

Проверка ФС и восстановление удалённых файлов в Linux

Linux — одна из самых надёжных операционных систем, которую вы когда-либо видели, однако это вовсе не означает, что оборудование на котором работает Linux такое же надёжное. Жёсткие диски могут работать с ошибками и как следствие — вы получите ошибки на ваших файловых системах. Неважно насколько надёжна ваша операционная система, если вы случайно удалили нужные файлы или каталоги. Однако нее отчаивайтесь, если с вами произошло нечто подобное. Linux располагает всем необходимым, чтобы помочь вам восстановить потерянные файлы в результате удаления или сбоев в работе дисков и файловых систем. О каких инструментах идёт речь? Первым делом мы рассмотрим с вами утилиты e2fsck, scalpel и lsof. В сегодняшней заметке мы с вами посмотрим, как при помощи такого набора инструментов можно исправлять ошибки ФС и восстанавливать удалённые файлы.

Проверка ФС ext2/ext3/ext4 при помощи e2fsck

Утилита e2fsck является потомком известной UNIX-утилиты fsck, предназначенной для проверки файловых систем. При помощи e2fsck вы можете проверять на наличие ошибок и выполнять восстановительные работы в файловых системах ext2/ext3/ext4.

Одним из наиболее важных моментов в работе с e2fsck является то, что при помощи неё работы можно проводить только на отмонтированной файловой системе, в противном случае вы можете получить себе ещё больше головной боли, о чём и предупреждает сама утилита при попытке запуска её для работы на смонтированной ФС. Если проверяемая ФС не является корневой, то вы можете завершить работу всех пользователей, переключиться в однопользовательский режим (init 1), отмонтировать ФС и работать с ней.

Однако автор всё же рекомендует воспользоваться каким-нибудь live-дистрибутивом и, загрузившись с него, выполнять все работы. Используя этот метод вы получите в своё полное распоряжение несмонтированные ФС без необходимости выполнять какие-то дополнительные действия.

Если же вы по каким-то причинам выбираете первый вариант, то после того, как перейдёте в однопользовательский режим:

отмонтируйте нужную для работы файловую систему:

и после успешного размонтирования запускайте  e2fsck:

Опция '-y' сообщает утилите e2fsck о том, что мы заранее согласны со всеми её вопросами и уходим пить кофе, в надежде что она самостоятельно всё сделает. В зависимости от размера файловой системы проверка и восстановление могут занять некоторое время. После окончания проверки вы всегда можете запустить тест ещё раз, чтобы убедиться в том, что не в ФС не возникло новых ошибок, что может быть вызвано аппаратными проблемами накопителя.

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

Восстановление удалённых файлов при помощи /proc и lsof

Теперь давайте рассмотрим процесс восстановления удалённых файлов. Вообще, причиной тому что вы можете восстановить удалённый файл является тот факт, что «файл» — это лишь ссылка на индексный дескриптор файла (inode). Именно в inode хранится информация о физическом размещении файла. Когда вы удаляете файл, фактически вы просто удаляете ссылку на inode, в то время как сам дескриптор ещё какое-то время будет существовать: до тех пор, пока процесс, ранее открывший этот файл не освободит соответствующий дескриптор для записи. Таким образом, есть какое-то время, пусть и короткое, в течение которого можно восстановить содержимое удалённого файла. Ключом в этом процессе является файловая система /proc, содержащая среди всего прочего информацию обо всех выполняющихся в системе процессах и открытых ими файлах. Каждый процесс, работающий в системе имеет соответствующий его PID каталог в /proc. Зная PID процесса, всё ещё держащего открытым удалённый файл, мы всегда можем восстановить его содержимое из каталога /proc/[pid]/ открывшего его процесса. Давайте на простом примере посмотрим, как это делается.

Сперва давайте создадим какой-нибудь файл:

$ echo 'Очень важные данные' > ~/myfile.txt

$ echo 'Очень важные данные' > ~/myfile.txt

Теперь у нас есть файл myfile.txt с важными данными, расположенный в домашнем каталоге. Давайте попробуем удалить его и затем восстановить следующим образом. Сначала мы откроем файл для просмотра командой less, после чего приостановим её работу, оставив таким образом нужный нам файл открытым. Итак, пошагово.

Откройте файл командой less для просмотра

После того, как файл будет открыт и вы увидите его содержимое, нажмите Ctrl+z , чтобы приостановить выполнение less.

Удалите файл:

Убедитесь в том, что файла больше нет

Поскольку работа ранее запущенной нами less ещё не завершена, то файл остаётся для неё открытым и фактически не удалён. Давайте восстановим его.

Для начала необходимо узнать PID процесса, открывшего файл и номер файлового дескриптора. Сделать это можно при помощи программы lsof:

$ lsof | grep myfile.txt less 2675 ashep 4r REG 8,1 37 294478 /home/ashep/myfile.txt (deleted)

$ lsof | grep myfile.txt

less      2675      ashep    4r      REG    8,1      37 294478 /home/ashep/myfile.txt (deleted)

Во втором поле вывода lsof содержится PID — 2675, а в четвёртом номер дескриптора — 4. Теперь можно приступать к восстановлению:

$ cp /proc/2675/fd/4 ~/recovered.txt

$ cp /proc/2675/fd/4 ~/recovered.txt

Проверьте, то ли содержимое находится в файле, которое нам нужно:

$ cat ~/recovered.txt Очень важные данные

$ cat ~/recovered.txt

Очень важные данные

Как видим, всё прошло успешно и нам удалось восстановить удалённый файл.

Восстановление удалённых файлов при помощи Scalpel

После того как процесс, открывший файл, завершится, восстановление файла становится задачей потруднее, поскольку индексный дескриптор освобождается и всякая связь между данными в блоках на диске и файловой системой потеряна. До тех пор, пока данные физически не будут перезаписаны на диске, существует возможность их восстановления при помощи утилиты Scalpel. Этот инструмент последовательно, блока за блоком, обходит содержимое диска и анализирует его содержимое, пытаясь найти признаки существования там файлов. Для поиска Scalpel использует шаблоны из последовательности байт, присущих определённым типам файлов. Например, PNG-файлы содержат в заголовке последовательность байт \x50\x4e\x47.

Scalpel вы найдёте в репозиториях большинства современных дистрибутивов. После установки утилиты первым делом нужно определиться с тем, какие файлы программа будет искать при работе. Определения шаблонов для поиска находятся в файле /etc/scalpel/scalpel.conf. По умолчанию содержимое файла целиком закомментировано и прежде чем начать работу вам необходимо раскомментировать нужные шаблоны и/или добавить свои. Формат описания шаблона довольно прост:

extension case_sensitive size header [footer]

extension  case_sensitive  size  header  [footer]

где

  • extension определяет расширение файла, которое Scalpel будет дописывать при восстановлении;
  • case_sensitive указывает утилите, имеет ли значение регистр символов в шаблоне поиска;
  • при помощи size определяется максимальный размер восстанавливаемых файлов;
  • в header и необязательном footer описываются последовательности заголовка файла и нижней его части соответственно.

Например, определение шаблона для JPG-файлов может выглядеть так:

jpg y 200000000 \xff\xd8\xff\xe0\x00\x10 \xff\xd9

jpg  y  200000000  \xff\xd8\xff\xe0\x00\x10  \xff\xd9

После того, как внесёте необходимые изменения в конфигурационный файл Scalpel и подготовите пустую (обязательно!) директорию для сохранения найденных файлов, можно запускать процесс поиска и восстановления:

# scalpel -o ~/recovered /dev/sdb1

# scalpel -o ~/recovered /dev/sdb1

где при помощи опции '-o' определяется путь к каталогу для сохранения найденных файлов. Процесс работы утилиты как правило очень долгий, поскольку она сканирует всё устройство целиком, поэтому воспользуйтесь моментом и сходите прогуляться на улицу, свежий воздух ещё никому не мешал ;)

После того, как Scalpel завершит свою работу, изучите содержимое выходного каталога на предмет наличия в нём нужных вам файлов.

Заключение

Мало кто хотел бы попасть в ситуацию, когда важные данные окажутся случайно удалёнными или повреждёнными. И хотя Linux предлагает средства для восстановления утраченных данных, приятного в этом процессе мало. Поэтому будьте всегда предельно внимательны к своим данным и работе с ними. Ну и, конечно же, не забывайте про своевременное резервное копирование — старый и проверенный метод, спасший не одну тысячу нервных клеток от верной гибели.

По материалам с linux.com

ashep.org

Восстановление *nix-систем после сбоя - «Хакер»

Когда происходит сбой в системе и она перестает загружаться, многие пользователи не знают, что делать. Конечно, лучше вообще не допускать таких ситуаций, но, если уж подобное случилось, нужно воспринять это как данность и разобраться в проблеме.

 

Для начала стоит рассмотреть, какие вообще бывают нештатные ситуации, после которых система не грузится. Условно их можно разделить на четыре вида:

  1. Сбой файловой системы
  2. Некорректное обновление дистрибутива. Конечно, именитые компании, такие как Canonical или Red Hat, очень стараются не допускать подобных ситуаций, но ведь и на старуху бывает проруха.
  3. Некорректно сконфигурированная графическая подсистема и/или кривые драйверы, чаще всего проприетарные.
  4. Невнимательность пользователя. О, чего тут только нет! Перечислю основные возможности сломать систему:
    • забыть пароль root (как вариант — свой собственный) или загрузчика;
    • перезаписать таблицу разделов;
    • удалить какой-нибудь крайне важный файл;
    • установить программу из неизвестного источника. Справедливости ради надо сказать, что если пользователь компилирует из-под своей учетной записи и ставит программы исключительно в свой домашний каталог (что, впрочем, бывает крайне редко), то максимум, что сможет сделать эта программа, — занять все ресурсы и/или запороть конфиги в домашнем каталоге (необходимо отметить, что это верно именно для криво написанных программ, не для зловредов).

Это, пожалуй, самые распространенные варианты сбоя, после которого может понадобиться реанимировать систему. Рассмотрим теперь, как это делать.

Для Linux способы сброса паролей пользователей разнятся от дистрибутива к дистрибутиву. Далее я опишу самый универсальный метод.

В загрузочном меню GRUB выдели дистрибутив и нажми клавишу . Затем выбери строку, начинающуюся с kernel, и снова нажми (в случае с GRUB2 — linux и повторно нажимать не надо). В конце строки допиши init=/bin/sh. Эта команда запускает вместо init/systemdпроцесс оболочки, в котором ты можешь изменить пароль. Но перед этим тебе необходимо перемонтировать ФС в режиме чтения/записи, для чего выполни следующую команду:

# /sbin/mount -no remount,rw /

Уже после этого ты можешь выполнить команду passwd или ее же, но с именем пользователя в качестве аргумента. После этого нужно перезагрузиться — но команды shutdown/reboot в этом режиме не всегда работают. Выход есть: используй клавишу , Люк! А именно — зажимая клавиши и , с интервалом в 3–4 секунды нажми следующие буквы: R E I S S U B. Итогом будет перезагрузка, и после нее ты сможешь заходить под новым паролем.

В FreeBSD ситуация сложнее. Обычно советуют грузиться в однопользовательском режиме и оттуда уже менять пароль. Однако если в файле /etc/ttys консоль отмечена как insecure, то этот метод, очевидно, не подходит, и тут не обойтись без LiveCD (в параметрах ядра, которые могут быть установлены в загрузчике, есть переменная kern.init_path, но сброс, а затем присвоение этой переменной пути к какой-либо оболочке ни на что не влияет). Рассмотрим, как именно сбросить пароль с его помощью.

  • Качаем (и записываем) Frenzy и грузимся с него.
  • Подключаем разделы FreeBSD в режиме чтение/запись.
  • Делаем chroot на подмонтированную ФС.
  • Делаем резервные копии файлов passwd, master.passwd, pwd.db и spwd.db.
  • Задаем команду passwd и ставим пароль.
  • Выходим из chroot, задаем команду sync, отмонтируем и перезагружаемся.

В случае с потерей пароля на GRUB/GRUB2 тебе необходимо загрузиться с LiveCD и поставить другой пароль. Для GRUB2 это делается путем редактирования файла/boot/grub/grub.cfg (после перезагрузки не забудь поставить новый зашифрованный пароль в соответствующий файл в /etc/grub.d/):

# <...> set superusers="root" # Забытый пароль #password_pbkdf2 root grub.pbkdf2.sha512.10000.FD7709726BA498BA0A116E09217D1B3D9D677605546EA2BFAD134581877694B3A8DC7AE0AAC1EBA51A2B8C153EF970617DB126D2B0860A9B0C0F9EA6769385C8.E43348DB1945B9428704A43685B9B41DCB0027098BFC33AE67FADFB1E78F5AABD757FAB9CD5D3A448100AF7B20E45DF958102A84B6CDE42D0225088567DEAC32 # Новый пароль (для упрощения изменения его мы не хешируем) password root newpass # <...>

Для старого GRUB достаточно заменить в файле /boot/grub/menu.lst строку password —md5 password_hash на password newpass.

Та самая строчка, которая влияет на ввод пароля в однопользовательском режиме в FreeBSD

В случае порчи загрузчика сперва нужно определить, какой из них используется в твоей системе. Как правило, в Ubuntu, начиная с версии 9.10, используется вторая версия GRUB. Однако проверить это нетрудно. Прежде всего загрузись с LiveCD и пробрось chroot. О том, как это сделать, написано в одном из следующих разделов. Помни, что в случае, если /bootнаходится на отдельном разделе, его также необходимо подмонтировать. Наиболее ярким индикатором, что установлен GRUB2, служит присутствие каталога /etc/grub.d/. Для полной же уверенности проверь также наличие файла grub-mkpasswd-pbkdf2 и отсутствиеgrub-crypt с помощью команды whereis.

В случае если в качестве загрузчика используется вторая версия GRUB и ты точно уверен, что он установлен, к примеру на /dev/sda, набирай следующую команду:

# grub-install /dev/sda

Если возникли ошибки, могут помочь опции проверки device map ‘—recheck’ и отключения проверки наличия флоппи-дисковода ‘—no-floppy’.

Для установки GRUB Legacy используй ту же самую команду. Замечу, что опция ‘—recheck’ в версии программы для grub-legacy недоступна.

Эта ситуация неприятна еще и тем, что иногда ее видно не сразу. В идеале конфигурационные файлы в пределах одной версии дистрибутива не должны меняться. Реальный мир, тем не менее, вносит свои корректировки — даже несмотря на то, что разработчики LTS-версий дистрибутива стараются делать бэкпортирование как можно более безболезненным, это не всегда получается. Наиболее правильный способ решить эту проблему — почитать логи и поправить конфиги. Но если этой возможности нет, остается только даунгрейд.

В системах, основанных на RHEL, даунгрейд можно осуществить сразу несколькими путями. Самый древний метод — использовать опцию ‘—rollback’ RPM. Например, для отката изменений на неделю назад необходимо выполнить следующую команду:

# rpm -Uvh --rollback '1 week ago'

Этот метод, однако, по современным меркам весьма неудобен, особенно если учитывать, что сейчас все пользуются yum. Для даунгрейда пакета с помощью yum можно использовать команду yum downgrade. Например, так:

# yum downgrade samba-common

Замечу, что зависимости не даунгрейдятся, и их нужно указывать вместе с пакетом, который подвергается этой операции.

В системах новее RHEL6 есть еще один метод, основанный на истории действий yum. Для его применения нужно прежде всего задать следующую команду:

# yum history

Затем посмотреть номер действия, убедиться, что это именно то действие, и откатиться:

# yum history info 38 # yum history undo 38 История действий yum

Для Ubuntu (и других систем, использующих apt-get) нужно сначала удалить пакет, а затем установить нужную версию (перед этим обязательно сохраняй конфиги!):

# apt-get remove php # apt-get install php=5.3.2

Нужно учесть, что для ядер это не подходит — новые ядра именно устанавливаются, а не обновляются.

В случае с портами FreeBSD существует утилита portdowngrade, которая, впрочем, сейчас служит в качестве фронтенда к subversion, то есть для ее использования необходимо, чтобыsvn был установлен. Использовать ее очень просто — сперва мы ищем ту ревизию, к которой нужно откатиться, затем откатываемся и ставим этот порт:

# /usr/local/sbin/portdowngrade emulators/dosbox # /usr/local/sbin/portdowngrade emulators/dosbox 251605 # cd /usr/ports/emulators/dosbox # make deinstall install clean Откат порта в FreeBSD

Восстановление удаленных файлов сильно зависит от файловой системы, и гарантии, что ты их восстановишь, нет никакой. Вначале опишу восстановление данных с ext2/3/4 под Ubuntu. Первым делом, если ты обнаружил, что какой-то файл удален, сразу насильно выключай компьютер — и чем раньше ты обнаружишь это, тем лучше. Затем грузись с LiveCD и установи программу extundelete:

$ sudo apt-get install extundelete

Если у тебя есть раздел, куда восстанавливать, подмонтируй его, перейди в соответствующий каталог и набери следующую команду:

$ sudo extundelete --restore-all /dev/sda3

Если же у тебя нет раздела, в который можно помещать восстанавливаемые файлы… тогда вместо —restore-all напиши —restore-file. Например, так:

$ sudo extundelete --restore-file /etc/shadow /dev/sda3

Отмечу, что путь к файлу задается относительно его корня — то есть если у тебя отдельный раздел /boot и ты случайно удалил файл /boot/grub/grub.cfg, то в качестве восстанавливаемого файла будет фигурировать /grub/grub.cfg.

В случае с Btrfs в версиях выше, чем 0.20, имеется команда btrfs restore. К сожалению, по умолчанию она не может восстанавливать конкретные файлы – для этого необходима сборкаbtrfs-progs от josefbacik. Пример использования:

$ sudo btrfs restore /dev/sda9 /mnt/restore

Что до FreeBSD, то ситуация с ней сложнее. Для восстановления удаленных данных в стандартной поставке ничего нет, поэтому берем какой-нибудь LiveCD — да тот же Ubuntu — и ставим пакет testdisk, в составе которого имеется photorec. К сожалению, эта программа (пока?) не понимает формата разделов и слайсов FreeBSD и его файловую систему. Тем не менее это не мешает им пользоваться. Запустим ее для раздела sda3:

$ sudo photorec /dev/sda3

В появившемся меню нажмем — поскольку мы уже выбрали раздел — и затем выберем Options». Там включаем опции по вкусу, выйдем из меню и вперед — жмем Search. Перед поиском photorec попросит указать каталог, куда сохранять. Разумеется, процесс это небыстрый, поэтому запасись терпением.

INFO

В пакет testdisk, помимо photorec, входит собственно сам testdisk — утилита, позволяющая восстанавливать случайно удаленные разделы из таблицы разделов. Помимо этих методов, есть еще один метод, почти универсальный для *nix-систем. Этот метод не требует немедленного отключения питания. Но не спеши радоваться, он доступен только в том случае, если ты удалил файл, открытый в другом приложении. Для восстановления файла тебе нужно узнать PID приложения, перейти в каталог/proc/<PID>/fd, найти ссылку на удаленный файл и с помощью cat его восстановить. Photorec в работе

INFO

В случае работы с поврежденными ФС необходимо быть чрезвычайно осторожным. Трижды убедись, что ты понимаешь, что делаешь.

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

Рассмотрим первую ситуацию (сбой питания) для ext4. В общем-то, эти методы работают при любой вышеперечисленной ситуации. Если система вообще не стартует, нужно загрузиться с LiveCD и по возможности скопировать образ раздела. Затем набираем в консоли следующую команду (предполагается, что ФС находится на sda7):

$ sudo fsck.ext4 -f /dev/sda7

Если все хорошо, то fsck будет задавать вопросы. Все нормально. Главное, чтобы их не было слишком много. Но если fsck ругается на некорректный суперблок… то и тут не стоит отчаиваться. Для начала узнаем, в каких блоках находятся резервные суперблоки, для чего используем стандартную команду mkfs.ext4:

$ sudo mkfs.ext4 -n /dev/sda7

Команда эта, как правило, создает новую файловую систему и во время этой процедуры пишет местонахождение резервных суперблоков. Нам, разумеетcя, не надо создавать ФС. Но запуск с опцией -n ее и не создает, а всего лишь показывает процесс создания — а заодно и выводит список резервных суперблоков (он, в свою очередь, зависит от размера блока). Допустим, размер блока у нас равен 4 Кб. Тогда мы снова задаем команду fsck.ext4:

$ sudo fsck.ext4 -f -b 32767 /dev/sda7

Опция -b указывает резервный суперблок, список которых мы получили из вывода предыдущей команды.

Просмотр списка резервных суперблоков с помощью mkfs

Если же и это не помогает (или хочется ручками попробовать восстановить), тогда пришло время для тяжелой артиллерии. В качестве таковой выступает связка утилит dumpe2fs,tune2fs и debugfs. Их описание выходит за рамки данной статьи, но не упомянуть их я не могу. Кроме того, у команды mkfs.ext4 есть ключ ‘-S’, который инициализирует только суперблок и группы блоков, но не таблицы инодов. После этого нужно запустить fsck. При использовании этого способа помни — размер блока должен совпадать со старым, иначе шансы на восстановление значительно уменьшатся.

В случае с Btrfs набор утилит для восстановления очень и очень скуден. Тем не менее некоторые средства все же имеются. Опишу опции монтирования, относящиеся к восстановлению:

  • опция монтирования recovery (доступна начиная с ядра 3.2) позволяет Btrfs при сбое сканировать предыдущие корни бинарных деревьев и по возможности использовать первый неповрежденный;
  • degraded — для систем на нескольких устройствах (RAID-массив средствами Btrfs). Если одно устройство по каким-то причинам недоступно, эта опция позволяет смонтировать ФС и добавить новое устройство;
  • skip_balance (доступна с ядра 3.4) отключает балансировку данных и метаданных. Использование этой опции имеет смысл, если питание было отключено внезапно и у тебя опять же ФС на нескольких устройствах — для ФС на одном устройстве операция балансировки не имеет смысла.

В FreeBSD fsck_ufs для указания резервного суперблока принимает тот же параметр -b’, что и в Linux. А вот у утилиты newfs, в отличие от ее аналога mkfs.ext4, для просмотра информации о создаваемой ФС без фактического ее создания используется ключ ‘-N’. Ключа, аналогичного описанному выше ‘-S’, нет вообще. Для ручного восстановления используй аналогичную связку из утилит dumpfs, tunefs и fsdb.

Для ZFS ситуация с утилитами восстановления хотя и более печальная, чем в случае с классическими ФС, но с Btrfs несравнима. И это при том, что субъективно Btrfs куда более сырая. Команды fsck в ней нет, но ее ближайшим аналогом служит команда zpool scrub, которая проверяет контрольные суммы всех занятых блоков пула. Для просмотра информации в уберблоке (примерном аналоге суперблока) используется утилита zdb. В случае критического повреждения пула используй команду zpool clear -F.

Просмотр возможностей файловой системы с помощью debugfsАналог debugfs в FreeBSD

Действия в этой ситуации зависят от того, как именно ты ставил это ПО и загружается ли система вообще. Если система не загружается, в случае Ubuntu имеет смысл загрузиться с LiveCD и, подмонтировав корневую ФС, сделать chroot:

# mount --bind /proc /media/ubuntu-root/proc # mount --bind /sys /media/ubuntu-root/sys # mount --bind /media/ubuntu-root/dev # chroot /media/ubuntu-root

Затем просмотреть, если ты ставил это неизвестное ПО с репозитория, список пакетов, которые недавно были установлены, для чего открыть файл /var/log/apt/history.log и с помощью apt-get удалить данный пакет. Если же ты устанавливал из исходных кодов, а система не загружается даже в однопользовательском режиме, скорее всего, ты установил какой-то модуль ядра, который прописался в initramfs. Чтобы от него избавиться, посмотри каталог /etc/initramfs-tools/, в частности файл modules. После устранения подозрительных строк обнови initramfs:

# update-initramfs -k all -u

Если система все же загружается в однопользовательском режиме, значит, дело в каком-то init-скрипте. Для просмотра свежесозданных файлов в каталоге /etc/init.d/ используй команду ls -t, затем, после обнаружения службы, отключи ее с помощью команды update-rc.d имя_службы purge. Затем перейди в каталог сборки и попробуй дать команду make uninstall. Не факт, что сработает, но попытаться стоит.

Эти проблемы относятся к проприетарным драйверам. Разумеется, сейчас они возникают довольно редко, но все же возникают. Рассмотрю, например, ситуацию, когда вместо нормального изображения драйвер NVIDIA после запуска показывает по центру монитора полосу примерно в половину ширины экрана с прерывистыми диагональными линиями на ней. Если после ее появления переключиться на консоль и обратно, изображение нормализуется. Для исправления этой ситуации нужно принудительно выставить графический режим путем добавления параметра ядра. В файле /etc/default/grubдобавляем в переменную GRUBCMDLINELINUX_DEFAULT параметр vga=0x314. Должна получиться следующая строка:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash vga=0x314"

Не забываем перегенерировать грабовский конфиг:

$ sudo update-grub

Еще одна проблемная ситуация может возникнуть, если драйвер неверно определяет разрешение монитора. Для ее решения есть два пути. Первый — добавить следующие строчки в файл /etc/X11/xorg.conf в секцию Screen:

SubSection "Display" Depth 24 Modes "1920x1200" EndSubSection

Разрешение, естественно, нужно подставить желаемое. Но файл xorg.conf считается устаревшим, поэтому рекомендую использовать комбинацию ~/.xprofile и команды xrandr. Создай файл ~/.xprofile со следующим содержимым:

xrandr --output VGA-0 --mode 1024x768 --rate 60

Конечно, в твоем случае опция —output (как и разрешение) может отличаться. Чтобы узнать точно, куда подключен монитор, набери xrandr без параметров.

LiveCD для восстановления системы

Cуществует несколько LiveCD-дистрибутивов для восстановления системы. Кратко опишу два из них.

Grml — LiveCD, основанный на Debian. Поддерживает как x86-, так и x64-системы. Может быть установлен на флешку. Из особенностей:

  • По умолчанию в качестве оболочки используется ZSH, а в качестве WM — Fluxbox.
  • USB-установка поддерживает сохранение конфигов (на флешке при этом нужно создать два раздела).
  • Есть пакет sleuthkit, предназначенный как для восстановления данных, так и для компьютерных криминалистов.

SystemRescueCD основан на Gentoo. Последняя его версия, 3.8.0, выпущенная в сентябре этого года, имеет следующие особенности:

  • Ядра как x86, так и x64, причем двух версий — Standard (3.4.62) и Alternative (3.10.12).
  • В качестве рабочего стола используется Xfce.
  • Помимо Linux, в меню загрузки имеются также некоторые образы дискет, например MHDD.

Все это добро умещается на 420 Мб.

WWW

Информация о структуре и нововведениях ext4: bit.ly/fjbdB8

В этой статье я попытался описать самые частые и наиболее пугающие проблемы, которые могут возникнуть при работе в современных дистрибутивах Linux и FreeBSD. По сравнению с тем, что было раньше, этот список заметно поубавился. Тем не менее я не описал проблем, связанных с железом (видеодрайверы не в счет), — во-первых, потому, что оно у всех разное, а во-вторых — их нужно по возможности предотвращать, иначе, когда они себя проявят, уже будет поздно.

xakep.ru

Linux восстановление файлов | schel4koff.ru

    Linux восстановление файлов. Оптимизации, которые предоставляют файловые системы Unix, становятся возможными благодаря сложному механизму, аналогичному базе данных. Для файловых систем, работающих без ошибок, ядро видит, что в установленной файловой системе нет никаких ошибок. С другой стороны, встречаются серь­езные ошибки вроде потери данных и сбоев системы.

   Наиболее часто встречающаяся причина ошибки файловой системы это жесткое завершение работы системы (например, при отключении питания на компьютере). Кэш в файловой системе может не найти данных на диске, и система также может находиться в процессе изменения файловой системы в момент, когда вы решили сделать компьютеру перезагрузку. Несмотря на то, что новое поколение файловых систем поддерживает журналы, чтобы сделать повреждение файловых систем менее вероятным, вам всегда следует завер­шать работу системы в правильном порядке. Более того, провер­ки файловых систем можно рассматривать как профилактическую меру, средство контроля ПО на отсутствие незначительных ошибок.

Вам следует запомнить одно имя команды для проверки файловой систе­мы: fsck. Однако, существуют различные версии этого инструмента для каж­дого типа файловых систем, поддерживаемых Linux. Представленная здесь информация характерна для файловых систем вторичного и третичного рас­ширения (ext2/ext3). А также для утилиты e2fsck. Вообще, вам не нужна e2fsck, если только fsck не может выяснить тип файловой системы, или вы ищете страницу руководства e2fsck.

Чтобы запустить fsck в ручном интерактивном режиме, воспользуйтесь уст­ройством или точкой монтирования (в /etc/fstab) как аргументом. Например:fsck /dev/hddl

Никогда не используйте fsck на подмонтированной файловой системе. Ядро может видоизменить данные на диске, когда вы запустите проверку, вызывая несоответст­вия, которые могут привести к сбою вашей системы и повредить файлы. Есть только одно исключение. Если вы подмонтировали корневой каталог в пользовательском режиме только для чтения, вы можете использовать fsck на корневой файловой сис­теме.В ручном режиме fsck печатает многословные сообщения о состоянии по выполняемым операциям.

Если fsck найдет проблему в ручном режиме, она остановится и задаст вам вопрос в соответствии с устранением проблемы. Эти вопросы касаются внутренней структуры файловой системы, такой как перестройка соединений и очистка блоков. Перестройка означает, что fsck нашла файл, который, похо­же, не имеет имени; перестройка помещает файл в каталог lost+found файло­вой системы как номер. Вам нужно выяснить имя, основываясь на содержи­мом файла.

Как правило, бессмысленно проводить процесс fsck если вы просто совершили ошибку жесткого завершения работы. e2fsck имеет опцию -р, ко­торая автоматически исправляет глупые ошибки не спрашивая вас об этом, и завершаясь в случае серьезной ошибки. Это так широко распространено, что версии Linux запускают свой вариант -р во время загрузки (fsck -а тоже иногда встречается).

Однако, если вы подозреваете, что произошла катастрофа, вроде сбоя аппаратного обеспечения или неправильный выбор конфигурации устройства; вам нужно определить направление действий, так как в этом случае fsck мо­жет только запутать файловую систему еще больше. Намек на серьезную про­блему — это очень большое количество вопросов в ручном режиме.

Если вы действительно думаете, что случилось что-то ужасное, попробуйте запустить fsck -n, чтобы проверить файловую систему, ничего не изменяя. Ес­ли есть какая-то проблема с конфигурацией устройства (неправильное число блоков в таблице разделов, кабель отошел или еще что-нибудь), которую вы можете самостоятельно устранить, то сделайте это до запуска fsck. Иначе, вы рискуете потерять изрядное количество данных.

Если вы подозреваете, что только суперблок, ключ базы данных компонен­тов файловой системы поврежден (например, кто-то сделал запись в начало раздела диска), вы можете восстановить файловую систему с помощью одной из резервных копий суперблока, которые создает mke2fs. Воспользуйтесь fsck -b num чтобы заменить поврежденный суперблок, дублирующим в блоке num.

Вы можете не знать, где искать резервный суперблок, потому что не запи­сали номера, когда запускали mke2fs. Если файловая система была создана со значениями по умолчанию, вы можете попробовать mke2fs -n на устройстве, чтобы посмотреть список резервных суперблоков без уничтожения ваших данных (снова, будьте на сто процентов уверены, что используете -n, потому что в противном случае вы действительно разорвете файловую систему в клочья). Если устройство работает правильно за исключением нескольких неболь­ших его частей, вы можете запустить fsck -с перед ручным запуском fsck, что­бы найти неисправные блоки. Такая ошибка встречается довольно редко.

Проверка файловых систем ext3.Вообще, вам не обязательно проверять файловые системы ext3, потому что журнал проверяет целостность данных. Однако, вы можете захотеть устано­вить файловую систему ext3 в режиме ext2. Ядро не установит файловую сис­тему ext3, которая содержит непустой журнал (если вы не завершили работу системы правильно, журнал может содержать какие-нибудь данные). Чтобы сместить журнал из файловой системы ext3 на постоянную базу данных фай­ловой системы, запустите e2fsck как показано ниже:e2fsck -fy /dev/disk_device

Самый худший случай.Более суровые проблемы диска оставляют вам небольшой выбор:1. Вы можете извлечь всю файловую систему с диска при помощи dd и пе­реместить на раздел другого диска с таким же размером.

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

3. В обоих случаях, вам все равно надо починить файловую систему перед тем, как ее устанавливать (если только вы не вводите свежие данные собственноручно). Чтобы ответить на все вопросы fsck, воспользуйтесьfsck с ключом -у, но делайте это лишь в крайнем случае.

Существует продвинутая утилита под названием debugfs для пользователей с доско­нальным знанием файловых систем, или для тех, кто хочет поэкспериментировать на не особо нужных файловых системах.

Если вы действительно в отчаянном положении, таком как катастрофический сбой в дисковой системе без резервирования, вам больше ничего не ос­тается, кроме как обратиться за профессиональной помощью.

Вы можете посмотреть так же записи

schel4koff.ru

Восстановление файловой системы

Иногда случается беда, файловая система перестаёт монтироваться хотя оборудование цело, скорее всего такое бывает от проделок "левых" программ управления разделами или от винды

Иногда получается спасти файлы и вообще восстановить работу файловой системы. Достаточно лишь восстановить таблицу файлов. Попробую на примере файловой системы размешённой в файле

Выделяю под раздел 120Mb, создаю файловую систему Ext3 и монтирую

dd if=/dev/zero of=test.img bs=1M count=120120+0 записей считано120+0 записей написаноскопировано 125829120 байт (126 MB), 1,65321 c, 76,1 MB/c

mkfs.ext3 test.img mke2fs 1.40.8 (13-Mar-2008)test.img is not a block special device.Proceed anyway? (y,n) yFilesystem label=OS type: LinuxBlock size=1024 (log=0)Fragment size=1024 (log=0)30720 inodes, 122880 blocks6144 blocks (5.00%) reserved for the super userFirst data block=1Maximum filesystem blocks=6737100815 block groups8192 blocks per group, 8192 fragments per group2048 inodes per groupSuperblock backups stored on blocks: 8193, 24577, 40961, 57345, 73729

Writing inode tables: done Creating journal (4096 blocks): doneWriting superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 30 mounts or180 days, whichever comes first. Use tune2fs -c or -i to override.

sudo mount -o loop test.img /mnt/df -h|grep mnt117M 5,6M 105M 6% /mnt

Подчёркнутым текстом выделены номера блоков в которох размещены резервные копии таблиц файлов и прочих важных для файловой системы параметров, эти цифры пригодятся для восстановления данных

Заполним файловую систему данным, перемонтируем и проверим

sudo cp -R /etc/* /boot/* /var/log/* /mnt/df -h|grep mnt117M 59M 52M 54% /mnt

umount /mntsudo mount -o loop test.img /mnt/df -h|grep mnt117M 59M 52M 54% /mnt

Видим, что файловая система в порядке, данные сохранены, всё монтируется. Теперь нанесём по ней удар, разрушим таблицу файлов: запишем в начало раздело 2 килобайта мусора, опция conv=notrunc заставит dd писать по верх существующего файла - типичное поведение вендового загрузчика

dd conv=notrunc if=/dev/urandom of=test.img bs=1k count=22+0 записей считано2+0 записей написаноскопировано 2048 байт (2,0 kB), 0,000716177 c, 2,9 MB/csudo mount -o loop test.img /mnt/mount: вы должны указать тип файловой системы

Всё, файловая система почти уничтожена, не монтируется, не определяется. Но её можно восстановить с помощью утилиты fsck и блоков копий таблицы файлов, вот номер блоков (Superblock backups stored on blocks: 8193, 24577, 40961, 57345, 73729), количество таких резервных копий зависит от размеров и настроек файловой системы, как видите номера можно просчитать зная арифметику

fsck.ext3 -b 73729 test.img e2fsck 1.40.8 (13-Mar-2008)test.img was not cleanly unmounted, check forced.Pass 1: Checking inodes, blocks, and sizesInode 16703, i_size is 286720, should be 289792. Fix? yes

Pass 2: Checking directory structurePass 3: Checking directory connectivityPass 4: Checking reference countsPass 5: Checking group summary informationFree blocks count wrong for group #0 (3548, counted=3539).Fix? yes

test.img: ***** FILE SYSTEM WAS MODIFIED *****test.img: 10024/30720 files (0.4% non-contiguous), 63998/122880 blocks

sudo mount -o loop test.img /mnt/df -h|grep mnt117M 59M 52M 54% /mnt

Соглашайтесь с тем что предлогают, либо попробуйте все другие резервные блоки. В итоге, в моём случае, я восстановил практически все файлы, во всяком случае в

sudo ls /mnt/lost+found/|wc -l0

ничего не оказалось, а именно туда утилита восстановления файловой системы складывает невостановленные куски

Сообщите мне о результат применения этой заметки, мне любопытно

breys.ru