Проблема с моментальным снимком VMWare
Итак, у меня есть особенно тревожная проблема, оставленная старым ИТ-отделом. Мы запускаем несколько снимков, и никто не подумал их объединить, вероятно, потому, что никто не был достаточно опытным в VMWare, чтобы понять, что они должны это сделать. Итак, вот проблема, с которой я остался:
Предполагая, что изображение не загружается, мы имеем следующее:
- -> ВМ 343,7 ГБ
- -> Снимок 1 5 14/14/2018, 150 ГБ
- ---> Снимок 2 13.06.2018, 9,03 ГБ (Снимок памяти ВМ: НЕТ)
- ----> Снимок 3 13.06.2018, 31,19 ГБ
- -----> Снимок 4 14.06.2018, 386,24 МБ
- ------> Снимок 5 27.08.2018, 45,43 ГБ
- ------- > Вы здесь (ура) 59,5 ГБ
Я немного покопался, и, похоже, лучшее решение - это сделать следующее:
- Создайте резервную копию файлов виртуальной машины, в идеале, когда она выключена. Достаточно просто скопировать всю ВМ во второе место.
- Удалите снимки. В идеале в нерабочее время для консолидации потребуется время. Много времени. Будет быстрее, когда ВМ выключена.
- Проверьте, не повреждена ли ВМ, если нет, восстановите резервную копию. Источник: Консолидация старых снимков VMWare
Мой вопрос к вам:
Эти снимки выполняются уже довольно давно, они самые старые с 2018 года. Судя по тому, что я читаю, это может вызвать некоторое ухудшение работы. если не полностью повредить виртуальную машину на этом этапе.
- Стоит ли мое время попытаться исправить это?
- Если нет, мне лучше сделать резервную копию баз данных, хранящихся на сервер и откат сервера?
Если я правильно понял, при возврате он возвращается к состоянию до создания снимков, отменяя изменения, сделанные в снимке. В то время как удаление снимков объединяет все внесенные изменения в одно целое. (Странная терминология VMWare)
Кроме того, это сервер с тонким предоставлением. Из-за нехватки места на диске я обнаружил эту проблему, и на данный момент у меня осталось около 4 ГБ.
Согласно «Оцените время, необходимое для консолидации моментальных снимков виртуальных машин (2053758)» на https://kb.vmware.com/s/article/2053758 , дополнительный файл Delta создается во время консолидации, если виртуальная машина включена. Это находится в разделе ЗАМЕТКИ и гласит
. Если консолидация дисков начинается при включении виртуальной машины, создается дополнительный файл дельты для отслеживания измененных блоков, который, наконец, записывается на базовый диск в конце консолидации. . Однако при удалении только одного снимка, который не является текущим, дополнительный файл дельты не требуется.
«Никакой дополнительный файл дельты не требуется при удалении только одного снимка, который не является текущим». Удаление по одному в порядке от самого старого к самому новому не займет дополнительного места на диске, пока вы не перейдете к самому последнему снимку. Это будет работать в фоновом режиме.
Тема сообщества VMware по адресу https://communities.vmware.com/thread/560315 также имеет эту проблему. В худшем случае базовый / родительский диск должен иметь возможность расти только до объема данных в моментальных снимках.
Кроме того, здесь представлена база знаний VMware о консолидации моментальных снимков в ESX 3.5 и ESX 4.0 (для чего требуются обновления исправлений) . В ESX 5 и выше эта функция встроена и выполняет ту же операцию. Он охватывает те же вопросы, что и обсуждение сообщества, которое я связал. https://kb.vmware.com/s/article/1023657 .
Таким образом, мой ответ на дополнительные требования к пространству: «Если вы сначала выключите виртуальную машину, то дополнительных требований к пространству не потребуется. Или вы можете удалять по одному снимку за раз, от самого старого к самому новому, и освободившееся пространство позволит вам удалить самый новый снимок, пока он еще включен ».
Возврат снимка, сделанного несколько лет назад, свои проблемы. Вы теряете доверие к домену, поскольку пароль компьютера больше не тот, который должен быть. В зависимости от предоставленных вами временных меток вы также потеряете 1,5 года обновлений Windows и любых других обновлений сторонних приложений или обновлений, выполненных вручную. Изменения реестра, которые не произошли через GPO. Настройки. Вы теряете все данные, которые хранятся в другом месте, например, документы или папки для загрузок (если у вас нет их резервной копии). Все это нужно будет вернуть.
Если вас беспокоит повреждение, выключите виртуальную машину, скопируйте файлы на диске в дополнительное хранилище и попытайтесь выполнить консолидацию, как вы упомянули в качестве варианта. Или просто создайте новый сервер и перенесите базу данных ... если у вас есть место в другом месте, поскольку вы уже упоминали о проблемах с пространством.
Я не совсем уверен в вашем вопросе, поэтому постараюсь ответить на оба вопроса.
Вы определенно захотите консолидировать этот диск, поскольку моментальные снимки не предназначены для использования в качестве «долгосрочных резервных копий». Когда вы создаете моментальный снимок (игнорируя VVOL для простоты), vSphere "замораживает" файл VMDK (файл в хранилище данных, представляющий жесткий диск виртуальной машины) для дисков виртуальных машин и начинает записывать все изменения в отдельную дельту. файл. Этот файл может вырасти только до размера исходного VMDK (примерно, могут возникнуть дополнительные накладные расходы). Если затем вы сделаете второй снимок, ваш первый дельта-файл снова будет "заморожен", и vSphere запустит второй дельта-файл.
Когда вы затем удаляете снимок, vSphere берет дельта-файл и записывает все изменения обратно в исходный VMDK. Однако, пока он делает это с включенной виртуальной машиной, ему нужно где-то продолжать записывать изменения, поступающие от виртуальной машины, поэтому он создает временный файл дельты для сохранения изменений в VMDK во время консолидации снимка. Когда это будет сделано, он снова объединит гораздо меньший временный дельта-файл и обычно останавливает виртуальную машину на долю секунды, чтобы дисковый ввод-вывод был тихим, пока он объединяет временный файл.
Однако, если вы удалите промежуточный snapshot, у vSphere уже есть еще один более новый файл дельты для работы, поэтому он может просто делать это, не затрагивая виртуальную машину. Этим можно воспользоваться, если вы не хотите минимизировать влияние удаления большого снимка, просто сделайте новый снимок, удалите старый в фоновом режиме, а затем удалите гораздо меньший снимок, когда это будет сделано.
Возврат работает немного другое. Здесь вы откатываете состояние виртуальной машины, что требует гораздо меньше ресурсов, вы просто удаляете дельта-файл и перезапускаете виртуальную машину с исходным VMDK (вы также можете сделать снимок памяти, который затем вернет виртуальную машину в состояние с включенным питанием). по состоянию).
Итак, зная все это;
Если ваша виртуальная машина работает нормально, хотя и немного медленнее из-за снижения производительности, вы должны сделать следующее:
- Убедитесь, что у вас есть хорошая резервная копия виртуальной машины
- Выключите виртуальную машину, чтобы ускорить работу
- Удалите все промежуточные моментальные снимки, начиная с самого старого.
- Удалить последний моментальный снимок
- Запустить объединение дисков, если эта опция доступна.
Если ваша виртуальная машина сломана, выключите ее и восстановите копию из резервной копии / восстановите ее. Последний вариант - вернуться к древнему снимку. Моментальные снимки предназначены для того, чтобы быть «о, я случайно удалил весь диск C: при выполнении какой-то работы, позвольте мне вернуться к моему снимку, который я сделал 30 минут назад», а не резервной копией.