Простой откат изменений файловой системы с помощью утилиты snapper
Оригинал: How to Easily Roll Back Changes with Snapper
Автор: Jack Wallen
Дата публикации: 23 сентября 2016 г.
Перевод: А.Панин
Дата перевода: 17 января 2017 г.
snapper является утилитой с интерфейсом командной строки, позволяющей создавать, удалять и сравнивать снимки файловой системы.
Хороший системный администратор должен знать, как устранить последствия любых некорректно осуществленных изменений системы. К примеру, вы можете устанавливать, обновлять, настраивать систему или отдельную службу и столкнуться с ошибкой в процессе выполнения соответствующих действий. Что делать в этом случае? Если вы создали копию файла конфигурации, то ничего страшного не произошло. Если в процессе установки программного обеспечения не было установлено большое количество других необходимых для его корректного функционирования программных компонентов (что, в свою очередь, может стать причиной систематических неполадок), вы можете просто удалить его. Но имеют место и такие ситуации, когда гораздо удобнее осуществить откат всех изменений файловой системы.
Если вы используете файловую систему Btrfs , откат ее изменений не будет связан с какими-либо сложностями. Btrfs позволяет использовать крайне полезный инструмент под названием snapper , позволяющий создавать снимки файловой системы и осуществлять откат ее изменений (в случае неполадок). snapper является утилитой с интерфейсом командной строки, спроектированной специально для управления снимками файловой системы и позволяющей создавать, удалять и сравнивать снимки, а также устранять изменения между ними.
В рамках данной статьи я подробно опишу процесс отката изменений файловой системы с помощью инструмента snapper в новейшей версии дистрибутива openSUSE Leap . Также следует упомянуть о том, что в как в комплекте поставки дистрибутива openSUSE, так и в комплекте поставки дистрибутива SUSE имеется плагин для центра управления системой под названием YaST, предназначенный для работы с snapper и максимально упрощающий описанный процесс. Но, перед тем, как знакомиться с графическим интерфейсом для рассматриваемого инструмента, все же стоит разобраться с лежащими в его основе командами.
Первые шаги
В качестве тестовой площадки будет использоваться свежеустановленная система openSUSE Leap. Так как система не находилась в длительной эксплуатации, в ней отсутствуют файлы конфигурации snapper. По этой причине вам придется открыть центр управления системой YaST, осуществить переход Miscellaneous > snapper и ознакомиться с сообщением об ошибке. Для исправления этой ошибки вам придется осуществить обновление системы с помощью инструмента zypper. Таким образом, в результате исполнения команды zypper upgrade будет осуществляться не только обновление системы, но и создание конфигурации snapper для корневой директории (/). Вы также можете создать эту конфигурацию вручную с помощью команды:
Приведенная выше команда создает новый файл конфигурации с именем «root» для корневой директории (/). Файлы конфигурации необходимы для корректной работы snapper; без них вы просто не сможете пользоваться данным инструментом. К счастью, файл конфигурации для корневой файловой системы — это все, что нужно для использования основных функций snapper.
Теперь при выполнении команды snapper list-configs вы увидите запись, соответствующую как минимум одному файлу конфигурации (Рисунок 1).
Рисунок 1: Файл конфигурации для корневой файловой системы, который был создан нами вручную
Если вы выполните команду snapper-list , snapper выведет список всех сохраненных снимков файловых систем. При использовании свежеустановленной системы велика вероятность того, что таких снимков будет не очень много, а возможно, что и вообще не будет. Ну что же, предлагаю создать новый снимок.
Создание снимка файловой системы
Предположим, что вы собираетесь установить веб-сервер Apache и хотите создать снимок файловой системы перед его установкой. Сервер функционирует корректно и ничто не мешает установке Apache. Пришло время создать снимок файловой системы. Это команда, которую следует использовать для его создания:
Давайте разберемся с ее параметрами:
- snapper : это название утилиты. Да, просто название.
- create : этот параметр сообщает snapper о том, что вы собираетесь создать новый снимок файловой системы.
- —type pre : этот параметр сообщает snapper о том, что вы создаете снимок до внесения изменений в файловую систему.
- —print-number : этот параметр сообщает snapper о необходимости вывода числового идентификатора, ассоциированного с создаваемым снимком файловой системы (он понадобится при создании связанного снимка после внесения изменений в файловую систему). Этот идентификатор является крайне важным.
- —description : это читаемое пользователем описание снимка файловой системы (оно очень поможет при поиске снимков, ассоциированных с определенными изменениями файловой системы или периодами времени).
Теперь, когда вы создали снимок файловой системы до внесения изменений, вы можете выполнять все необходимые действия с сервером (а в нашем примере — устанавливать Apache). После того, как вы закончите работу, вам придется создать ассоциированный снимок файловой системы. Как вы видите, при внесении любых важных изменений в файловую систему вам придется создавать по два ее снимка: снимок перед внесением изменений ( pre ) и снимок после внесения изменений ( post ). Благодаря их наличию вы сможете осуществлять откат изменений файловой системы.
Для создания снимка файловой системы после внесения изменений вы должны выполнить следующую команду:
Здесь вместо X должен использоваться числовой идентификатор, полученный при создании снимка файловой системы до внесения изменений.
Помните, что при создании снимка файловой системы до внесения изменений, snapper должен выводить числовой идентификатор, ассоциированный с этим снимком. и именно для этой цели вы использовали параметр —pre-number . Снова выполните команду snapper list и вы увидите в списке информацию о снимках файловой системы, созданных до и после внесения изменений в нее (Рисунок 2).
Рисунок 2: Числовой идентификатор моего снимка файловой системы до внесения изменений равен 2, а после внесения изменений — 5
Проверка изменений
На этом этапе все становится гораздо проще и удобнее. Вы можете сообщить snapper о необходимости вывода списка всех изменений, внесенных в файловую систему в промежутке времени между созданием ее снимков. При этом мы знаем, что снимок файловой системы до внесения изменений имеет идентификатор 2, а после — идентификатор 5. Но какие файлы были изменены? Выполните команду snapper 2..5 для получения списка всех измененных файлов (Рисунок 3).
Рисунок 3: Список файлов, измененных в процессе установки веб-сервера Apache
Слева от каждой строки несложно обнаружить символ «+» , который обозначает, что файл по приведенному пути был создан. Аналогично символ «c» обозначает, что файл был изменен, а символ «-» — что файл был удален.
Вы также можете ознакомиться со списком изменений определенных файлов. Предположим, что вы обнаружили символ «c» перед путем к файлу «/etc/sysconfig/apache2» и хотите узнать, какие строки этого файла конфигурации были изменены. Вы можете выполнить следующую команду:
В результате будет выведен список изменений файла конфигурации /etc/sysconfig/apache2 на основе его версий до и после установки веб-сервера Apache в формате утилиты diff . Вы также можете выполнить команду snapper diff 2..5 без передачи имени файла для получения информации об изменениях, внесенных в каждый из подвергшихся модификации файлов.
Откат изменений
Предположим, что с помощью команды diff вам удалось найти причину некорректной работы системы и теперь вы хотите осуществить откат этих изменений. На самом деле, это совсем не сложно. Возвращаясь к нашему примеру, предположим, что проблема заключалась в изменениях, внесенных в файл /etc/sysconfig/apache2 . Для отката содержимого этого файла к начальному состоянию достаточно выполнить следующую команду:
Приведенная выше команда позволяет откатить изменения файла /etc/sysconfig/apache2 от состояния из снимка после внесения изменений в файловую систему до состояния из снимка до внесения изменений в файловую систему (в данном случае, перед установкой Apache).
Да, это действительно просто. Даже без плагина snapper для центра управления системой YaST вы смогли откатить изменения, не используя ничего кроме интерфейса командной строки системы.
Истинная сила
Благодаря инструменту snapper, вы приобретаете истинную силу. С помощью нескольких несложных команд вы можете создавать и сравнивать снимки файловых систем, а также откатывать изменения, появившиеся в новых снимках. После того, как вы научитесь работать с утилитой snapper, вам непременно следует обратить внимание на плагин snapper для центра управления системой YaST; он является настолько же мощным, но более простым в использовании благодаря наличию графического интерфейса.
Для того, чтобы узнать немного больше об инструменте snapper следует воспользоваться командой man snapper , в результате чего откроется страница руководства, которая поможет лучше оценить все его возможности.
Источник
Как восстановить файл, перезаписанный другим в Linux?
Я сделал это в командной строке (Ubuntu 12.04, ext4)
Есть ли способ восстановить требуемый_файл? Я вложил так много работы в это. Я обычно делаю резервные копии файлов, но на этот раз я забыл.
3 ответа 3
Некоторые люди предлагают
Там, где ваш файл находился в файловой системе /home, ‘home был смонтирован на /dev //sda2, а военная является ключевой фразой, которая, вероятно, будет уникальной для перезаписанного файла.
recovered_file может быть большим, но может содержать текст из перезаписанного файла. Если перезаписанный файл не был в основном текстовым, этот подход бесполезен.
Важно принять меры для предотвращения дальнейшей записи операционной системой файловой системы, содержащей ваш файл. Хороший способ — это загрузка с live-CD. Если вы можете размонтировать файловую систему или перемонтировать ее только для чтения, это тоже хорошо.
Вам может быть интересно прочитать http://carlo17.home.xs4all.nl/howto/undelete_ext3.html — хотя это относится больше к удаленным файлам, чем к перезаписанным. Однако, если вы ранее редактировали перезаписанный файл, вполне вероятно, что редактор оставил несколько удаленных копий на диске как естественную часть процесса редактирования.
Прекратите использовать / размонтировать соответствующий раздел как можно скорее.
Рассмотрим эту тему, где упоминается extundelete . Кроме того, существуют photorec, прежде всего, и скальпель, которые являются очень мощными резчиками файлов, которые могут помочь восстановить ваш файл (например, путем поиска более старых версий или резервных копий вашего файла, которые еще не были перезаписаны).
Все эти инструментов доступны в вашей Ubuntu метких хранилищ (PhotoRec поставляется с пакетом TestDisk).
Не забудьте сохранить результаты восстановления в другом разделе, чем тот, из которого вы восстанавливаете данные.
Однако, если ваш файл действительно был перезаписан (т. Е. Та же область жесткого диска, на которой был сохранен старый файл, использовалась для хранения нового файла), то нет возможности восстановить файл (Примечание: это действительно только для жесткие диски — ssds хранит (и «перезаписывает») файлы другим способом). Если вам повезет, вы сможете восстановить только те части файла, которые не были перезаписаны, например, если новый файл был меньше старого.
Я не думаю, что требуемый_файл был фактически перезаписан этим действием. Это было скорее «несвязано» с соответствующим инодом, чтобы «исчезнуть». Кроме того, some_arbit_file не изменил своего местоположения — это был скорее «указатель», который ранее указывал на required_file, который сейчас указывает здесь.
Существуют инструменты, которые помогут вам в таких случаях, например, Sleuthkit или Testdisk. Но они требуют некоторой ручной работы — и это не так легко сделать, если вы не знаете, с чего начать. Также есть скрипт ext3undel, который использует эти инструменты и автоматизирует процесс, или отдельная утилита extundelete.
Все, что вы пытаетесь сделать: вообще не трогать поврежденный раздел диска, увеличивает ваши шансы на восстановление потерянного файла. Лучше всего выполнить все действия на другом компьютере, а подключенный диск только для чтения, даже для восстановления, также повышает ваши шансы. Если у вас нет другого компьютера, вы можете попробовать live CD (не устанавливайте поврежденный диск в режиме записи и здесь!). Даже будучи LiveCD, они позволяют устанавливать программное обеспечение в памяти, поэтому вы можете получить и запустить любой из вышеупомянутых инструментов. Имейте под рукой дополнительный носитель (например, карту памяти, SD-карту, внешний диск . ) для хранения восстановленных файлов и запуска процесса — в зависимости от того, что вы выбрали — оттуда.
Источник
Можно ли восстановить перезаписанные файлы?
Я говорю не о восстановлении удаленных файлов , а о перезаписанных файлах. А именно следующими методами:
Можно ли получить что-нибудь, если какое-либо из указанных выше трех действий выполнено, если на компьютере с Linux не установлено никаких специальных программ?
Ответ: «Возможно, да, но это зависит от типа файловой системы и времени».
Ни один из этих трех примеров не перезапишет физические блоки данных old_file или существующие_file, за исключением случайного.
mv new_file old_file , Это отвяжет old_file. Если на old_file есть дополнительные жесткие ссылки, блоки в этих оставшихся ссылках останутся неизменными. В противном случае блоки обычно (в зависимости от типа файловой системы) будут помещены в свободный список. Затем, если mv требуется копирование (в отличие от простого перемещения записей каталога), новые блоки будут выделены как mv записи.
Эти вновь распределенные блоки могут быть или не быть теми же, которые были только что освобождены . В файловых системах, таких как UFS , блоки распределяются, если это возможно, из той же группы цилиндров, что и каталог, в котором был создан файл. Так что есть вероятность, что отсоединение файла от каталога и создание файла в этом же каталоге будет использоваться повторно ( и перезаписать) некоторые из тех же блоков, которые были только что освобождены. Вот почему стандартный совет для людей, которые случайно удаляют файл, — не записывать новые данные в файлы в их дереве каталогов (и желательно не во всю файловую систему), пока кто-то не попытается восстановить файл.
cp new_file old_file будет делать следующее (вы можете использовать strace для просмотра системных вызовов):
Флаг O_TRUNC приведет к освобождению всех блоков данных, как это mv делалось выше. И, как указано выше, они, как правило, добавляются в свободный список и могут или не могут быть повторно использованы последующими записями, выполненными cp командой.
vi existing_file , Если vi это на самом деле vim , 😡 команда делает следующее:
Так что он даже не удаляет старые данные; данные сохраняются в файле резервной копии.
На FreeBSD, vi делает open(«existing_file»,O_WRONLY|O_CREAT|O_TRUNC, 0664) , который будет иметь ту же семантику, что cp и выше.
Вы можете восстановить некоторые или все данные без специальных программ; все , что вам нужно , grep и dd , а также доступ к исходному устройству.
Для небольших текстовых файлов, единственная grep команда в ответе @Steven D в вопросе, на который вы ссылаетесь, является самым простым способом:
Но для больших файлов, которые могут быть в нескольких несмежных блоках, я делаю это:
который даст вам смещение в байтах совпадающей строки. Выполните это с помощью ряда dd команд, начиная с
Вы также хотели бы прочитать некоторые блоки до и после этого блока. В UFS файловые блоки обычно имеют размер 8 КБ и обычно распределяются довольно непрерывно, причем блоки одного файла чередуются с блоками 8 КБ из других файлов или свободного места. Длина файла в UFS составляет до 7 фрагментов по 1 КБ, которые могут быть или не быть смежными.
Конечно, в файловых системах, которые сжимают или шифруют данные, восстановление может быть не таким простым.
На самом деле в Unix очень мало утилит, которые перезаписывают блоки данных существующего файла. Тот, который приходит на ум, это dd conv=notrunc . Другой есть shred .
Источник
