Знакомые друзья могут знать, что после поступления в архитектурную группу, в этом году делал для команды различные средства разработки, в том числе и сервер.
В последнее время этот сервер был в сети более трех месяцев, и он непрерывно собирал много данных, включая различные операции с поведением пользователей, данные вызовов API и так далее.
В недавнем обновлении я изменил структуру каталогов исходного кода и мгновенно удалил базу данных.
Так начался однодневный процесс восстановления данных, конечный результат очень трагичен, но, к счастью, последствия невелики, об этом можно будет рассказать позже.
поиск файлов
Следует отметить, что поскольку это небольшой и микросервис, используется самая простая база данных SQLite. Очевидная разница между SQLite и другими базами данных заключается в том, что он предоставляет только самые основные услуги данных, но не включает мониторинг портов.Вы можете просто подумать, что это файл.Если вы удалите его, это то же самое, что и обычные файлы, исчезающие из система. . Поэтому обычно, если вы используете SQLite для сохранения данных, вам необходимо регулярно создавать резервные копии.
Поэтому, хотя этот пост в блоге называется «удаление библиотеки», на самом деле его можно просто понять какпоиск файлов.
rm -rf
Когда я удалил его по ошибке, я использовал команду rm -rf, которая, конечно же, является хорошо известной и печально известной командой (поэтому, когда я спросил совета у внутреннего босса в то время, ответ внутреннего босса был "Ой, наконец-то ты и его удалил. kura")
rm — это команда, используемая для «удаления файла или каталога» в системе Linux.
-fИдентификатор указывает силу, то есть:
Не спрашивать перед удалением файлов, защищенных от записи.
-rИдентификация означает:
Разрешает циклическое удаление каталогов и их содержимого, когда параметр File является каталогом
extundelete и дисковое хранилище
extundeleteЭто мощный инструмент для восстановления данных в системе Linux. extundelete использует информацию, хранящуюся в журнале раздела, чтобы попытаться восстановить файлы, которые были удалены из раздела.
Давайте немного рассмотрим основы работы с компьютером:
жесткий диск
Жесткий диск — это устройство хранения данных, использующее магнитные носители, и данные хранятся на нескольких дисках в «физическом смысле». На каждой стороне диска несколько концентрических окружностей с осью вращения в качестве оси и определенной магнитной плотностью в качестве интервала разбиты на дорожки, а каждая дорожка разбита на несколько секторов.
Главный загрузочный сектор и таблица разделов
Сектор 0 дорожки 0 цилиндра 1 жесткого диска является битом главного загрузочного сектора, включая основную загрузочную запись жесткого диска MBR (основная загрузочная запись) иТаблица разделовDPT (таблица разделов диска).Операционная система делит жесткий диск на несколько разделов через таблицу разделов, а затем создает файловую систему в каждом разделе и записывает файлы данных.
Журнал разделов
Система ведения журнала разделов — это файловая система, используемая для исправления любых несоответствий, вызванных неправильным выключением компьютера. Это отключение обычно происходит из-за отключения электроэнергии или проблемы с программным обеспечением. То есть операции чтения и записи данных раздела записываются.
Благодаря этим журналам вы можете узнать историю операций в разделе.
хранилище данных
Существует множество конкретных принципов хранения данных, которые мы не будем здесь повторять. Для простоты понимания я понимаю это здесь как:
Файл в операционной системе представлен на жестком диске путем записи двоичной информации в область данных жесткого диска, а указатель операционной системы указывает на физический адрес. А "удалить файл" на уровне операционной системы - это удалить "указатель" После того, как в исходном физическом адресе нет «указателя», он эквивалентен освобождению, когда операционной системе это нужно, он может быть перезаписан новыми данными.
Из этого видно, что extundelete находит удаленный указатель, обращаясь к журналу разделов, и сообщает пользователю, какие данные можно попытаться восстановить.
Однако, поскольку операционная система может перезаписать резервный диск в любое время, если восстанавливаемый физический адрес был перезаписан, данные не будут восстановлены.
DEMO
В целях десенсибилизации я использую свой собственный сервер, чтобы специально записывать процесс восстановления файлов.
окрестности
- CentOS 7.4 64-разрядная версия
- Каталог файлов: /root/Sparrow/db.sqlite3
Удалить файлы
# rm -rf db.sqlite3
установить extundelete
# yum install extundelete -y
монтировать диск
Во-первых, давайте запросим диск, на котором находится файл или родительская папка.
# df /root/Sparrow/
文件系统 1K-块 已用 可用 已用% 挂载点
/dev/vda1 41151808 2614640 36423736 7% /
Найдя его, первым делом нужно смонтировать диск,После монтирования диск больше не будет записываться, защищая сцену
umount /dev/vda1
/dev/vda1это диск, на котором находится файл.
Также возможно не монтировать его, что приведет к записи на диск другими процессами, тем самым удалив исходные данные, поэтому я не получил файл в конце, потому что он не был смонтирован вовремя.
inode
Индекс — это идентификатор файла или папки в системе Linux. пройти черезls –idты можешь видеть.
Прочитайте значение inode корневого каталога:
# ls -id /
2 /
Теперь мы знаем, что индекс в корне диска равен 2.
extundelete запрашивать информацию о восстанавливаемых данных
Сначала запросите восстанавливаемую информацию в корневом каталоге диска.
# extundelete /dev/vda1 --inode 2
При выполнении, если диск не смонтирован, появится запрос.
получил ответ:
Сосредоточьтесь на красном круге, см.rootИндекс 131073, продолжайте запрашивать/devИнформация:
# extundelete /dev/vda1 --inode 131073
Видеть/SparrowДа 262194, продолжить запрос/devИнформация:
# extundelete /dev/vda1 --inode 262194
Наконец нашел информацию об удалении:
Вы можете видеть, что db.sqlite3 идентифицируется какDeleted.
extundelete восстановить данные
Выполните --restore-directory, чтобы восстановить указанный каталог
# extundelete /dev/vda1 --restore-directory /root/Sparrow/db.sqlite3
или выполните --restore-all, чтобы восстановить все восстанавливаемые данные
# extundelete /dev/vda1 --restore-all
После завершения выполнения будет создан файл по текущему пути.RECOVERED_FILESпапка со всеми восстановленными файлами.
Если диск был прочитан и записан и не может быть восстановлен, появится аналогичное сообщение:
Loading filesystem metadata ... 320 groups loaded.
Loading journal descriptors ... 27896 descriptors loaded.
Searching for recoverable inodes in directory /root/Sparrow/db.sqlite3 ...
120 recoverable inodes found.
Looking through the directory structure for deleted files ...
120 recoverable inodes still lost.
No files were undeleted.
постскриптум
Этот инцидент с «удалением библиотеки» преподал мне хороший урок. Данные сервера должны быть зарезервированы вовремя, или должно быть выполнено аварийное восстановление, чтобы предотвратить потерю. В то же время, на этот раз я также воспользовался этой возможностью, чтобы узнать о восстановлении файлов.
Конечно, я надеюсь, что у всех не будет такой трагедии, как у меня 😂.