Что теперь делать, если я случайно обрезал файл, для которого у меня нет резервной копии?

344
Vyan

Я запускаю KVM Server 300 ГБ Размер файла VMDK Когда я хочу сделать резервную копию своего сервера, я запускаю скрипт (примечание Отправляющий сервер: 192.168.13.95, Принимающий сервер 192.168.13.91)

#tar cv vm-102-disk-1.vmdk | nc -q 1 192.168.13.91 1234 

на моем сервере отправки и запустить скрипт

#nc -w 10 192.168.13.95 1234 > vm-102-disk-1.vmdk 

К сожалению, я запускаю его на своем отправляющем сервере тоже с другой консоли, на самом деле я знаю, что мне нужно запустить этот скрипт с моего принимающего сервера

Эта ошибка стоила мне мой файл vmdk 300Gb, переписанный в 0 байтов. Есть ли способ его восстановить?

2
** Завершите работу системы СЕЙЧАС. ** (Система, в которой файл был усечен.) Тогда вы сможете попытаться восстановить данные, если вам очень, очень, ОЧЕНЬ повезет. Скорее всего, если вы вообще что-то сделали с системой, которая вызывала некоторые записи на диск, данные теперь слишком сильно искажены, чтобы восстановить больше, чем несколько разбросанных, частично поврежденных файлов. ... Вы, вероятно, даже лучше потяните за штекер системы вместо того, чтобы постепенно отключаться. Horn OK Please 8 лет назад 1
И если VMDK был зашифрован или сжат, вы, вероятно, не сможете получить * какие-либо * данные обратно. Horn OK Please 8 лет назад 0
Если виртуальный диск был создан для хранения в нескольких файлах, то файл VMDK содержит только данные конфигурации, которые вы можете без особых проблем воссоздать. Данные диска хранятся в `vm-102-disk-1-sNNN.vmdk`, где NNN - порядковые номера 001, 002, ..., и эти файлы не будут перезаписаны. AFH 8 лет назад 0

1 ответ на вопрос

2
Horn OK Please

Файлы хранятся на диске в виде последовательности логических блоков, обычно 512 байт или 4096 байт. Когда файл усекается до 0 байтов (что, по-видимому, и происходит здесь), это означает, что файловая система обновила метаданные файла, так что ни один из блоков, которые он ранее заявлял как часть файла, больше не является частью файла.

Фактически, те блоки, которые раньше были частью файла, теперь будут помечены как свободное место .

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

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

Чтобы предотвратить это, лучше всего знать, что делать, когда это происходит.

Если у вас нет резервной копии только что урезанного файла, вам нужно ПРЯМО УСТАНОВИТЬ штекер вашей системы. И, потянув за вилку, я имею в виду, выдернуть ее из стены. Отключите электропитание от системы. Если это ноутбук, отключите его и извлеките аккумулятор.

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

В этом случае, потянув за вилку, вы наименее опасны.

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

-

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

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

Похожие вопросы