Создание согласованных с приложениями резервных копий виртуальных машин уровня хоста
Иллюстрации
Показать всеИзобретение относится к способу создания согласованных с приложениями резервных копий виртуальных машин уровня хоста. Техническим результатом является обеспечение эффективного создания согласованной с приложениями резервной копии без первоначальной приостановки или выключения виртуальной машины. Способ содержит отправку в виртуальную машину запроса на формирование согласованного с приложениями моментального снимка тома виртуальной машины упомянутой виртуальной машины, причем виртуальная машина выполнена с возможностью формирования этого согласованного с приложениями моментального снимка, пока виртуальная машина выполняется; прием сигнала, указывающего, что виртуальной машиной сформирован согласованный с приложениями моментальный снимок тома виртуальной машины; формирование моментального снимка тома хоста, причем том виртуальной машины хранится как файл на хосте; и извлечение согласованного с приложениями моментального снимка тома виртуальной машины из моментального снимка тома хоста. 3 н. и 17 з.п. ф-лы, 5 ил.
Реферат
Предшествующий уровень техники
1. Область техники, к которой относится изобретение
Так как компьютеризированные системы имеют возрастающую популярность, таким образом, есть необходимость хранить и создавать резервные копии электронных файлов и другой информации, созданных пользователями и приложениями, ассоциированным с ними. Вообще, компьютерные системы и связанные с ними устройства создают файлы по множеству причин, таких как в общем случае создания документа текстовой обработки в рабочей обстановке, так же как и создание файла, используемого для более сложных целей, связанных с базой данных. Кроме того, многие из этих документов могут включать в себя ценный результат работы или критически важную информацию, которая должна быть защищена. Следовательно, специалисту будет понятно, что существует множество причин, почему организация хочет создавать резервную копию электронных файлов на постоянной основе и, таким образом, обеспечивать надежное восстановление первоначально созданного файла, когда необходимо.
Так как вычислительные системы постоянно развиваются в более сложные конфигурации программного обеспечения и аппаратных средств, сложности, связанные с резервным копированием этих конфигураций, также возросли. В своей самой простой форме компьютер, создающий резервную копию, затрагивает просто копирование информации с диска или тома компьютера и передачу этой информации в местоположение хранения резервной копии. Простое копирование данных с диска, однако, становится гораздо более сложным при создании резервной копии больших наборов данных на множестве серверов в сети, особенно, когда наборы данных постоянно изменяются в течение процесса резервного копирования. Например, вместе с простым резервным копированием данных некоторые из проблем для больших организаций могут включать в себя необходимость сохранить данные быстрым, надежным и относительно непрерывным образом так, чтобы данные являлись также быстро восстанавливаемыми. Дополнительные заботы включают в себя то, как обращаться к различным серверным данным в первом примере, особенно, когда каждый сервер может иметь различные функции, которые могут сделать сервер более или менее доступным для заданной программы резервного копирования, в отличие от другого сервера.
Эти типы сложностей в резервном копировании серверных данных могут быть особенно трудными в виртуализированном серверном окружении. Как правило, виртуализированное серверное окружение затрагивает использование хост-сервера, на котором может быть установлена одна или более "виртуальных машин". Эти виртуальные машины содержат уникальные экземпляры операционной системы, которые установлены в выделенной части дискового пространства хост-сервера, и ресурсы (например, хост-память) и, таким образом, содержат границы отдельной машины. Таким образом, каждая виртуальная машина может быть представлена уникальным сетевым идентификатором и, таким образом, кажется отдельной и отличной в сети от самого хост-сервера. Кроме того, каждая виртуальная машина может также иметь дополнительные разделы хранения, сделанные в пространстве хоста, выделенном для виртуальной машины. Кроме того, в дополнение к получению впечатления отдельной машины от хост-сервера, виртуальная машина может также выглядеть как вмещающая множество логических дисков или томов, несмотря на размещение на физическом диске(-ах) хост-сервера. Соответственно, специалист может понять, что виртуальные машины могут использоваться в ряде важных способов, чтобы более эффективно распределять аппаратные ресурсы в организации.
Несмотря на эти преимущества, непросто скопировать тома хоста, на которых установлены виртуальные машины, и держать эти данные в качестве полезных (например, согласованными и действительными) при необходимости. Одна из причин этого затруднения происходит из природы самих виртуальных машин, как считается, они должны иметь различающиеся идентичности (например, включая в себя различающиеся операционные системы) относительно других виртуальных машин и относительно соответствующего хост-сервера(ов). Например, хост-сервер не может просто предписывать приложениям внутри виртуальной машины создавать "согласованный с приложениями" моментальный снимок своих данных, так как такие приложения, как правило, находятся под управлением виртуальной машины. Таким образом, когда хост создает моментальный снимок или резервную копию тома (или томов), на котором установлена виртуальная машина, процессы внутри виртуальной машины могут продолжать работать, и, по существу, копия виртуальной машины может вероятно включать в себя состояние данных и файлов, которые являются действительными для различных случаев времени. Т.е. копия данных виртуальной машины не будет "согласованной с приложениями". Если вы восстановите такую виртуальную машину, это может даже не функционировать правильно, если не вовсе не функционировать.
Как правило, "согласованная с приложениями" резервная копия означает, что приложения принимают участие в процессах подготовки резервного копирования и создают файлы приложения для резервного копирования на основе того, что находится на физическом диске, так же как и то, что находится в памяти. По существу, эти файлы или моментальные снимки для резервного копирования согласуются с текущим состоянием приложения и восстанавливаются посредством приложения в более поздний момент времени. В противоположность "согласованные с аварийным отказом" данные относятся к данным, по которым создаются резервные копии, как правило, без преимуществ вовлечения приложений, используемых, чтобы создавать данные в первом примере. Как результат, первичный продукт во время согласованного с аварийным отказом резервного копирования является набором данных, которые являются такими же, что и те, которые находятся на физическом диске во время процесса резервного копирования, не принимая во внимание то, что находится в памяти, и не принимая во внимание состояния приложения. Это похоже на то, как файловые данные могут существовать во время аварийного отказа всей системы, например во время потери питания или перезагрузки, и, таким образом, нет гарантии, например, согласованности с приложениями. В частности, для определенных сложных операционных окружений, особенно, где важно обеспечить настолько цельный переход, насколько возможно после резервного копирования, предпочтителен подход согласованного (т.е. согласованного с приложениями и/или файловой системой) резервного копирования.
Существует множество способов создания согласованной резервной копии данных тома. К несчастью, традиционные системы, которые пытаются создавать согласованные с приложениями резервные копии виртуальных машин (и соответствующих томов, управляемых ими), как правило, не могут эффективно создавать согласованную с приложениями резервную копию без первоначальной приостановки или выключения виртуальной машины. Это в типичном варианте заканчивается некоторым нежелательным простоем, который в некоторых случаях с определенным критически важным программным обеспечением может создавать отдельные трудности для администратора. Одной причиной для этого, таким образом, является то, что интересующий том может копироваться, пока дополнительные записи не делаются в томе, так что данные, сформированные посредством приложения, все согласуются с одним и тем же экземпляром во времени. Конечно, в окружении, где готовый, непрерывный и эффективный доступ к данным является важным, приостановка или выключение виртуальной машины, чтобы создавать резервную копию, являются менее желательными и могут создавать утечку ресурсов организации.
Другими способами, которыми организация может попытаться создавать согласованные с приложениями резервные копии виртуальной машины, является установка особого агента резервного копирования в каждом экземпляре данной виртуальной машины. Как правило, агент резервного копирования будет сконфигурирован, чтобы взаимодействовать со средствами записи приложения в операционной системе, чтобы создавать согласованную с приложениями резервную копию, как может в обычном случае быть выполнено на уровне хоста для главного тома хост-сервера. К несчастью, нельзя просто установить новые агенты резервного копирования для каждой виртуальной машины. Например, организации в типичном варианте будет необходимо приобрести нового отдельного агента резервного копирования (или лицензии) для каждой виртуальной машины и затем установить каждый агент резервного копирования в виртуальной машине. Специалист поймет, что это может представлять довольно значительную трудность с точки зрения стоимости и расхода ресурсов (например, включающих в себя служебное управление) для больших организаций, которые могут запускать десятки, сотни или даже тысячи виртуальных машин.
Соответственно, существует ряд трудностей, связанных с резервным копированием виртуальных машин, которые могут быть устранены.
Краткое изложение сущности изобретения
Осуществления настоящего изобретения предоставляют системы, способы и компьютерные программные продукты, выполненные с возможностью создавать согласованные резервные копии уровня хоста одной или более виртуальных машин. В частности, осуществления настоящего изобретения предоставляют возможность создавать резервную копию хост-сервера и соответствующей одной или более виртуальных машин с помощью существующих средств запроса (запросчиков) резервного копирования и средств записи согласованным образом без необязательных значительных перерывов в работе одной или более виртуальных машин. В одном осуществлении, например, средство записи хост-сервера (например, VSS-средство записи виртуального сервера) инструктирует каждую виртуальную машину создавать один или более согласованных с приложениями моментальных снимков своих собственных данных тома уровня виртуальной машины. Приложение резервного копирования на хост-сервере также создает моментальные снимки томов уровня хоста, на которых установлены одна или более виртуальных машин (например, их файл виртуального жесткого диска). Хост-сервер может затем извлечь ранее созданные моментальные снимки уровня виртуальной машины из моментальных снимков уровня хоста и закончить процессы резервного копирования.
Например, со стороны хост-сервера способ создания согласованной резервной копии данных тома виртуальной машины без ненужного требования остановки или перезагрузки одной или более виртуальных машин может затрагивать идентификацию по меньшей мере одной виртуальной машины, имеющей один или более компонентов для процессов резервного копирования с участием средства записи. Кроме того, способ может затрагивать отправку инструкции каждой из этой одной или более виртуальной машины, чтобы подготовить согласованный с приложениями моментальный снимок уровня виртуальной машины. Способ может также затрагивать идентификацию того, что операции моментального снимка в упомянутой по меньшей мере одной виртуальной машине завершены. Кроме того, способ может затрагивать создание одного или более моментальных снимков уровня хоста одного или более томов хоста, на которых установлены идентифицированные одна или более виртуальных машин. Способ может еще дополнительно затрагивать извлечение согласованного с приложениями моментального снимка томов виртуальной машины, сделанного упомянутой по меньшей мере одной виртуальной машиной.
В противоположность, со стороны виртуальной машины способ создания согласованной резервной копии одного или более томов виртуальной машины в ответ на инструкции от средства записи хоста из состава хост-сервера может затрагивать прием запроса от средства записи хоста, чтобы идентифицировать доступные компоненты программного обеспечения. Способ может также затрагивать прием запроса от средства записи хоста, чтобы сделать моментальный снимок одного или более томов, вмещаемых виртуальной машиной, с помощью по меньшей мере одного из этих доступных компонентов программного обеспечения. Кроме того, способ может затрагивать отправку инструкций одному или более средствам записи приложений в виртуальной машине, чтобы подготовить соответствующие одно или более приложений виртуальной машины для резервного копирования. Кроме того, способ может затрагивать отправку сигнала средству записи хоста, что приготовления моментальных снимков для каждого из упомянутых одного или более томов, вмещаемых внутри виртуальной машины, завершены.
Данное изложение сущности изобретения предусмотрено для того, чтобы в упрощенной форме представить набор идей, которые дополнительно описываются ниже в подробном описании. Это изложение сущности изобретения не предназначено для того, чтобы идентифицировать ключевые признаки или важнейшие признаки заявляемого изобретения, а также не предназначено для того, чтобы быть использованным в качестве помощи при определении объема заявляемого изобретения.
Дополнительные признаки и преимущества изобретения будут частично изложены в описании, которое следует ниже, и частично будут явствовать из описания или могут быть изучены при практическом использовании изобретения. Признаки и преимущества изобретения могут быть реализованы и получены посредством инструментов и комбинаций, детально указанных в прилагаемой формуле изобретения. Эти и другие признаки настоящего изобретения станут более полно явными из нижеследующего описания и прилагаемой формулы изобретения или могут быть изучены при практическом использовании изобретения, что изложено далее в данном документе.
Перечень чертежей
Чтобы описать способ, которым вышеперечисленные и другие преимущества и признаки изобретения могут быть получены, более конкретное описание изобретения, кратко описанного выше, будет представлено посредством ссылки на конкретные варианты его осуществления, которые иллюстрируются в приложенных чертежах. Понимание того, что эти чертежи изображают только типичные варианты осуществления изобретения и, следовательно, не должны рассматриваться как ограничивающие его объем, изобретение будет описано и объяснено с дополнительной конкретностью и деталями посредством использования сопровождающих чертежей, на которых:
Фиг.1A иллюстрирует общий схематический чертеж в соответствии с осуществлением настоящего изобретения, на котором приложение резервного копирования уровня хоста идентифицирует, с каких одной или более виртуальных машин могут быть сделаны резервные копии согласованным образом;
Фиг.1B иллюстрирует компоненты по фиг.1A, в которых хост-сервер инициирует процессы резервного копирования в связи с гостевым запросчиком уровня виртуальной машины в виртуальной машине в соответствии с осуществлением настоящего изобретения;
Фиг.1C иллюстрирует компоненты по фиг.1A-1B, в которых запросчик хост-сервера создает моментальные снимки томов хоста, в которых установлены одна или более виртуальных машин, так что моментальные снимки уровня хоста также содержат данные томов виртуальной машины, которые, в свою очередь, содержат моментальные снимки уровня виртуальной машины, выполненные ранее виртуальными машинами;
Фиг.1D иллюстрирует обзорный схематический чертеж в соответствии с осуществлением настоящего изобретения, в котором приложение резервного копирования, иллюстрированное на фиг.1A-1C, извлекает данные моментального снимка уровня хоста, имеющие данные моментального снимка уровня виртуальной машины, содержащиеся в них; и
Фиг.2 иллюстрирует блок-схемы способов, содержащих последовательности действий в соответствии с осуществлениями настоящего изобретения со стороны хост-сервера и виртуальной машины для предоставления согласованных с приложениями резервных копий виртуальных машин, установленных на одном или более томах хост-сервера.
Подробное описание
Осуществления настоящего изобретения распространяются на системы, способы и компьютерные программные продукты, выполненные с возможностью создавать согласованные резервные копии уровня хоста одной или более виртуальных машин. В частности, осуществления настоящего изобретения предоставляют возможность создавать резервную копию хост-сервера и соответствующей одной или более виртуальных машин с помощью существующих запросчиков резервного копирования и средств записи согласованным образом, без необязательных значительных перерывов в работе одной или более виртуальных машин. В одном осуществлении, например, средство записи хост-сервера (например, средство записи VSS виртуального сервера) инструктирует каждую виртуальную машину создавать один или более согласованных с приложениями моментальных снимков своих собственных данных тома уровня виртуальной машины. Приложение резервного копирования на хост-сервере также создает моментальные снимки томов уровня хоста, на которых установлены одна или более виртуальных машин (например, их файл виртуального жесткого диска). Хост-сервер может затем восстановить ранее созданные моментальные снимки уровня виртуальной машины из моментальных снимков уровня хоста и закончить процессы резервного копирования.
Специалист поймет после прочтения этого описания и формулы изобретения, что хост-сервер (например, через средство записи виртуального сервера) может также предоставлять возможность создания все еще согласованных резервных копий виртуальных машин, даже если они не могут быть легко идентифицированы как сконфигурированные для согласованных (например, согласованных с приложениями и/или файловой системой) процессов резервного копирования. Например, виртуальные машины могут быть выключены или иным образом не работать, либо виртуальные машины могут не быть установлены с соответствующими программными или аппаратными компонентами. Тем не менее, хост-сервер может использовать другие компоненты, чтобы скопировать тома хоста и соответствующие виртуальные машины способом, который сохраняет состояние и затем приостанавливает или останавливает виртуальные машины по меньшей мере на мгновение. Средство записи хост-сервера может затем предоставить возможность виртуальным машинам возобновить работу после того, как был сделан моментальный снимок тома(ов) хоста.
Специалист поймет после прочтения этого описания и формулы изобретения, что осуществления настоящего изобретения могут предоставлять согласованные резервные копии виртуальных машин способом, который минимизирует простой, и без необходимости покупки и установки новых агентов резервного копирования. По существу, организации, которые реализуют решения на базе виртуальной машины, могут предоставлять лучший хост-сервер, виртуальную машину и доступность данных в сетевой системе способом, который минимизирует потребление ресурсов организации.
Соответственно, фиг.1A иллюстрирует примерный хост-сервер 100, выполненный с возможностью управлять томами 110 и 115. В томах 110 и 115 установлены виртуальные машины 120 и 130 соответственно. С целью объяснения, хотя каждая виртуальная машина 120, 130 может быть задумана как отдельная вычислительная система на одном уровне, каждая виртуальная машина 120, 130 может также быть задумана как набор "файлов" (например, файл конфигурации виртуальной машины или "VMC" и один или более файлов виртуального жесткого диска - "VHD"), при взгляде с уровня хоста 100. В любом случае, хотя фиг.1A иллюстрирует одну виртуальную машину в каждом томе, это не требуется, и может быть установлено несколько виртуальных машин на любом томе данного хост-сервера 100. Подобным образом, каждая виртуальная машина может охватывать множество томов на одном или более хост-серверах.
Кроме того, каждая виртуальная машина может управлять дополнительными логическими дисками, которые эффективно выполнят роль дополнительных распределений томов в распределении(ях) тома, на котором установлена данная виртуальная машина. Например, фиг.1A показывает, что виртуальная машина 120 также управляет одним или более виртуальными физическими дисками, которые, тем не менее, являются частью хост-тома 100. Как правило, каждый виртуальный физический диск может также быть представлен файлом, таким как файл виртуального жесткого диска (т.е. VHD 123, 127 и т.д.). В частности, VHD-файл показан как физический диск внутри виртуальной машины, которая может дополнительно содержать дополнительный один или более томов (не показаны), содержащиеся на нем, при этом каждый том имеет свой собственный глобальный уникальный идентификатор ("GUID"). Таким образом, VHD-файл 123 (который в этой иллюстрации содержит только один том для простоты) может, таким образом, иметь том, который показан как логический диск "m:\" - или некоторый другой уникальный идентификатор, подходящий для данной операционной системы, в то время как VHD 127 (который также в этом случае включает в себя только один том) может иметь том, который показан в сети как "n:\", и т.д.
Кроме того, фиг.1A показывает, что хост 100 содержит приложение 105 резервного копирования, которое может также называться как "хост-запросчик" или "запросчик уровня хоста". Как правило, приложение 105 резервного копирования содержит последовательности выполняемых компьютером инструкций, сконфигурированных, чтобы управлять событиями резервного копирования на хосте 100. В одном осуществлении, таком как, например, операционная среда фирмы MICROSOFT, приложение 105 резервного копирования содержит запросчик службы теневого копирования томов ("VSS"). Фиг.1A также показывает, что приложение 105 резервного копирования, в свою очередь, может быть сконфигурировано, чтобы направлять свои инструкции резервного копирования через средство 125 записи хоста, которое также может называться как "средство записи хоста", "средство записи уровня хоста" или "VSS-средство записи виртуального сервера уровня хоста".
Как правило, средство 125 записи хоста содержит последовательности исполняемых компьютером инструкций, сконфигурированных, чтобы осуществлять инструкции резервного копирования, принятые от приложения 105 резервного копирования. В одном осуществлении, таком как в среде MICROSOFT, например, средство 125 записи хоста может содержать VSS-средство записи, такое как VSS-средство записи, используемое с MICROSOFT VIRTUAL SERVER. С целью объяснения ссылка в данном документе на компоненты MICROSOFT является только иллюстративной. В частности, специалист поймет после прочтения этой спецификации и формулы, что компоненты, модули, системы и функции, описанные в данном документе, могут быть применены к широкому множеству компонентов, модулей и функций, используемых в других операционных средах.
Чтобы выполнить согласованные резервные копирования виртуальных машин, хосту 100, как правило, будет нужно определить, какая из вмещаемых виртуальных машин может сообщить о соответствующих компонентах, сконфигурированных, чтобы делать согласованные резервные копии по возможности в первую очередь. В качестве вступительной части непрерывная ссылка делается в данном документе на процессы "согласованного с приложениями" резервного копирования или моментального снимка. Специалист поймет, однако, что согласованные с приложениями процессы резервного копирования являются только одним примером "согласованных" операций резервного копирования в соответствии с осуществлениями настоящего изобретения. Другие примеры согласованных процессов резервного копирования включают в себя согласованные с файловой системой и/или аварийным отказом процессы резервного копирования.
В любом случае и со ссылкой на согласованные с приложениями резервные копирования, например, некоторые виртуальные машины могут быть установлены с соответствующими средствами записи и запросчиками для создания согласованных с приложениями резервных копий, в то время как другие виртуальные машины могут быть установлены без соответствующих средств записи и запросчиков. Для этих виртуальных машин, работающих без таких соответствующих компонентов, хост 100 может все еще делать резервные копии этих виртуальных машин, но может необязательно делать так тем же образом, что и с соответствующими компонентами. В частности, хост 100 может быть сконфигурирован так, чтобы делать резервные копии тех виртуальных машин, которые сообщают о соответствующих компонентах без простоя или прерывания (или не виртуально), и альтернативно сконфигурирован, чтобы делать резервные копии тех виртуальных машин, которые не сообщают (т.е. с отсутствующими или не работающими) о соответствующих компонентах по меньшей мере с некоторым простоем или прерыванием.
Соответственно, фиг.1A показывает, что приложение 105 резервного копирования (т.е. "запросчик хоста") запускает службы резервного копирования по меньшей мере частично, отправляя запрос 103 средству 125 записи хоста. В этом случае запрос 103 предписывает средству 125 записи хоста идентифицировать, по каким виртуальным машинам могут быть созданы резервные копии "без простоя". Например, запрос 103 предписывает средству 125 записи хоста установить, какие из виртуальных машин 120, 130 и т.д. содержат соответствующие гостевые средства записи и/или запросчики для выполнения внутреннего согласованного с приложениями резервного копирования. В одном осуществлении в среде MICROSOFT, например, такие компоненты могут включать в себя совместимые с "VM-дополнениями", которые используются в инфраструктуре MICROSOFT VIRTUAL SERVER.
Эти и другие подобным образом сконфигурированные компоненты виртуальной машины сконфигурированы, чтобы взаимодействовать в виртуальной машине (и отвечать на инструкции от), например, с VSS-средством записи виртуального сервера уровня хоста. Фиг.1A также показывает, что при приеме запроса 103 средство 125 записи хоста может связываться через сообщение 111 (которое может быть, например, приватным интерфейсом прикладного программирования - "приватным API") с виртуальной машиной 120 и идентифицирует, что виртуальная машина 120 сообщает о компонентах в соответствии с "версией x". Например, фиг.1A показывает, что виртуальная машина 120 включает в себя "гостевой запросчик 140".
Фиг.1A также показывает, что средство 125 записи хоста дополнительно связывается (например, через сообщение 111) с виртуальной машиной 130 и что средство 125 записи хоста идентифицирует, что виртуальная машина 130 сообщает о компонентах согласно "версии y". В этом отдельном случае "версия y" означает, что виртуальная машина 130 не имеет соответствующих компонентов для процессов согласованного резервного копирования. В ответ на свои связи с виртуальными машинами (например, 120, 130 и т.д.) средство 125 записи хоста может отправить одно или более сообщений о своих собранных ответах обратно приложению 105 резервного копирования. Например, средство записи отправляет сообщение 113, которое указывает, что виртуальная машина 120 имеет версию "x", и сообщает о соответствующих компонентах и дополнительно указывает, что виртуальная машина 130 имеет версию "y", но не сообщает о соответствующих компонентах.
После приема фиг.1A показывает, что приложение 105 резервного копирования может получить сообщение 113 и сделать свои собственные определения о том, с каких виртуальных машин должны быть сделаны резервные копии, а с каких виртуальных машин не должны быть сделаны резервные копии. Например, фиг.1A показывает, что модуль 107 определения синтаксически разбирает информацию сообщения 113, помещает виртуальную машину 120 в категорию "VM для резервного копирования без простоя" и помещает виртуальную машину 130 в категорию "VM для резервного копирования с некоторым простоем" (или VM не для резервного копирования). В альтернативных осуществлениях средство 125 записи хоста просто делает свои собственные определения о том, для чего должно или не должно быть сделано резервное копирование (или резервное копирование с некоторым простоем), и затем сообщает такие категории обратно приложению 105 резервного копирования. В любом случае иллюстрированные категории сами по себе необязательно означают, что для виртуальной машины 130 не должно быть сделано резервное копирование. В большинстве случаев это просто означает, что с виртуальной машины 120 не может быть сделано резервное копирование соответственно согласованным образом, а виртуальная машина 130 может быть сконфигурирована, только чтобы сделать резервное копирование согласованным образом с некоторым простоем. После распределения по категориям каждой виртуальной машины приложение 105 резервного копирования начинает выполнение процессов резервного копирования.
Как показано на фиг.1B, например, приложение 105 резервного копирования отправляет инструкции 117a средству 125 записи хоста. Инструкции 117a, в свою очередь, говорят средству 125 записи хоста начать согласованные с приложениями процессы резервного копирования по меньшей мере относительно виртуальной машины 120. Средство 125 записи хоста затем подготавливает свое собственное сообщение 117b, которое говорит виртуальной машине начать "с участием средства записи" процессы резервного копирования. Средство 125 записи хоста затем отправляет сообщение 117b каждой виртуальной машине (например, 120), указанной приложением 105 резервного копирования, а каждая указанная виртуальная машина, в свою очередь, принимает сообщение 117b через свой соответствующий расположенный внутри гостевой запросчик.
Например, фиг.1B показывает, что гостевой запросчик 140 виртуальной машины 120 принимает сообщение 117b. В одном варианте осуществления средство 125 записи хоста может связываться (например, сообщение 111, 117b и т.д.) с гостевым запросчиком 140 через один или более приватных API, через вызовы удаленных процедур ("RPC") и т.п., хотя это не требуется во всех вариантах осуществления. В других осуществлениях, таких как, если средство 125 записи хоста и гостевой запросчик 140 расположены в раздельных местоположениях сети (или даже различных доменах), средство 125 записи хоста может связываться с другими соответствующими интерфейсами связи и/или компонентами. В частности, специалист поймет, что осуществления настоящего изобретения могут также быть применены на практике, даже когда необходимо сделать резервную копию виртуальной машины из удаленного местоположения через глобальную вычислительную сеть.
В любом случае и после запуска гостевой запросчик 140, таким образом, начинает процессы резервного копирования своих томов в соответствии с первоначальными инструкциями приложения 105 резервного копирования. Как показано на фиг.1B, например, гостевой запросчик 140 отправляет внутреннее сообщение 117c виртуальной машины приложениям, установленным на любых томах, управляемых виртуальной машиной 120. Сообщение 117c может включать в себя инструкции для каждого средства записи приложения (например, VSS-средства записи, не показано), чтобы подготовить для согласованных с приложениями процессов резервного копирования каждого тома, управляемого в нем, тома, содержащиеся на своих физических дисках (т.е. представленные VHD-файлами 123, 127). Как правило, каждое средство записи приложения может содержать исполняемые компьютером инструкции, которые могут быть включены в приложения и службы в виртуальной машине и которые помогают обеспечить согласованные с приложениями резервные копирования данных приложения.
Для приложений, которые работают при приеме запроса 117c, средство записи приложения может ответить, например, посредством подготовки своих хранилищ данных и гарантирования того, что в томе не будут выполняться записи (например, 123, 127), пока создается моментальный снимок. Чтобы сделать данные на диске согласованными, средство записи приложения может также сбросить свои буферы на диск или записать данные в памяти на диск. Кроме того, средство записи приложения может предоставлять информацию об имени приложения, иконках, файлах, которые включать или исключать, и стратегии восстановления файлов. Для приложений, которые не работают, соответствующее средство записи приложения может не отвечать на сообщение 117c, и гостевой запросчик 140 может, таким образом, предположить, что все данные, управляемые средствами записи приложений, в томе являются согласованными, базы данных закрыты и не требуется дополнительных действий для того, чтобы выполнить резервное копирование.
Как правило, средство записи приложения в соответствии с одним или более осуществлениями настоящего изобретения может быть ассоциировано с одним или более компонентами. Каждый компонент, в свою очередь, может содержать группу файлов (например, базу данных и набор журнальных файлов), которые должны быть скопированы как целое. Таким образом, каждому средству записи приложения не нужно предоставлять данные о каждом компоненте и каждом соответствующем файле компонента соответствующей службе резервного копирования (например, запросчику виртуальной машины, например гостевому запросчику 140). Каждое средство записи приложения может дополнительно предоставлять информацию о восстановлении данных на покомпонентной (и, следовательно, по каждому файлу каждого компонента) основе. В одном осуществлении, например, средство 125 записи хоста может предоставить список файлов, используемых, чтобы сохранить постоянную информацию об управляемых виртуальных машинах (например, 120, 130 и т.д.). Средство 125 записи хоста может сообщить, например, для каждой виртуальной машины путь файла конфигурации отдельной виртуальной машины, любые пути файла виртуального жесткого диска и т.д.
В любом случае и в ответ на инструкции 117c фиг.1B показывает, что соответствующие средства записи приложения в томах 123 и 127 создают согласованное с приложениями состояние данных своих томов. Данные тома, сообщенные релевантными приложениями для тома в соответствующем файле физического диска (например, VHD 123, 127), заключены в моментальные снимки тома. Например, фиг.1B показывает, что данные 145 тома в VHD 123 копируются как "чистовая копия данных" 155 и данные 150 в VHD 127 копируются как "чистовая копия данных" 160. Как правило, эти "чистовые" копии данных 155, 160 являются согласованными копиями (например, теневой копией тома) данных в моментальном снимке гостевого тома и, как правило, не составляют отдельные копии от самого моментального снимка. В частности, "чистовые копии" 155, 160, по существу, являются согласованными с приложениями копиями данных тома в моментальных снимках, содержащихся в файлах виртуального жесткого диска (VHD) 123 и 127 (фиг.1A) соответственно.
После того как каждая соответствующим образом сконфигурированная виртуальная машина (например, 120) сделала свою собственную внутреннюю, согласованную с приложениями (или "чистовую") копию томов своего физического диска (например, копия 155 данных 145), средство 125 записи хоста может предоставить возможность приложению 105 резервного копирования перейти к созданию моментальных снимков хост-томов (например, 110), на которых установлены соответствующим образом сконфигурированные виртуальные машины (например, 120). Данные тома виртуальной машины внутри этих моментальных снимков уровня хоста, однако, необязательно являются согласованными с приложениями (т.е. "черновыми" или "согласованными с аварийным отказом").
Как правило, "черновые" копии являются такими, что не могут быть гарантированы как согласованные с приложениями относительно данных тома виртуальной машины по меньшей мере частично, так как они не запускают процессы создания моментальных снимков приложения с участием средства записи в виртуальных машинах. Например, хост 100 может использовать средства записи приложения уровня хоста (например, средство 125 записи хоста), чтобы создавать резервную копию данных тома 110 с помощью процессов с участием средства записи, но, как упомянуто ранее, эти средства записи приложения уровня хоста будут только копировать файлы всей виртуальной машины, как они видимы хостом. Как результат, даже если использовать средства записи приложения уровня хоста, чтобы создавать согласованные с приложениями копии данных тома уровня хоста, каждая лежащая в основе виртуальная машина может подвергнуться различным изменениям данных в момент создания резервной копии тома 110 уровня хоста.
Например, фиг.1C пок