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

== Аннотация ==
;Докладчик: {{Speaker|Денис Силаков}}
<blockquote>
Дистрибутив Linux является динамично развивающейся средой, постоянно получающей большие пласты обновлений. Обновления призваны привнести в систему улучшения и новый функционал, однако иногда они имеют обратный эффект, ломая что-то работающее и вызывая недовольство пользователей. Кроме того, многие члены сообщества – это энтузиасты, которых постоянно тянет попробовать что-то новое.

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

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


== Видео ==

{{vimeoembed|106435755|800|450}}
{{youtubelink|OhTafawHRwU}}{{letscomment}}



<!-- pollholder --> 










== Слайды ==
[[File:Средства восстановления системы в ROSA Linux (Денис Силаков, OSSDEVCONF-2014).pdf|left|page=-|256px]]

{{----}}

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

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

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

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

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

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

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

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

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

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

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

== Примечания и отзывы ==
<!-- <blockquote>[©]</blockquote> -->

<references/>

[[Category:OSSDEVCONF-2014]]
[[Category:Open-source projects]]

<!-- topub -->
{{stats|disqus_comments=0|refresh_time=2021-08-31T18:27:48.221565|vimeo_comments=0|vimeo_plays=543|youtube_comments=4|youtube_plays=985}}
[[Category:ROSA Linux]]