Всем привет. Некоторым это может показаться предостережением о том, чего не следует делать и почему некоторые важные технические работы в час ночи (в системе, о которой вы мало что понимаете) могут привести к огромному сбою и простою в течение двух дней.
Короткая заметка о системном администраторе-любителе, который только начинает погружаться в мир виртуализации.
История о том, как снапшоты не помогали, а мешали и месяц делали откат системы, а потом я вытащил оттуда все файлы с простоем в 2 дня и вернул систему.
Фон
После двух лет сидения на Никс системах, и в частности на сервере Ubuntu (16.04 LTS), я решил попробовать свои силы в виртуализации.Друг порекомендовал ESXi как бесплатное решение для небольших серверов (мой случай: 1 процессор + всего 8 ГБ ОЗУ).
Процесс переезда был осложнен тем, что нужно было сначала установить vmware workstation на компьютер под управлением Windows вместе с vmware конвертером, перенести туда готовую систему, затем установить esxi на сервер, а затем с помощью знакомого конвертера перенести систему в эсси.
Это такой долгий и мучительный путь.
Основная ошибка, которую я допустил при переносе и которая не дает мне покоя по сей день, заключается в том, что я использовал тонкий диск.
То есть находясь на чистом ubuntu-сервере с диском, отформатированным в exfat-4, у меня было около 223,8 ГБ места на ssd. Перейдя на esxi и отформатировав диск в их непонятный формат, я потерял всего 300 МБ, но именно из-за них мне не удалось сделать толстый диск, который (позже выяснилось) мне так нужен.
Начинать
Раньше я возился с сервером ubuntu (когда только «учился»), откатываясь и переустанавливая систему раз в месяц-два.Сейчас ломаю дрова с ESXi. Думаю, нет нужды описывать проблему тонких дисков (короче, расширив их пространство, они не «сужают» его в обратную сторону.
Они также могут выйти за пределы физического объема памяти на диске).
Во-первых, я использовал swap на том же SSD-накопителе, не настроив его должным образом в ESXi. Он жрал память, записывал туда какие-то временные файлы, а тем временем тонкий разрастался.
Во-вторых, я почему-то сделал снимки.
Я руководствовался в тот момент тем, что «ну удобно, быстро и все такое».
Еще не подозревая, какую чушь и какую медленную бомбу мне подложили.
В-третьих, я не уследил за быстро уменьшающимся объемом дискового пространства.
Начало
Первым звонком стала остановка главной машины 17 июля.Я получил уведомление по электронной почте о сбое хоста.
Зайдя в esxi его забрать (ну вдруг что-то может случиться), виртуальная машина сообщила мне хорошие новости (скриншота, к сожалению, нет).
Вкратце всплывающее окно выглядело примерно так: «Извините, у меня закончилось место на диске.
Ваша виртуальная машина остановлена.
Очистите место, и вы сможете продолжить использовать виртуальную машину.
"Повторить попытку" "Отмена" На тот момент проблема решилась удалением второй ВМ, которая занимала около 16Гб.
Но это было временное решение, так как каждый день 5Гб продолжали куда-то пропадать, хотя увеличения этих файлов в системе не было.
В итоге прохладным вечером четверга 19 июля я впервые написал тостеру об этой проблеме.
Ответа не было.
Я думаю, это из-за непопулярного тега esxi. Дальше было безуспешное гугление, затем удаление снимков.
В этот момент пропали 5 гигабайт, свободного места стало больше, но не настолько, чтобы забыть об этой проблеме.
После этого, поразмыслив, я начал изучать иерархию снимков.
Последний, 000003, занимал на тот момент 12 ГБ места.
В настройках ВМ он значился как файл активного диска, с которого загружалась машина.
Недолго думая, я удалил с жесткого диска 1 дисковый файл с активным снэпшотом и вставил на его место родительский диск всей виртуальной машины.
Система загрузилась (ура), а вместе с ней и файлы за 30 июня.
Дата последней модификации всех файлов на родительском диске.
Подозреваю, что именно в этот день я создал первый снимок.
Места больше не было, что логично.
Свободного места еще около 5гб, но файлы пропали.
Первые мысли логичны: что я сделал, все файлы до 19 июля пропали.
Затем я увидел, что файлы снимков не были удалены.
Однако при попытке загрузить их в качестве основного диска ESXi жаловался на модифицированный родительский диск, чего быть не должно «Родительский виртуальный диск был модифицирован с момента создания дочернего» Моя вечная ошибка на протяжении следующих двух дней.
Гугление
Время приближалось к двум часам ночи, и я оставил все тщетные попытки извлечь хоть какую-то информацию из этих несчастных файлов снимков *-0000?-.vmdk. Утро пятницы началось с активного, очень активного гугления типа «как извлечь файлы из vmdk».
Статьи, линукс ридер (программа на винде) и все такое прочее попадалось очень часто.
Эти 223 гигабайта я перенес с сервера на Windows-ноут по каналу 100Мбит, что было очень больно.
Попробовал смонтировать SSD-диск формата vmware к системе Linux, накатил на него vmware-tools, он жаловался на несовместимость версий (последняя поддерживаемая была 5, но у меня была 6.5).
Попытки открыть через Windows и Java также оказались тщетными.
И даже после того, как мне удалось получить доступ (с помощью программы чтения Linux в Windows) к файлу *-flat.vmdk, я получил файлы только до 30 июня.
Все дальнейшие попытки смонтировать файлы снимков ничего не дали; программа пожаловалась на невалидный диск и отказалась работать дальше.
Выход найден
Пятница закончилась, я был измотан, а также расстроен тем, что файлы не удалось вернуть.Но суббота началась удачно.
Когда я погуглил ошибку (почему не сделал сразу неизвестно) "Родительский виртуальный диск был изменен с момента создания дочернего" в первой строке гугл дал ссылку на страницу vmware. Куча страшных символов, красные линии и все такое меня сразу напугало.
Я открыл ссылку и оставил ее в надежде, что найду что-то более понятное.
И оно было найдено.
https://communities.vmware.com/thread/323730 Русскоязычный форум VmWare и подобная проблема встретила меня в Интернете.
Вероятно, это не тот случай, что у меня, но, пролистав вниз и прочитав комментарии, я попробовал сделать что-то подобное.
В текстовом редакторе, подключаясь к esxi по sftp, я открыл файл с настройками родительского диска.
.
vmdk (не -flat.vmdk) Узнал CID диска, после чего зашёл в *-00001.vmdk, делая так, как описал человек с ником Апавлюченко на форуме.
В первом снимке CID родительского диска должен был быть указан в полях CID и ParentCID. И затем в файле .
vmx в полях scsi0:1.present = «ложь» scsi0:1.имя_файла = " .
vmdk" scsi0:1.deviceType = "scsi-hardDisk" измените параметр FALSE на TRUE и .
vmdk включен -00001.vmdk. И действительно, после этого машина загрузилась и больше не жаловалась на ошибку.
И о чудо! Файлы появились до того, как был создан второй снимок! На форуме друг описал способ восстановления файлов только с одного снимка.
Но у меня случай тяжелый (видимо, из-за моей болезни, которая называется «тыкать все руками на рабочей машине»).
И у меня был не один снимок, а три.
Что логично, необходимо было продолжить изменение файлов.
Итак, вот мои действия.
Откройте родительский диск.
Давайте узнаем его CID. Далее скопируйте CID родительского диска в строку родительского CID диска.
-00001.vmdk (первый снимок).
Там смотрим CID этого снапшота и копируем его в строку родительского CID диска -00002.vmdk (второй снимок).
Там смотрим CID этого снапшота и копируем его в строку родительского CID диска -00003.vmdk (третий снимок) и после этого лезем в .
vmx и в строке fileName указываем имя файла снапшота (в моем случае *-0003.vmdk) Результат был следующий.
* .
vmdk CID=387edddf родительскийCID=ffffffff * -00001.vmdk CID=0284jf712 (все CID я взял жирным шрифтом) родительскийCID=387edddf * -00002.vmdk CID=732fhhtud родительскийCID=0284jf712 * -00003.vmdk CID=3747jfj4ff родительскийCID=732fhhtud .
vmx scsi0:1.present = "истина" scsi0:1.имя_файла = " -00003.vmdk" scsi0:1.deviceType = "scsi-hardDisk" Включаю ВМ и вижу, что данные восстановлены.
Кажется, отпустило.
Копирую все на другой сервер, останавливаю машину (уже вопит про сбой диска и еще какие-то критичные проблемы), возвращаю настройки *.
vmx обратно и копирую файлы обратно на рабочую машину.
Ура.
Заключение
Эта история научила меня нескольким золотым истинам, которые я никогда раньше не мог понять.Во-первых, бэкапить всё всегда и везде, а не на диск внутри виртуальной машины, как я делал раньше.
Нужно иметь один, а то и два резервных диска, чтобы не было такого двухдневного простоя.
(файлы удалены? Откатываемся, копируем файлы из резервной копии, и время простоя не 48 часов, а максимум 2 часа) Во-вторых, ничего не делайте с тяжелой головой в час ночи (если я пошел спать, я бы пришел с ясной головой в пятницу к другому выходу, а не бардак в два часа ночи) В-третьих, не вносите никаких важных поправок в рабочие машины.
Создайте второй виртуальный диск, сделайте туда снимок, затем сделайте родительский диск основным и посмотрите, что будет после — так и надо было сделать.
И в-четвертых, делайте еще больше резервных копий.
Не только виртуальная машина, но и сам esxi в целом.
P.S. Ресурсы, которые в конечном итоге мне помогли:
Тот же форум с потрясающей Апавлюченко (мы не знакомы, если это так) Страница базы знаний от vmware с описанием моей проблемы и способов ее решения Картинка, которую я использовал Если кому интересно, могу оставить в комментариях те ресурсы, статьи которых мне не помогли.
P.S.S.
К сожалению, проблема исчезновения космоса по-прежнему актуальна.Если у вас есть какие-либо мысли или желание помочь мне разобраться в этом, пожалуйста, прокомментируйте.
Мы можем поговорить об этом там.
Или, если вы знаете другой способ восстановления файлов со снимков дисков и тоже хотите им поделиться, мне будет интересно его прочитать.
Спасибо Теги: #*nix #Виртуализация #Системное администрирование #esxi #Восстановление данных #рабочая станция vmware #сервер Ubuntu 16.04
-
Критика Веб-Дизайна
19 Oct, 24 -
Дорабатываем Оборудование Turnigy 9X
19 Oct, 24 -
Linkmeup. Выпуск 3
19 Oct, 24 -
Опрос Разработчиков Stackoverflow (2017 Г.)
19 Oct, 24 -
Ох Стоит Activex
19 Oct, 24
