​​Настраивал скрипт бэкапа с автоматическим удалением старых копий. Во время отладки и бэкапы, и сам скрипт лежали в одной директории. Напутал с условием удаления и случайно был удалён сам скрипт после выполнения. Так как ещё не успел его никуда сохранить, это была единственная копия.

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

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

# apt install scalpel

Далее нам нужно указать сигнатуры восстанавливаемых файлов. Часть сигнатур есть в самом файле конфигураций - /etc/scalpel/scalpel.conf. Ещё более подробный список можно посмотреть тут в репозитории. Я не совсем понял, какие заголовки должный быть у обычного текстового файла, коим являлся мой скрипт. По идее там особых заголовков и нет, а искать можно по содержимому. Так что я добавил в scalpel.conf следующее:

NONE   y   1000   #!/bin/bash

В данном случае #!/bin/bash это начало моего скрипта. Я их все так начинаю. Запускаем сканирование с выводом результатов в /tmp/restored:

# mkdir /tmp/restored
# scalpel /dev/mapper/zabbix-vg-root -o /tmp/restored

zabbix-vg-root - корневой и единственный lvm раздел этого сервера. Если у вас не используется lvm, то это будет что-то вроде /dev/sda2 и т.д.

Программа минуты за 3-4 просканировала раздел на 50G и вывела результаты в указанную директорию. Там было около сотни различных текстовых скриптов, а нужный мне был где-то в самом начале списка, так что мне даже по содержимому искать не пришлось. Сразу нашёл при беглом осмотре. Всё содержимое файла сохранилось.

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

#restore #linux

В свете недавних обсуждений гипервизоров вспомнил, как я начинал изучение KVM. До него работал с Xen и Hyper-V. Первым делом стал разбирать вопрос бэкапа виртуальных машин наживую, без их остановки. Это было более 10-ти лет назад и простых решений не существовало. Proxmox не помню, был уже тогда или нет, но я про него не знал. Использовал всё это в консоли с помощью virsh, и в GUI с помощью virt-manager.

Я изучил вопрос и разобрался, как делать снепшоты при использовании файлов qcow2 для дисков виртуальных машин, и как снимать с них бэкапы. Всё это обернул в очень простой скрипт без каких-то дополнительных проверок. Оформил всё это в статью.

Уже не помню, в чём там был нюанс, но при некотором стечении обстоятельств можно было потерять образы дисков. Вроде бы если по какой-то причине не создался снепшот, то скрипт, не найдя его, удалял сам образ машины. Лично с таким не сталкивался, потому что очень внимательно проверял работу до того, как включал реальное удаление. А вот в комментариях отписались люди, которые диски потеряли, хотя я обо всём этом предупреждал в статье. Сначала всё тщательно проверяем - потом включаем удаление.

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

Допустим, у нас работает виртуальная машина с диском в виде файла vm-109-disk-0.qcow2 и этот файл по какой-то причине был удалён в момент работы VM. То есть машина работает, а файла уже нет. Поверяем, реально ли файл удалён, но всё ещё открыт его дескриптор:

# lsof | grep '(deleted)'
kvm    402083            root  14u   REG        0,39 21478375424     17 /var/lib/vz/images/109/vm-109-disk-0.qcow2 (deleted)

Вы должны увидеть строки с упоминанием файла /var/lib/vz/images/109/vm-109-disk-0.qcow2. Значит, он реально ещё не удалён. Его держит процесс с пидом 402083. Проверяем это:

# ls -l /proc/402083/fd | grep deleted
lrwx------ 1 root root 64 Aug 3 21:16 14 -> /var/lib/vz/images/109/vm-109-disk-0.qcow2 (deleted)

Да, файловый дескриптор на месте и имеет номер 14. Скопируем из него данные обратно в файл:

# cp /proc/402083/fd/14 /var/lib/vz/images/109/vm-109-disk-0.qcow2

Какое-то время будет длиться копирование. После этого файл будет возвращён на место. Так как копирование не моментальное, диск виртуальной машины может немного пострадать. Если там есть СУБД, то может нарушиться целостность базы, но не обязательно. Большую часть ошибок сможет починить обычный fsck. По сравнению с полной потерей виртуалки это будут небольшие трудности.

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

❗️Сохраните заметку в закладки, может пригодиться в самом неожиданном случае. У меня бывало, что по ошибке удалял конфиг работающей программы. Казалось бы, вот он только что был, ты его грохнул, а как сразу же вернуть, не знаешь, надо вспоминать.

#restore #linux #terminal