Итак, у меня есть особенно тревожная проблема, оставленная старым ИТ-отделом. Мы запускаем несколько снимков, и никто не подумал их объединить, вероятно, потому, что никто не был достаточно опытным в VMWare, чтобы понять, что им нужно это сделать. Итак, вот проблема, с которой я остался:
Предположим, что изображение не загрузилось, тогда имеем следующее:
- ->Виртуальная машина 343,7 ГБ
- --> Снимок 1 14.05.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 ГБ.
решение1
Согласно «Оценке времени, необходимого для консолидации снимков виртуальных машин (2053758)» наhttps://kb.vmware.com/s/article/2053758, дополнительный файл Delta создается во время консолидации, если ВМ включена. Это находится в разделе ПРИМЕЧАНИЯ и гласит
Если консолидация дисков запускается при включении виртуальной машины, создается дополнительный дельта-файл для отслеживания измененных блоков, который в конце консолидации записывается на базовый диск. Однако при удалении только одного снимка, который не является текущим, дополнительный дельта-файл не требуется.
"Дополнительный файл дельта не требуется при удалении только одного снимка, который не является текущим". Удаление по одному снимку за раз в порядке от самого старого к самому новому не будет занимать дополнительное место на диске, пока вы не дойдете до самого последнего снимка. Это будет работать в фоновом режиме.
Тема сообщества VMware наhttps://communities.vmware.com/thread/560315также имеет эту проблему. В худшем случае базовый/родительский диск должен иметь возможность увеличиваться только до объема данных в моментальных снимках.
Кроме того, вот VMware KB о консолидации снимков в ESX 3.5 и ESX 4.0 (что требует обновлений патчей). ESX 5 и выше имеют эту встроенную функцию и выполняют ту же операцию. Она охватывает те же моменты, что и обсуждение сообщества, на которое я дал ссылку.https://kb.vmware.com/s/article/1023657.
Таким образом, мой ответ на вопрос о дополнительных требованиях к пространству таков: «Никаких дополнительных требований к пространству не будет, если вы сначала выключите виртуальную машину».ИлиВы можете удалять по одному снимку за раз, от самого старого к самому новому, а освободившееся место позволит вам удалить самый новый снимок, пока он еще включен».
Возврат снимка к состоянию на несколько лет назад имеет свои проблемы. Вы теряете доверие домена, поскольку пароль компьютера-машины больше не тот, что должен быть. На основе предоставленных вами временных меток вы также потеряете 1,5 года обновлений Windows и любых других обновлений сторонних приложений или обновлений, выполненных вручную. Изменения реестра, которые не были внесены через GPO. Настройки. Вы теряете все данные, которые хранятся в другом месте, например, документы или папки загрузок (если у вас нет резервной копии). Все это придется вернуть обратно.
Если вас беспокоит повреждение, то отключите виртуальную машину, скопируйте файлы на диске в дополнительное хранилище и попробуйте консолидировать, как вы упомянули в качестве варианта. Или просто постройте новый сервер и перенесите базу данных... если у вас есть место в другом месте, поскольку вы уже упоминали проблемы с пространством.
решение2
Я не совсем уверен в сути вашего вопроса, поэтому попробую ответить на оба.
Вы определенно хотите консолидировать этот диск, так как моментальные снимки не предназначены для «долгосрочного резервного копирования». Когда вы создаете моментальный снимок (игнорируя VVOL для простоты), vSphere «замораживает» VMDK-файл (файл в хранилище данных, представляющий жесткий диск виртуальной машины) для дисков виртуальных машин и начинает записывать все изменения в отдельный дельта-файл. Этот файл может вырасти только до размера исходного VMDK (приблизительно, могут быть некоторые дополнительные накладные расходы). Если вы затем сделаете второй моментальный снимок, ваш первый дельта-файл снова «замораживается», и vSphere запускает второй дельта-файл.
Когда вы затем удаляете снимок, vSphere берет файл дельты и записывает все изменения обратно в исходный VMDK. Однако, пока он делает это с включенной виртуальной машиной, ему нужно где-то продолжать записывать изменения, поступающие от виртуальной машины, поэтому он создает временный файл дельты, чтобы сохранить изменения в VMDK, пока он консолидирует снимок. Когда это сделано, он снова консолидирует гораздо меньший временный файл дельты и обычно останавливает виртуальную машину на долю секунды, чтобы ее дисковый ввод-вывод оставался тихим, пока он консолидирует временный файл.
Однако если вы удалите промежуточный снимок, у vSphere уже есть другой новый файл delta для работы, поэтому он может просто делать свое дело, не влияя на VM. Это можно использовать, если вы не хотите минимизировать влияние удаления большого снимка, просто сделайте новый снимок, удалите старый в фоновом режиме, а затем удалите гораздо меньший снимок, когда он будет готов.
Возврат работает немного по-другому. Здесь вы откатываете состояние виртуальной машины, что гораздо менее ресурсоемко, вы просто удаляете файл дельты и перезапускаете виртуальную машину с исходным VMDK (вы также можете сделать снимок памяти, который затем вернет виртуальную машину в состояние включения).
Итак, зная все это;
Если ваша виртуальная машина работает нормально, хотя и немного медленнее из-за снижения производительности, вам следует сделать следующее:
- Убедитесь, что у вас есть хорошая резервная копия виртуальной машины.
- Выключите виртуальную машину, чтобы ускорить процесс.
- Удалите все промежуточные снимки, начиная с самого старого.
- Удалить последний снимок
- Запустите консолидацию дисков, если такая возможность доступна.
Если ваша виртуальная машина сломалась, выключите ее и восстановите копию из резервной копии/пересоберите ее. Возврат к старому снимку должен быть вашим последним вариантом. Снимки предназначены для того, чтобы быть «ой, я случайно удалил весь диск C: во время выполнения какой-то работы, позвольте мне вернуться к моему снимку, который я сделал 30 минут назад», а не для резервного копирования.