Я полагаю, что существуют способы перенаправить домены с помощью бесплатного веб-сервиса или разрабатывая собственный инструмент.
Попробуйте это:
Когда виртуальная машина имеет активный моментальный снимок, ввод-вывод виртуального диска не выполняется для фактических файлов .VMDK виртуальной машины, но вместо этого они остаются неизменными, и любые изменения в виртуальной машине записываются в разные физические файлы; это позволяет восстановить предыдущее состояние виртуальной машины, но имеет три важных побочных эффекта:
Действительно, лучше не хранить активные снимки в течение длительного времени. Если вам нужно долгосрочное резервное копирование виртуальной машины в заданном состоянии, вы можете просто скопировать виртуальную машину в другое место: это не повлияет на производительность виртуальной машины, и вы в любом случае будете использовать меньше дискового пространства, чем то, что будет заполняться долгосрочными снимками со временем.
Кроме того, наличие копии виртуальной машины, хранящейся в другом месте, действительно поможет вам, если вы потеряете виртуальную машину: моментальные снимки хранятся вместе с виртуальной машиной, которой они принадлежат, и полезны только в том случае, если виртуальная машина доступна; они совершенно бесполезны в случае реальной потери данных (например, сбоя хранилища данных) и поэтому не могут использоваться в качестве реальных резервных копий.
Вот некоторая официальная документация по снимкам:
http: // kb. vmware.com/selfservice/microsites/search.do?cmd=displayKC&externalId=1015180
Некоторые форматы моментальных снимков, используемые vmware, со временем снижают производительность, поскольку в них хранится больше данных. Формат «разреженного экстента», который, как мне кажется, по-прежнему используется по умолчанию в последних версиях, похоже, не имеет этого свойства (вы смотрите на 3 чтения за чтение и до 2 чтения или 3 записи за запись, но это не так. не становится хуже по мере заполнения диска). Итак, я не совсем уверен, что свойство «не хранить снимки надолго» является обязательно правильным советом в любое время.
Однако я заметил одну вещь: объединение снимков занимает возрастов по мере их увеличения. В зависимости от вашего варианта использования, это может быть или не быть проблемой.
Что касается вашего другого вопроса о «временном резервном копировании», это просто - резервное копирование предназначено для того, чтобы пережить потерю основного хранилища данных . Поскольку моментальные снимки и исходные данные хранятся вместе (а моментальный снимок бесполезен без базового образа), вы теряете большую часть - следовательно, снимок ни в коем случае не является резервной копией.
В качестве решения для запроса вашей команды на создание образа чистой установки или определенного состояния я бы рекомендую использовать шаблоны. Шаблоны клонируют виртуальную машину (в основном просто копию) в состояние, которое нельзя включить или изменить, его можно просто использовать как ссылку на клонированные копии. Так, например, если у меня есть шаблон «Установка Debian по умолчанию», и команда сервера запрашивает три новых сервера, я просто создаю три новых клона, настраиваю и готово.
То же самое можно сделать и для вашего второй сценарий. Если виртуальная машина переходит в состояние, на которое вы хотите сослаться, создайте шаблон. С этого момента, когда вам понадобится ссылаться на него, просто клонируйте еще одну копию.
То же самое можно сделать и для вашего второго сценария. Если виртуальная машина переходит в состояние, на которое вы хотите сослаться, создайте шаблон. С этого момента, когда вам понадобится ссылаться на него, просто клонируйте еще одну копию.
То же самое можно сделать и для вашего второго сценария. Если виртуальная машина переходит в состояние, на которое вы хотите сослаться, создайте шаблон. С этого момента, когда вам понадобится ссылаться на него, просто клонируйте еще одну копию.
Идея создания моментального снимка - это скорее точка восстановления, прежде чем вы выполните некоторую реконфигурацию виртуальной машины (установите новое программное обеспечение, крупное обновление и т. Д.). Так что, если вы используете его, вы можете вернуться к тому моменту, когда он работал, и уйти, свистя, не обвиняя никого из своих коллег :)
И общая идея состоит в том, что вы объединитесь в какой-то момент в будущем ( когда вы можете отключить его на некоторое время, не затрагивая пользователей).
Вы не должны хранить моментальный снимок vmware по причинам, уже описанным другими здесь, но многие люди делают так, чтобы снимок vmware был снят и после этого сделано чисто (зависит на госте, что на самом деле делает снимок) вы берете снимок вашего массива хранения, чтобы получить, а затем вы можете сделать резервную копию / скопировать / архивировать / и т.д. этот снимок. После того, как вы создали реальный снимок вашего массива, вам необходимо как можно скорее удалить снимок vmware.
Я знаю, что эта публикация немного устарела, но поднятые вопросы и вопросы все еще очень актуальны.
Моментальные снимки VMware определенно не резервные копии. Хуже побочный эффект, который случился со мной и многочисленными клиентами, они хранят моментальный снимок VMware 6-месячной давности, на хосте ESXi происходит незапланированный сбой, вызывающий перезагрузку ESXi, или требуется перезагрузка для устранения сбоя. ESXi восстанавливается, виртуальные машины загружаются, и все данные возвращаются к моменту времени, когда был сделан снимок VMware.
В этом сценарии все изменения между моментом времени, когда были сделаны снимки VMware, и моментом сбоя просто теряются.
Поэтому я рекомендую делать снимки состояния VMware только для определенной цели и удалять их, как только они будут служить этой цели.