Всем привет. Это может показаться для кого-то поучительной историей того, как не стоит делать и почему какие-то важные технические работы в час ночи (в системе, в которой ты мало чего понимаешь), могут привести к огромному краху и простою на два дня.
Небольшая заметка-рассказ системного администратора-любителя, который только начинает погружение в мир виртуализации. История о том, как снапшоты не помогли, а помешали и сделали откат системы на месяц, а потом я с даунтаймом в 2 дня вытащил все файлы оттуда и вернул систему.
Предыстория
После двух лет сидения на nix системах, а в частности на ubuntu server (16.04 LTS), я решил попробовать себя в виртуализации. Знакомый посоветовал ESXi как бесплатное решение для небольших серверов (мой случай: 1 процессор + всего 8 GB RAM). Процесс переезда осложнялся тем, что надо было сначала на windows-компьютере поднять vmware workstation вместе с vmware converter`ом, перебросить туда готовую систему, после поднять на сервере esxi и уже после знакомым конвертером перебросить систему на esxi. Вот такой долгий и мучительный путь. Главная ошибка при переносе, которую я допустил и которая до сих пор мне аукается, заключается в том, что я использовал thin-диск. То есть будучи на чистом ubuntu server c диском, отформатированным в exfat-4, я имел где-то 223.8 гб места на ssd. Переезжая на esxi и форматируя диск в их непонятный ни для чего формат, я потерял всего 300мбайт, но именно из-за них я не смог сделать thick диск, который мне (впоследствии так оказалось) был так нужен.
Начало
Раньше я ломал дрова с ubuntu server (когда только «изучал» его), откатываясь и переустанавливая систему по раз в месяц-два. Сейчас я ломаю дрова с ESXi. Думаю, проблему thin-дисков описывать не надо (если вкратце, то они после расширения своего пространства его не «сужают» в обратную сторону. они так же могут выйти за пределы физического количества памяти на диске). Во-первых, я использовал swap на том же ssd диске, не настроив его должным образом в ESXi. Он жрал память, записывал туда какие-то временные файлы, а thin тем временем рос.
Во-вторых, я зачем-то сделал снапшоты. Руководствовался я в тот момент тем, что «ну это же удобно, быстро и все такое». Еще не подозревая, какую бяку и какую медленную бомбу они мне заложили.
В-третьих, я не следил за стремительно уменьшающимся количеством памяти на диске.
Завязка
Первым звоночком стал стоп основной машины 17 июля. Пришло оповещение на почту о падении хоста. Зайдя в esxi, чтобы поднять его (ну вдруг что-то могло произойти), виртуалка мне выдала приятное известие (скриншота нет, к сожалению). Вольный пересказ всплывающего окна был примерно такой «Прости, место на диске закончилось. Твоя виртуальная машина остановлена. Очищай место и можешь продолжать пользоваться ВМ. «Повторить» «Отменить»». На тот момент проблема решилась удалением второй ВМ, которая занимала около 16гб. Но это было временное решение, так как с каждым днем куда-то по-прежнему пропадало по 5гб, хотя в системе не было прироста этих файлов.
В итоге 19 июля вечером прохладного четверга я написал сначала на тостер об этой проблеме. Ответа так и не было. Думаю, это из-за непопулярного тега esxi. После пошло безуспешное гугление, после — удаление снапшотов. В этот момент исчезло 5 гигабайт, free-space стало больше, но не на столько, чтобы забыть об этой проблеме.
После, пораскинув мозгами, я стал изучать иерархию снапшотов. Последний, 000003, занимал 12гб места на тот момент. В настройках ВМ он числился как активный дисковый файл, с которого машина и загружалась. Недолго думая, я удалил с hard disk 1 disk file с активным диском снапшота и на его место вставил parent-диск всей виртуальной машины.
Система загрузилась (ура), а вместе с ней и файлы за 30 июня. Последняя дата изменения всех файлов на parent-диске. Подозреваю, именно в этот день я создал первый снапшот. Места, что логично, не прибавилось. В free-space по-прежнему около 5гб, а файлы пропали.
Первые мысли логичны: что я наделал, все файлы до 19 июля испарились. Потом я увидел, что файлы снапшотов не удалились. Однако при попытки загрузки их в качестве основного диска ESXi ругалось на измененный parent-диск, чего быть не должно «The parent virtual disk has been modified since the child was created» Моя вечная ошибка на протяжении двух последующих дней.
Гугление
Время подходило к двум часам ночи, и я оставил все тщетные попытки вытащить хоть какую-то информацию с этих несчастных *-0000?-.vmdk файлов снапшотов.
Утро пятницы началось с активного, действительно активного гугления наподобие «как вытащить файлы из vmdk». Статьи, Linux reader (программа на windows) и все подобное попадались очень часто. Я перебрасывал эти 223 гигабайта с сервера на windows-ноутбук по 100мбитному каналу, что было очень больно. Я пытался примонтировать ssd-диск формата vmware к linux системе, накатывал на нее vmware-tools, она ругалась на несовместимость версий (последняя поддерживаемая — 5, а у меня была 6.5). Попытки открыть через windows и java тоже были тщетными.
И даже после того как мне удалось получить доступ (с помощью программы Linux reader на windows) к файлу *-flat.vmdk, я получил файлы только до 30 июня. Все дальнейшие попытки примонтировать файлы снапшота ничего не давали, программа ругалась на недействительный диск и отказывалась работать дальше.
Выход найден
Пятница закончилась, я был вымотан, а так же расстроен тем, что файлы вернуть нельзя. Но суббота началась успешно. По гуглению ошибки (почему я не сделал это сразу — неизвестно) «The parent virtual disk has been modified since the child was created» в первой же строке гугл выдал ссылку на страницу vmware. Куча страшных символов, красных строк и всего подобного сразу же испугало. Я открыл ссылку и оставил ее в надежде, что найду что-то более понятное.
И оно нашлось. https://communities.vmware.com/thread/323730 Русскоязычный форум VmWare и подобная проблема встретили меня на просторах интернета. Вероятно, это не тот же случай, что и у меня, но промотав вниз и вчитавшись в комментарии, я попытался сделать подобное.
В текстовом редакторе, подключившись к esxi по сфтп, я открыл файл с настройками parent-диска. .vmdk (не -flat.vmdk) я узнал CID диска, а после полез в *-00001.vmdk, делая так, как описал человек с ником apavlyuchenko на форуме.
В первом снапшоте в полях CID и parentCID стоило указать CID parent-диска. А после в файле .vmx в полях
scsi0:1.present = "false"
scsi0:1.fileName = «.vmdk»
scsi0:1.deviceType = "scsi-hardDisk"
изменить параметр FALSE на TRUE и .vmdk на -00001.vmdk.
И действительно, после этого машина загрузилась и уже не ругалась на ошибку. И о чудо! Появились файлы до создания второго снапшота!
На форуме товарищ описал способ восстановления файлов только с одного снапшота. Но мой случай тяжелый (видимо, из-за моей болезни, которая называется «тыкать все руками на рабочей машине»). И у меня был не один снапшот, а три. Что логично, надо было продолжать менять файлы.
Итак, мои действия.
Открываем parent-диск. Узнаем его CID. Далее копируем CID parent-диска в строку parentCID диска -00001.vmdk (первый снапшот). Там же смотрим CID этого снапшота и копируем его в строку parentCID диска -00002.vmdk (второй снапшот). Там смотрим CID этого снапшота и копируем его в строку parentCID диска -00003.vmdk (третьего снапшота), ну а после — залезаем в .vmx и в строке fileName указываем имя файла снапшота (в моем случае *-0003.vmdk)
В итоге получилось следующее.
*.vmdk
CID=387edddf
parentCID=ffffffff
*-00001.vmdk
CID=0284jf712 (все CID`ы я взял от болды)
parentCID=387edddf
*-00002.vmdk
CID=732fhhtud
parentCID=0284jf712
*-00003.vmdk
CID=3747jfj4ff
parentCID=732fhhtud
.vmx
scsi0:1.present = "true"
scsi0:1.fileName = "-00003.vmdk"
scsi0:1.deviceType = "scsi-hardDisk"
Включаю ВМ, вижу, что данные восстановлены. Кажется, отпустило. Копирую все на другой сервер, стопаю машину (она уже кричит о неисправности дисков и каких-то других критических проблемах), возвращаю настройки *.vmx назад и копирую файлы обратно на рабочую машину. Ура.
Заключение
Эта история научила меня нескольким золотым истинам, которые так и не удалось до этого понять.
Во-первых, бекапить все всегда и везде и не на диск внутри виртуалки, как я делал до этого. Надо иметь один, а то и два бекапных диска, чтобы не было такого двухдневного простоя. (удалились файлы? Откатываемся, копируем файлы из бекапа, и простой — не 48 часов, а часа 2 от силы) Во-вторых, не делать ничего на тяжелую голову в час ночи (уйдя бы спать, я бы с чистой головой в пятницу пришел бы к другому выходу, а не наломал дров во втором часу ночи) В-третьих, не делать какие-то важные поправки в рабочие машины. Накатать вторую виртуалку, там сделать снапшот, потом сделать parent-диск основным и посмотреть, что будет после — вот как надо было делать. Ну и в-четвертых, делать еще больше бекапов. Не просто ВМ, но и самой esxi в целом.
P.S. ресурсы, которые в конце-концов мне помогли:
Тот самый форум с потрясающим apavlyuchenko (мы не знакомы, если что)
Страница на knowledge base от вмваре с описанием моей проблемы и путях ее решения
Картинка, которую я использовал
если кому-то интересно, в комментариях смогу оставить те ресурсы, статьи которых мне не помогли
P.S.S
К сожалению, проблема исчезания места по-прежнему актуальна. Если у вас есть мысли или желание помочь мне разобраться с этим, прошу в комментарии. Мы можем там поговорить об этом. Или если вы знаете другой способ восстановления файлов из дисков снапшотов и тоже хотите им поделиться, то мне будет интересно это прочитать. Спасибо
Автор: ZloyKishechnik
