Как восстановить роса линукс

ROSAForum

Forum about ROSA Linux Distros

• Темы без ответов
• Активные темы
• Поиск
• Наша команда

Файловые системы и восстановление данных

Файловые системы и восстановление данных

Сообщение dreamdrawer » 22 май 2016, 03:27

Был старый hdd лет 10 отработал, в последнее время использовался как файлопомойка.
Работал без нареканий, но в один прекрасный день попросту перестал отображаться в системе.
Проблемы с важными файлами не стояло, было просто интересно получить опыт извлечения данных с убитых устройств.
Действовал средствами всевозможных линукс-утилит
Gparted (попробовать восстановить данные)
TestDisk
ddrescue
После безуспешных попыток, многочасовых прогонов углублённого сканирования, максимум что удавалось получить — имена двух каталогов в одном из которых обнаруживались ещё несколько подкаталогов, совершенно не читаемые с нулевым размером. Исходно было с десяток каталогов со множеством подкаталогов.
Восстановить или хотя бы получить список файлов, которые были на жестком диске, не удалось.

Решил попробовать средства виндовс.
Программа Active@ File Recovery средствами быстрого сканирования (. testdisk не справился даже многочасовым, глубоким сканированием) выдала список всех файлов, которые совершенно без проблем были восстановлены, со скоростью обычного копирования.

Возникло множество вопросов.

Возможно совпадение, но после того, как стал использовать Linux стали выходить из строя жесткие диски. При том, что под виндой они работали без нареканий несколько лет. Скорее всего просто срок службы подошёл к концу, и этот момент совпал с установкой Linux, но всё же, может ли быть, что Linux гробит жесткие диски больше чем винда, или возможно это имеет место быть только в случае с файловой системой ntfs?

Какие такие уникальные инструменты используют виндосские утилиты восстановления данных, что позволяет так легко без затруднений восстанавливать диски, которые средства Линукс в упор не воспринимали? Играет ли роль то, что файловая система ntfs закрытая и утилиты линукс не могут с ней полноценно работать?
Означает ли это, что в файловых системах Ext4 линукс утилиты будут не менее дееспособны, чем виндовс утилиты?

Утилита Active@ File Recovery имеет загрузочный LiveCD, который собран на основе виндовс (вродебы win8), что так же наводит на мысль о том, что собрать на базе linux было невозможно ввиду ограничений этой системы в работе с жесткими дисками. Иначе какой был бы смысл разработчикам покупать лицензию на винду, когда имеются свободные системы, которые успешно используются во многих продуктах — те же Касперский LiveCD и многими другими.

Как вывод, надо ли понимать, что в среде Linux безопаснее пользоваться открытыми файловыми системами Ext4 и по возможности избегать ntfs?

Источник

Средства восстановления системы в ROSA Linux (Денис Силаков, OSSDEVCONF-2014)

Материал из 0x1.tv

Содержание

Аннотация

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

Например, всевозможные программы из различных источников, которые не имеют прямого отношения к дистрибутиву. Рано или поздно программы могут вступить в конфликт с приложениями и политиками ОС и привести систему (по крайней мере частично) в нерабочее состояние.

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

Видео

Посмотрели доклад? Понравился? Напишите комментарий! Не согласны? Тем более напишите.

Слайды

Расширенные тезисы

Инструменты уровня пакетов

Поскольку в Росе, как и в большинстве дистрибутивов Linux, установка, удаление и обновление программ сводится к манипуляции с пакетами, то и откат действий по управлению ПО логично осуществлять на уровне пакетов — то есть если с обновленным пакетом что-то не так, то надо откатиться на предыдущую версию. На практике такой подход сталкивается с двумя проблемами — во-первых, пользователь не всегда может однозначно идентифицировать пакет, который привел к сбою, а во-вторых — надо где-то взять старую версию пакета, ведь в официальных источниках (если они использовались для обновления) она уже заменена новой. Если проблемы вызваны пакетами из сторонних репозиториев, то на помощь может прийти инструмент urpm-reposync (аналог reposync из Fedora), способный привести состояние пакетной базы системы в соответствие с подключенными репозиториями — в частности, удалить пакеты, в этих репозиториях отсутствующие, а для имеющихся пакетов обновить или откатить их до официальных версий.

Urpm-reposync обладает некоторой гибкостью (в частности, позволяет не удалять «лишние» пакеты, если их зависимости по-прежнему будут присутствовать в системе после синхронизации с репозиториями), однако в целом является достаточно тяжеловесным инструментом. С его помощью можно провести синхронизацию всех пакетов, установленных в системе, но нельзя откатить конкретные обновления.

Более избирательным является urpmi.recover, работающий на уровне транзакций rpm. Этот инструмент позволяет производить откат пакетной базы по датам или транзакциям — можно откатить заданное число транзакций либо все транзакции до определенной даты.

Алгоритм работы инструмента прост — при удалении или обновлении пакетов делается резервная копия удаляемой/обновляемой версии пакета, которая и устанавливается в систему при откате. Отметим, что откатывать транзакции выборочно инструмент не позволяет, однако при сильном желании можно попробовать сделать такой откат вручную с помощью rpm — ведь старые версии пакетов доступны в кэше urpmi.recover.

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

Соответственно после отката можно ожидать «сюрпризов» в виде неожиданной отработки post-скриптов или некорректного изменения конфигурационных файлов, входящих в пакет. Тем не менее, urpmi.recover снискал популярность у тестировщиков РОСЫ, поскольку позволяет откатывать тестовые версии пакетов проще и быстрее, чем urpm-reposync.

Инструменты уровня файловой системы

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

Сценарии использования систем резервного копирования подразумевают, что «плохие» ситуации в ОС происходят относительно редко, и откат ОС к предыдущему состоянию осуществляется только при выявлении подобных ситуаций. Однако в жизни бывают и другие сценарии, когда с большой вероятностью все действия пользователя в рамках текущей сессии необходимо будет откатить. Такие ситуации нередко встречаются на предприятиях, когда сотрудникам при загрузке машины предоставляется некоторая фиксированная система, которая при выключении машины или перезагрузке возвращается в исходное состояние (возможно, за исключением домашних папок сотрудников и других мест, где они могут сохранять результаты своей работы).

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

Подобное решение — ROSA Freeze — мы реализовали в Росе. При использовании ROSA Freeze, ОС может работать в двух режимах — обычном и режиме «заморозки». При использовании последнего поверх всех системных директорий верхнего уровня (/bin, /etc, /usr и так далее; список может быть скорректирован администратором) с помощью aufs монтируются директории-«перехватчики», находящиеся в tmpfs либо на отдельном разделе жесткого диска.

Любые изменения, вносимые в «замороженные» директории, реально попадают в директории-«перехватчики», а содержимое оригинальных директорий остается неизменным. При перезагрузке машины все содержимое этих перехватчиков удаляется и системные ди- ректории возвращаются в первоначальное состояние. При этом после перезагрузки система продолжает оставаться в замороженном состоянии — выход из этого режима надо производить явно. Предусмотрена возможность переноса всех изменений из aufs, сделанных в рамках текущей сессии, в оригинальные директории. Инструмент ROSA Freeze очень молодой, однако уже готов к использованию. В настоящее время инструмент рассчитан на работу в схеме, когда все замораживаемые директории находятся на одном и том же разделе жесткого диска. В будущем мы планируем добавить поддержку заморозки директорий на разных разделах, а также реализовать в рамках ROSA Freeze механизма точек восстановления — ведь используемые подход с aufs позволяет нам автоматически получать инкрементальные различия между состояниями системы, остается только реализовать средства сохранения таких различий на диск и отката к ним.

Источник