ЭФФЕКТИВНОЕ СОЗДАНИЕ ЧАСТЫХ РЕЗЕРВНЫХ КОПИЙ ЦЕЛОСТНЫХ ДЛЯ ПРИЛОЖЕНИЙ Российский патент 2011 года по МПК G06F12/16 

Уровень техники

С ростом популярности компьютеризированных систем увеличились и потребности в хранении и резервном копировании электронных файлов и другой информации, созданной пользователями и связанными с ними приложениями. Обычно компьютерные системы и относящиеся к ним устройства создают файлы по множеству причин, например в общем случае создания текстового документа в процессе работы, а также создания файла, используемого для более сложной базы данных. Кроме того, многие из этих документов могут включать в себя ценный результат работы или важную информацию, которые должны быть защищены. Поэтому понятно, что имеется множество причин, по которым организация захочет делать резервное копирование электронных файлов на регулярной основе и посредством этого при необходимости выполнять надежное восстановление первоначально созданного файла.

Несмотря на некоторые удобства, предоставляемые многими традиционными системами резервного копирования, механизмы, используемые многими традиционными системами, часто являются менее эффективными, чем оптимальные. Например, возможность создать резервную копию, целостную для приложений, может являться важным компонентом некоторых систем резервного копирования. Целостная для приложений (а также для файловой системы) резервная копия по существу представляет собой скопированный набор данных, который является целостным по состоянию файлов в конкретный момент времени. Например, если администратор резервного копирования скопировал все данные на заданном томе рабочего сервера, как раз когда данные могли быть в процессе записи или обновления, состояние файлов соответствующей резервной копии может не обязательно являться целостным для одного момента времени. Поэтому создание целостной для приложений резервной копии обычно включает в себя дополнительные усилия по согласованию состояния файла.

Однако следует понимать, что может иметься любое количество трудностей, связанных с созданием целостных для приложений резервных копий данных. Например, традиционные механизмы для создания резервных копий обычно включают в себя приложение, например, компонент резервного копирования почты или приложение базы данных, вызывающую один или более интерфейсов приложений (API) резервного копирования и/или восстановления. В частности, компонент резервного копирования может указать интерфейсам приложений (API) остановить запись некоторых конкретных дисковых данных на рабочем сервере и затем создать резервную копию (то есть "реплику") данных. К сожалению обычно не имеется простого способа для того, чтобы компоненты резервного копирования описывали свои данные для интерфейсов приложений (API) резервного копирования на рабочем сервере. Дополнительно усложняет эту трудность тот факт, что иногда может иметься большое количество интерфейсов приложений (API) резервного копирования, на которые может потребоваться ссылка во время процесса резервного копирования.

Кроме того, тот факт, что конкретное приложение, которое создало некоторые данные, запрашивает службу резервного копирования, часто подразумевает, что не все данные рабочего сервера могут быть скопированы в любой заданный момент времени. Например, традиционные механизмы резервного копирования часто являются специфическими для приложения в отношении копируемых данных. Такие специфические для приложения подходы резервного копирования часто включают в себя выполнение нескольких экземпляров во время процесса резервного копирования. Однако будет понятно, что выполнение нескольких экземпляров может являться неэффективным по ряду причин, будь то с точки зрения стоимости или расхода ресурсов.

Кроме того, даже использование приложений для обеспечения резервного копирования может являться несколько неэффективным, так как специфическое для приложений резервное копирование обычно не обеспечивает копии данных приложений на момент времени без существенных расходов ресурсов. Это может означать, что приложение может быть не в состоянии обеспечить целостную для приложений резервную копию на момент времени с высокой частотой (тем самым обеспечивая высокую степень детализации точек восстановления) без чрезмерной нагрузки как на рабочий сервер, так и на сервер резервного копирования. Таким образом, традиционные резервные копии, выполненные конкретным приложением, обычно не могут обеспечить "горячее резервирование" резервных копий на моменты времени, которые прошли лишь несколько минут назад.

Это общая нехватка возможности настройки степени детализации может распространяться на широкий спектр других проблем в системах резервного копирования. Например, традиционные системы резервного копирования может быть трудно настроить для типов файлов, конкретных папок или местоположений папок на отдельном томе. Таким образом, могут существовать трудности, связанные с тем, чтобы заставить традиционные системы резервного копирования выполнять резервное копирование данных рабочего сервера с большей степенью детализации, чем только один или несколько томов целиком, или только файлы целиком, в противоположность резервному копированию только тех частей файлов, которые были фактически изменены. Эти и другие подобные проблемы часто означают, что рабочий сервер и сервер резервного копирования выполнены с возможностью копировать и передавать между собой больше данных, чем необходимо, что безусловно может затронуть производительность системы и пропускную способность сети. В частности, рабочий сервер может копировать и передавать данные файлов, которые не изменялись, а также целые файлы, которые изменялись только в малой части. Из-за этого серверу резервного копирования также может быть необходимо предоставить больше емкости запоминающего устройства, чем необходимый для резервного копирования данных рабочего сервера.

Поэтому понятно, что каждый из упомянутых выше факторов (или их совокупность) может негативно затронуть директивную точку восстановления (RPO), которая обычно указывает, насколько давние данные должны быть восстановлены, чтобы организация возобновила свою деятельность после аварии. Упомянутые выше факторы также могут негативно затронуть директивные сроки восстановления (RTO), которые обычно указывают на то, сколько времени пройдет после аварии, прежде чем смогут быть восстановлены данные, необходимые для возобновления деятельности. Таким образом, традиционные системы резервного копирования обычно плохо оснащены для обеспечения относительно высоких значений точек восстановления, особенно при относительно быстром времени, без чрезмерной нагрузки на системные ресурсы.

Поэтому существующие системы резервного копирования сталкиваются со многими трудностями, на которые можно обратить внимание.

Сущность изобретения

Реализации настоящего изобретения решают одну или более проблем в области техники с помощью систем, способов и компьютерных продуктов, выполненных по меньшей мере частично с возможностью директивные точки восстановления и директивные сроки восстановления в системах резервного копирования. Например, по меньшей мере в одной реализации экономия ресурсов на рабочем сервере может быть достигнута посредством отслеживания изменений томов рабочего сервера с помощью драйвера фильтра тома. Кроме того, пропускная способность сети и ресурсы сервера резервного копирования могут использоваться эффективно посредством передачи прежде всего только дифференциальных изменений (например, байтов или диапазонов байтов изменений) на сервер резервного копирования, начиная с последнего цикла репликации. Как будет лучше понятно далее, такая оптимизация может предоставить возможность выполнять резервное копирование данных рабочего сервера практически непрерывно (или почти непрерывно) без существенных расходов ресурсов рабочего сервера, ресурсов сервера резервного копирования и/или проблем с пропускной способностью сети.

Например, со стороны рабочего сервера способ репликации данных рабочего сервер практически непрерывным и целостным образом может включать в себя отправку копии данных тома с одного или более томов рабочего сервер на сервер резервного копирования. В таком случае отправленная копия данных для тома (томов) обычно будет являться целостной (то есть целостной для приложений или целостной для файловой системы) на первый момент времени. Кроме того, способ может включать в себя идентификацию одного или более изменений данных тома через один или более файлов журнала тома. Способ может дополнительно включать в себя после идентификации события цикла репликации сохранение одного или более изменений данных в одном или более файлах журнала тома. Обычно одно или более изменений данных также будут являться целостными на второй (то есть последующий) момент времени. Кроме того, способ может включать в себя отправку на сервер резервного копирования копии одного или более изменений. Таким образом, сервер резервного копирования будет иметь копию данных одного или более томов, где данные являются действительными на первый момент времени и на второй момент времени.

В отличие от этого со стороны сервера резервного копирования способ репликации данных рабочего сервера практически непрерывным и целостным образом может включать в себя прием одной или более резервных копий тома от рабочего сервера. В таком случае одна или более резервных копий тома являются целостными на начальный момент времени. Способ также может включать в себя прием одного или более целостных для приложений обновлений резервных копий, по меньшей мере одно из которых является целостным обновлением по меньшей мере одной из одной или более резервных копий тома на последующий момент времени. Кроме того, способ может включать в себя прием запроса восстановления данных, которые являются действительными в соответствии с последующим моментом времени.

Кроме того, способ также может включать в себя идентификацию запрашиваемых данных для последующего момента времени на одном или более томах сервера резервного копирования. В таком случае запрашиваемые данные включают в себя по меньшей мере часть по меньшей мере одного целостного для приложений обновления резервной копии. Кроме того, способ может включать в себя отправку запрашиваемых данных, которые являются действительными на последующий момент времени, на рабочий сервер.

Это описание сущности изобретения дано для того, чтобы в упрощенной форме предоставить выбор концепций, которые далее описаны в подробном описании. Это описание сущности изобретения не предназначено для выявления ключевых признаков или основных признаков заявленного предмета, а также не предназначено для использования в качестве помощи в определении объема заявленного предмета.

Дополнительные признаки и преимущества иллюстративных реализаций изобретения будут изложены в последующем описании и отчасти будут очевидны из описания или могут быть изучены посредством применения на практике таких иллюстративных реализаций. Признаки и преимущества таких реализаций могут быть поняты и получены посредством инструментов и комбинаций, на которые особенно указано в приложенной формуле изобретения. Эти и другие признаки станут более понятными из следующего описания и приложенной формулы изобретения или могут быть изучены посредством применения на практике таких иллюстративных реализаций, изложенных далее.

Краткое описание чертежей

Чтобы описать способ, которым могут быть получены упомянутые выше и другие преимущества и признаки изобретения, более подробное описание изобретения, кратко изложенного выше, будет выполнено со ссылкой на его конкретные варианты воплощения, которые проиллюстрированы на приложенных чертежах. При понимании, что эти чертежи изображают только типичные варианты воплощения изобретения и поэтому не должны рассматриваться как ограничивающие его объем, изобретение будет описано и разъяснено с дополнительной спецификой и подробностями с помощью сопроводительных чертежей, на которых:

Фиг.1A иллюстрирует архитектурную обзорную диаграмму в соответствии с реализацией настоящего изобретения, в которой рабочий сервер создает дифференциальные целостные для приложений (или для файловой системы) резервные копии и отправляет эти резервные копии на сервер резервного копирования;

Фиг.1B иллюстрирует обзорную диаграмму в соответствии с реализацией настоящего изобретения, в которой драйвер фильтра тома отслеживает изменения тома с использованием системной памяти и одного или более физических дисков; и

Фиг.2 иллюстрирует блок-схемы последовательности операций способов, содержащие последовательность действий, выполняемых на стороне рабочего сервера и сервера резервного копирования в соответствии с реализациями настоящего изобретения.

Подробное описание

Настоящее изобретение распространяется на системы, способы и программные продукты, выполненные с возможностью по меньшей мере частично оптимизировать директивные точки восстановления и директивные сроки восстановления в системах резервного копирования. Например, по меньшей мере в одной реализации экономия ресурсов на рабочем сервере может быть достигнута посредством отслеживания изменений томов рабочего с помощью драйвера фильтра тома. Кроме того, пропускная способность сети и ресурсы сервера резервного копирования могут использоваться эффективно посредством передачи прежде всего только дифференциальных изменений (например, байтов или диапазонов байтов изменений) серверу резервного копирования со времени последнего цикла репликации. Как будет лучше понятно далее, такая оптимизация может предоставить возможность резервировать данные рабочего сервера фактически непрерывно (или почти непрерывно) без существенных расходов ресурсов рабочего сервера, ресурсов сервера резервного копирования и/или проблем с пропускной способностью сети.

Как будет лучше понятно из следующего описания и формулы изобретения, реализации настоящего изобретения могут удовлетворить широкому диапазону "директивных сроков восстановления" посредством обновления информации сервера резервного копирования с помощью "полной копии" данных рабочего сервера. Кроме того, реализации настоящего изобретения включают в себя драйвер фильтра тома, который может быть реализован на рабочем сервере. Как будет лучше понятно далее, драйвер фильтра тома может быть выполнен с возможностью отслеживать изменения байтов (и или блоков байтов) на томе (томах) рабочего сервера. Тогда рабочий сервер может быть выполнен с возможностью отправлять полную копию (или резервную копию) посредством отправки только этих измененных байтов (или блоков байтов) на сервер резервного копирования. Также использование драйвера фильтра тома может ослабить затраты ресурсов, которые в ином случае могли бы быть использованы при перемещении полной копии данных рабочего сервера на сервер резервного копирования.

Кроме того, в качестве результата этих и других признаков рабочий сервер может предоставлять серверу резервного копирования фактически непрерывные резервные копии нескольких "целостных" (то есть целостных для приложений и/или целостных для файловой системы) копий (то есть начальную резервную копию и последующие теневые копии), которые расположены близко друг к другу во времени. Кроме того, так как каждое обновление резервной копии является целостным для приложений (и/или целостным для файловой системы) или действительным на конкретный момент времени, различие между каждым обновлением также будет являться целостным для приложений. Также реализации настоящего изобретения предоставляют пользователю возможность восстанавливать широкий диапазон целостных для приложений данных (например, от уровня файла, уровня базы данных и даже уровня всего рабочего сервера) с довольно высокой степенью детализации (например, только несколько минут назад) с намного меньшими затратами, чем могло бы быть необходимо в ином случае.

Обычно имеется множество способов в соответствии с реализациями настоящего изобретения для того, чтобы реализовать службы непрерывного, целостного резервного копирования. По меньшей мере в одном очень общем смысле создание целостной резервной копий включает в себя создание базовой копии (например, 145) одного или более томов (например, 175) и затем дополнение этой базовой копии с помощью дифференциальных целостных обновлений (например, 150, 155) для одного или более томов. Например, фиг.1A показывает, что рабочий сервер 105 создает по меньшей мере одну базовую резервную копию (например, 145) данных на выбранном томе (томах) 175. В дополнение к простому созданию базовой копии 145 администратор резервного копирования в системе 100 может использовать любое количество или любые типы механизмов, чтобы сделать копию 145 целостной.

В одной реализации администратор резервного копирования может использовать агент реплики (не показан), установленный на сервере 110 резервного копирования и/или на рабочем сервере 105, чтобы управлять процессами репликации. Во время цикла репликации, например, агент реплики может быть выполнен с возможностью давать команду любой одной или более соответствующим приложениям записи на рабочем сервере 105 немедленно остановить действия записи на любой один или более томов (например, база данных может охватывать несколько томов, и несколько приложений могут использовать один и тот же том с различными расписаниями репликации) на один момент времени. (Для резервной копии общего каталога приложение записи даже может вообще не быть задействовано.) Это позволяет агенту реплики тем самым создать единую резервную копию на момент времени (то есть "теневую копию") одного или более томов.

Агент реплики также может дать команды каждому приложению записи выполнить некоторые функции над своими интересующими данными, чтобы тем самым гарантировать, что все данные и метаданные являются целостными на момент времени цикла репликации. Для более простых приложений, которые могут не иметь приложений записи или соответствующего подключаемого расширения, связанного с ней, агент реплики может быть выполнен с возможностью просто дать этим приложениям команду приостановиться или закрыться во время цикла репликации. Упомянутые выше агенты, компоненты и функции для создания целостных резервных копий могут быть предоставлены по меньшей мере в одной реализации в среде корпорации MICROSOFT, например, с помощью службы теневого копирования тома ("VSS").

В любом случае, приостановив интересующие записи на конкретный том (или тома) и на конкретный момент времени, рабочий сервер 105 может затем сделать и отправить копию интересующего тома (томов) (или в качестве альтернативы только выбранных папок, файлов или типов файлов). Например, фиг.1A показывает, что рабочий сервер 105 может предоставить эту начальную базовую копию 145 серверу 110 резервного копирования. Обычно рабочий сервер 105 может предоставить базовую копию 145 любым из нескольких способов. В одной реализации, например, рабочий сервер 105 просто отправляет копию 145 по сетевому соединению. В других реализациях, в которых, например, пропускная способность сети может быть более ограничена, администратор резервного копирования может передать копию тома на ленту (или другой узел промежуточного хранения - не показан) и позже присоединить эту ленту к серверу 110 резервного копирования. Каким бы то ни было образом рабочий сервер 105 предоставляет серверу 110 резервного копирования по меньшей мере одну целостную базовую копию всех данных (то есть действительную на момент времени t₀) для интересующего тома, папки, файла или набора файлов, которые совместно используют один и тот же цикл репликации.

После предоставления одной или более базовых копий одного или более томов рабочего сервера (серверов) сервер 110 резервного копирования может продолжить принимать обновления базовой резервной копии (копий). Например, сервер 110 резервного копирования может продолжить выполнять резервное копирование рабочего сервера 105 на основе широкого спектра конфигурируемых расписаний репликации, например, в диапазонах приблизительно 5-10 минут, 10-15 минут, 15-30 минут и т.п. Обычно уровень, на который администратор резервного копирования настраивает циклы репликации, будет являться уровнем степени детализации, до которого можно получить конкретную "точку восстановления".

Как обсуждается ранее, обычно относительно высокий уровень степени детализации при доступности резервных копий на момент времени может являться чрезмерно дорогим ресурсом для некоторых систем резервного копирования. Таким образом, чтобы создать упомянутый выше уровень степени детализации "точек восстановления", не ставя с неизбежностью под угрозу "время, потраченное на восстановление" (например, не неся существенных накладных расходов), реализации настоящего изобретения могут предоставить несколько важных компонентов и функций.

В одной реализации, обсуждаемой более полно в дальнейшем, например, драйвер 115 фильтра тома может использоваться для отслеживания дифференциальных изменений одного или более томов (например, 175) на рабочем сервере 105 либо с помощью битовых массивов памяти, либо посредством маркировки конкретных измененных байтов (или блоков байтов) в журнале тома на диске. Обычно драйвер фильтра тома (например, 115) будет независим от того, каким образом реализованы аппаратные или программные "копии" на рабочем сервере 105. Однако будет понятно, что драйвер 115 фильтра тома не обязательно требуется, и аналогичные функции могут быть выполнены другими компонентами, что также обсуждается здесь. В дополнительных или альтернативных реализациях рабочий сервер 105 также может отслеживать изменения тома (например, изменения файлов 120, 125, 130 и т.д.) с помощью традиционного механизма отслеживания теневых копий и/или журналов номеров последовательного обновления (то есть "журналов 140 USN") и т.п. В отношении операционной среды корпорации MICROSOFT, например, такие компоненты обеспечиваются через объединенное использование службы теневого копирования тома ("VSS") и журнала USN.

Обычно файл (например, 135) журнала тома может содержать все изменения тома во время заданного цикла репликации (например, смещение в томе, длину изменения данных) для каждой записи на том и/или битовые карты в памяти для изменений. Когда происходит заданный цикл репликации, существующий файл (например, 135) журнала тома фиксируется, и может быть создан новый файл журнала тома (не показан) для сбора изменений для следующего цикла репликации. В одной реализации изменения на уровне тома могут быть отправлены непосредственно на сервер 110 резервного копирования без какой-либо дополнительной коррелирующей информации. Соответствующие обновления, отправленные на сервер 110 резервного копирования, могут затем быть применены к реплике как "байт n" (или "блок байтов n, измененный на n+1"). В дополнительных или альтернативных реализациях данные тома на рабочем сервере 105 также могут быть сопоставлены с информацией журнала 140 USN (или относящегося к нему компонента).

В частности, журнал USN (например, 140) содержит информацию с временными метками о таких действиях относительно данных имени файла в файловой системе. Компоненты, аналогичные или идентичные журналу 140 USN, также называются фильтрами изменений или журналами изменений и т.п. Таким образом, конкретная ссылка на "журнал 140 USN" делается здесь прежде всего для удобства. В любом случае в отношении действий файловой системы рабочий сервер 105 может объединить данные файла журнала тома (например, 135) и данные журнала изменений (например, журнала 140 USN) для корреляции времени, типа действий, имени файла и т.д. для различных записей на том 175.

По этому принципу журнал 140 USN также может использоваться вместе с файлом 135 журнала тома для корреляции, например, адреса изменения конкретного байта или "блока байтов" (а также соответствующих файлов для изменения). В частности, каждый файл на томе может рассматриваться как открытый набор адресуемых байтов, а также открытый набор адресуемых блоков байтов фиксированной длины. В некоторых случаях отслеживание и передача блоков байтов (а не индивидуальных байтов) может являться более эффективным способом отслеживания и передачи изменений, а также определения, сколько пространства может быть необходимо для целей резервного копирования. В частности, потому, что блоки байтов представляют уровень степени детализации, который обычно является несколько меньше уровня всего файла, но больше уровня одного байта. Также фиг.1A показывает, что рабочий сервер 105 протоколирует различные изменения байтов или блоков байтов в своих файлах, которые должны быть защищены.

Например, фиг.1A показывает, что рабочий сервер 105 протоколирует изменения байтов (или "блоков байтов") 121, 122 и 123 из файла 120 (например, файл 120 является новым файлом) со времени последнего цикла репликации (например, последние 5, 10, 15, 20, 25 или 30 минут и т.д.). Аналогично, хотя файл 125 содержит байты (или блоки байтов) 127, 128 и 129, изменились только байты 128 и 129; и где файл 130 содержит байты 131, 132 и 133, изменился только байт 133 со времени последнего цикла репликации. Обычно рабочий сервер 105 может протоколировать эти измененные байты в доступной только для чтения теневой копии тома, папки или соответствующих файлов. Как упоминалось ранее, рабочий сервер 105 также может сохранить эти измененные байты в файле журнала тома как битовые карты в памяти (например, с использованием бита на каждый блок данных на томе), которые позже передаются на физический диск во время репликации. Каким бы образом ни были протоколированы и отслежены изменения, в подходящее время (то есть при следующем цикле репликации) рабочий сервер 105 может затем подготовить для отправки на сервер 110 резервного копирования только эти изменения файлов (то есть 121, 122, 123, 128, 129, 133 и т.д.).

В этом конкретном примере каждое из изменений (то есть 121, 122, 123, 128, 129, 133 и т.д.) является действительным на самый последний момент времени (то есть t₁), и поэтому целостным (то есть целостным для приложений или целостным для файловой системы). В особенности, поскольку эти байты (или блоки байтов) представляют различие между двумя целостными резервными копиями на момент времени, применение этих байтов (или блоков байтов) в сервере 110 резервного копирования также может являться целостным. После идентификации этих изменений данных рабочий сервер 105 может отправить эти изменения как обновления 150 (для времени t₁) на сервер 110 резервного копирования. Аналогично рабочий сервер 105 может идентифицировать и отправить каждый следующий набор дифференциальных изменений данных (то есть изменения данных, протоколированные для одного или более томов) в следующем дифференциальном обновлении для следующего цикла репликации. Например, фиг.1A также показывает, что рабочий сервер 105 готовит и отправляет обновление 155 (для времени t₂) на сервер 110 резервного копирования и т.д.

Будет понятно, что с момента, в который рабочий сервер 105 читает измененные данные и готовит сообщение 150, могут произойти дополнительные изменения данных тома, которые иным образом могут сделать читаемые данные нецелостными (то есть целостными на момент времени t₁ и действительными в последующее время). Однако, как рассмотрено ранее в отношении базовой копии 145, служба теневого копирования тома (или другой механизм, подобный механизму VSS) может использоваться по меньшей мере в одной реализации для чтения данных только для фиксированного, конкретного момента времени и не каких-либо последовавших за ним изменений. Это может помочь гарантировать, что обновления 150 копии (а также 155 и т.д.) являются целостными вплоть до указанного момента времени, в который были начаты операции копии (также называемой обновлением резервной копии или обновлением).

После приема сервер 110 резервного копирования может сохранить каждую резервную копию и соответствующее обновление (обновления) для конкретного тома реплики. В одной реализации сервер 110 резервного копирования сохраняет резервные копии и обновления в том же самом месте тома того же самого носителя данных. В других реализациях сервер 110 резервного копирования (и/или дополнительные серверы резервного копирования или узлы хранения) может сохранить резервные копии и соответствующие обновления на отдельных томах и даже на отдельных носителях данных, как задано администратором резервного копирования.

В некоторых случаях вследствие характера фактически непрерывных итерационных резервных копий рабочего сервера 105 администратору резервного копирования может потребоваться синхронизировать несколько аспектов данных с рабочим сервером 105 данных. Например, могут быть случаи сбоя во время цикла репликации и/или по прошествии нескольких циклов репликации, которые могут произойти вследствие выхода из строя сети, переполнений журналов (например, выхода за пределы журнала USN и т.д.). Поэтому в одной реализации администратор резервного копирования может выполнить проверку правильности или исправление посредством создания новой базовой полной копии (например, аналогичной 145) рабочего сервера 105. Администратор резервного копирования затем может выполнить (например, через рабочий сервер 105) сравнение контрольной суммы (или другую проверку правильности) между копией данных на рабочем сервере 105 и данными на сервере 110 резервного копирования. Тогда в случае необходимости любые ошибочные данные на сервере 110 резервного копирования 110 могут быть исправлены.

Конкретно в отношении операционных компонентов системы WINDOWS, например, эта проверка контрольной суммы может быть выполнена по меньшей мере в одной реализации с использованием удаленного разностного сжатия (RDC), используемого в системе WINDOWS SERVER 2003. В некоторых случаях использование механизма, подобного механизму RDC, может являться предпочтительным в среде глобальной сети (WAN). В другой реализации, которая может являться предпочтительной в локальной сети (LAN), администратор резервного копирования может разделить каждый файл в копии на наборы "фрагментов" (например, блоки байтов) и затем вычислить контрольные суммы для каждого фрагмента.

В любом случае отчасти благодаря уровню степени детализации репликации, обеспечиваемому реализациями настоящего изобретения, если пользователь запрашивает конкретную версию файла (или другого представления данных), с момента которой прошло лишь несколько минут (например, необходимую из-за недавнего аварийного отказа персонального компьютера), пользователь может запросить у сервера 110 резервного копирования эту конкретную версию файла. Например, пользователь может запросить конкретную копию файла 120, которая являлась действительной 5 минут назад (например, на момент t₀ или перед обновлениями 121, 122, 123). Аналогично администратор может запросить (не показано) полное воспроизведение тома или томов 175.

После приема запроса в зависимости от характера запроса сервер 110 резервного копирования затем может найти запрашиваемые данные в установленном порядке. Например, в отношении основных данных файловой системы каждое обновление тома 175 может содержать полную копию запрашиваемых данных. Таким образом, серверу 110 резервного копирования может только потребоваться идентифицировать запрашиваемое пользователем время, идентифицировать данные в пределах соответствующего обновления для этого времени и затем выдать копию этих данных пользователю (например, сообщение 160 восстановления).

В других случаях, например, для почты или других типов данных приложений для работы с базами данных, каждое дифференциальное обновление (например, 150, 155), принятое сервером 110 резервного копирования, может содержать только дифференциальное обновление для запрашиваемых данных. Таким образом, сервер 110 резервного копирования может быть выполнен с возможностью воспроизводить каждое дифференциальное обновление от запрашиваемой точки восстановления обратно до последней полной базовой копии. Сервер 110 резервного копирования может затем объединить запрашиваемые данные, идентифицированные во время воспроизведения (например, 145, 150, 155 или t_0-n), пока не будет достигнуто время, указанное в запросе. Когда все соответствующие данные из первоначальной резервной копии и соответствующих обновлений объединены и готовы, тогда сервер 110 резервного копирования может отправить ответ восстановления (например, 160), который является действительным на запрашиваемое время. Например, фиг.1A показывает, что сервер 110 резервного копирования отправляет ответ 160, который указывает, что восстановленные данные являются действительными на время t₁.

Таким образом, в предшествующей реализации серверу 110 резервного копирования 110 может потребоваться поддержка приложения для воспроизведения дифференциальных обновлений. В другой реализации базовая полная копия и любые соответствующие дифференциальные обновления между базовой полной копией и запрашиваемым моментом времени могут быть просто скопированы обратно на рабочий сервер 105. Соответствующее приложение записи (например, приложение записи в пределах структуры службы теневого копирования томов) на рабочем сервере 105 тогда может воспроизвести журналы на полной резервной копии.

Обычно время, которое проходит между запросом конкретных данных и соответствующим ответом, может зависеть по меньшей мере от двух частей:

1. Времени для передачи данных от сервера 110 резервного копирования на рабочий сервер 105 и

2. Времени для завершения восстановления сервером 110 резервного копирования (например, через соответствующий агент резервного копирования).

Безусловно время для передачи данных от цели до источника обычно зависит от доступной пропускной способности сети, а также дисковых скоростей и использования ресурсов на сервере 110 резервного копирования и рабочем сервере 105. В отличие от этого время для создания конкретного восстановления обычно зависит от времени, требуемого для восстановления полной копии данных рабочего сервера из заданной базовой копии, и времени, требуемого для идентификации и воспроизведения обновлений (например, t_n-1), накопленных от базовой копии, чтобы восстановить заданный момент времени. Поэтому будет понятно, что время восстановления может быть значительно улучшено посредством ограничения количества обновлений, которые сервер 110 резервного копирования (или рабочий сервер 105) должен воспроизвести для любого заданного запроса восстановления, например, посредством создания периодических базовых полных копий (например, 145).

Как упомянуто ранее, один способ ограничения количества дифференциальных обновлений, которые могут потребоваться воспроизводить серверу 110 резервного копирования, может включать в себя периодическое создание новой "полной" базовой копии. Поскольку создание и отправка новой полной копии на сервер 110 резервного копирования в некоторых случаях может требовать много ресурсов (например, пропускную способность сети, ресурсы рабочего сервера 105 и необходимое количество дискового пространства сервера 110 резервного копирования), реализации настоящего изобретения также предусматривают создание "интеллектуальных полных копий". Эти интеллектуальные полные копии фактически представляют собой установление границ базовых копий для предопределенного момента времени. Например, через каждый предопределенный период, например каждые две недели, сервер 110 резервного копирования может сводить двухнедельные дифференциальные обновления (например, 150, 155 и т.д.) вместе с последней базовой копией данных (например, 145 или более новой), и тем самым создавать по существу новую копию данных рабочего сервера 105 на момент t₀.

Чтобы эффективно свести каждое из этих дифференциальных обновлений вместе, сервер 110 резервного копирования может быть выполнен с возможностью отслеживать все записи на тома рабочего сервера 105 с момента последней полной копии. По меньшей мере в одной реализации, например, сервер 110 резервного копирования реализует драйвер 115 фильтра тома на рабочем сервере 105 для отслеживания изменений тома (то есть одного или более томов) и сохраняет эти записи в памяти 170 рабочего сервера 105 во время каждого цикла репликации. Например, фиг.1A (см. также фиг.1B) показывает, что драйвер 115 фильтра тома служит интерфейсом между томом 175 и памятью 170 на рабочем сервере 105. Как будет более понятно на фиг.1B, каждый раз, когда в данные тома вносится изменение, драйвер 115 фильтра тома может записывать это изменение (или набор изменений) в файл 135 журнала тома. По меньшей мере в одной реализации эти изменения записываются в системную память 170 как битовая карта в памяти (например, 117a) для каждого из одного или более томов. Когда рабочий сервер 105 готов к конкретному циклу репликации, драйвер 115 фильтра тома может передать все битовые карты памяти на том 175, и рабочий сервер 105 может затем отправить соответствующие данные на сервер 110 резервного копирования.

Например, фиг.1B показывает, что память 170 использована для сбора данных копий, соответствующих различным битовым картам в памяти. В частности, фиг.1B показывает, что драйвер 115 фильтра тома идентифицирует некоторые изменения файла (то есть изменения файла 121, 122, 123 и т.д.) и затем сохраняет эти изменения как соответствующие битовые карты 193, 195 и т.д. в памяти в месте 190a памяти. В этом конкретном примере драйвер 115 фильтра тома сохраняет все изменения на соответствующем одном или более томах, начиная с последнего цикла репликации (то есть копию 185a на момент t₂), и, таким образом, каждая битовая карта 193, 195 и т.д. является действительной на самый последний момент времени в соответствующей копии (то есть 190a, копия на момент t₃).

Когда инициируется цикл репликации, например, благодаря командам, принятым от агента реплики, драйвер 115 фильтра тома передает все битовые карты для копии 190a (то есть битовые карты 193, 195 и т.д.) в соответствующее место 190b тома 175. Например, фиг.1B показывает, что части 180a и 185a памяти для копии были освобождены, поскольку цикл репликации, для которого они были формированы, уже прошел. Кроме того, соответствующие места 180b, 185b и т.д. тома 175 теперь содержат "все битовые карты" 183, 187, которые были ранее сохранены в частях 180a, 185a памяти, соответственно. В конечном счете, когда копия, соответствующая набору битовых карт, удаляется, битовые карты (например, 183, 187) могут остаться на томе (например, 175).

Эти битовые карты памяти (например, 193, 195) могут быть созданы и реализованы многими различными способами. Например, в одной реализации сервер 110 резервного копирования берет теневую копию (например, копию 150) тома рабочего сервера 105, сообщение управления вводом-выводом ("IOCTL") может быть отправлено поставщику теневого копирования (программному или аппаратному). Это сообщение IOCTL может быть перехвачено драйвером 115 фильтра тома для разбиения активной битовой карты. В ответ во время создания теневой копии драйвер 115 фильтра тома синхронизирует разбиение посредством создания зафиксированного набора битовых карт (например, 180a/189b, 185a/185b) и нового активного набора битовых карт (например, 190a/190b). В другой альтернативной реализации объект, который способен собирать область разности теневых копий (например, область разности механизма VSS), может знать об изменениях на уровне тома и также знать о USN и файловой системе. Также этот объект может обеспечивать абстракцию, которая дает набор измененных файлов и набор изменений в файлах. Соответствующее приложение репликации или резервного копирования тогда может использовать эту инфраструктуру для достижения репликации.

Когда инициируется цикл репликации, драйвер 115 фильтра тома передает зафиксированные битовые карты на диск, чтобы уменьшить использование памяти 170. Драйвер 115 фильтра тома может также обеспечить один или более интерфейсов IOCTL, к которым можно делать запрос обо всех изменениях, которые произошли, начиная с новой копии (например, на момент t_n-1). В одной реализации запрос этих интерфейсов IOCTL возвращает все битовые карты, которые были накоплены, начиная с новой копии. Будет понятно, что описанное здесь использование битовых массивов в памяти для отслеживания изменений может являться очень эффективным по меньшей мере частично по той причине, что битовые карты в памяти не имеют тенденции существенно воздействовать на ресурсы рабочего сервера 105.

В альтернативной реализации для идентификации каждого из этих отслеживаемых изменений сервер 110 резервного копирования также может идентифицировать набор файлов, которые изменяются, например, с использованием журнала 140 USN (или с использованием других метаданных отслеживаемых файлов). Сервер 110 резервного копирования (или соответствующий компонент) может затем запросить у файловой системы рабочего сервера 105 зоны памяти для файлов, которые занимает каждый измененный файл. Пересечение между зонами памяти для файлов, запрашиваемых у файловой системы, и зонами памяти для файлов, о которых сообщает драйвер 115 фильтра тома, может предоставлять собой зону памяти для файла, который изменился с последнего цикла репликации, и тем самым позволяет некоторым файлам (например, файлам базы данных) быть исключенным из некоторых процессов репликации. Сервер 110 резервного копирования (или соответствующий компонент) может затем повторить этот процесс для каждого измененного файла (либо в соответствии с отчетом журнала USN, либо в соответствии с аналогично формируемым документом метаданных).

Конкретно в отношении использования журнала USN для отслеживания изменений на рабочем сервере 105 будет понятно, что идентификационный номер файла ("FRN") на рабочем сервере 105 может не соответствовать номеру FRN для того же самого файла, хранящегося на сервере 110 резервного копирования. Таким образом, чтобы отправить отслеживаемые изменения с рабочего сервера 105 на сервер 110 резервного копирования, может быть важно в некоторых случаях вычислить правильный соответствующий путь к конкретному измененному файлу. Например, тома могут иметь следующие изменения, которые включают в себя изменение пути на рабочем сервере 105 для файла y.txt:

1) Изменить C:\a\b\c\y.txt

2) Переименовать C:\a\b в C:\p\q\r

3) Изменить C:\p\q\r\b\c\y.txt

4) Удалить C:\a

В только что проиллюстрированном примере первоначальный путь "a\b" на рабочем сервере 105 переименован как путь "p\q\r", и каталог "\a" первоначального пути удален. В результате этого путь на рабочем сервере 105 для файла y.txt становится "C:\p\q\p\r\b\c\y.txt". Однако эти изменения пути для файла y.txt на рабочем сервере 105 могут автоматически не привести к изменениям пути на сервере 110 резервного копирования. В частности, путь к файлу y.txt на сервере 110 резервного копирования обычно останется "a\b\c\y.txt".

Во время копии рабочий сервер 105 также может записать в журнал USN следующие изменения, показанные ниже как иллюстративные записи 1-5:

1) {rsn=modify, FRN=yFRN, parentFRN=cFRN, filename=y.txt}

2) {rsn=rename-old, FRN=bFRN, parentFRN=aFRN, filename=b}

3) {rsn=rename-new, FRN=bFRN, parentFRN=rFRN, filename=b}

4) {rsn=modify, FRN=yFRN, parentFRN=cFRN, filename=y.txt}

5) {rsn=delete, FRN=aFRN, parentFRN=root, filename=a}

В дополнение из предшествующего примера состояние соответствующего тома рабочего сервера 105 во время репликации показано как "C:\p\q\r\b\c\y.txt".

Чтобы отправить изменения для записи 1 на сервер 110 резервного копирования в этом конкретном примере, рабочему серверу 105 требуется извлечь путь файла y.txt из сервера 110 резервного копирования. В частности, вследствие описанного выше изменения пути путь для файла y.txt на рабочем сервере 105 в копии для c-FRN представляет собой C:\p\q\r\b\c\y.txt, что отличается от его пути на сервере 110 резервного копирования (то есть C:\a\b\c\y.txt). Реализации настоящего изобретения могут решить эту проблему по меньшей мере с помощью двух альтернативных подходов. В одной реализации, например, журнал USN может просто извлечь и сохранить метаданные пути из сервера 110 резервного копирования в реляционной базе данных и тем самым постоянно коррелировать пути к файлу на рабочем сервере 105 и сервере 110 резервного копирования.

В альтернативной реализации рабочий сервер 105 может сканировать журнал USN дважды. При первом проходе рабочий сервер 105 может коррелировать эту информацию через итерационные просмотры (или "прохождения") журнала 140 USN. Например, при одном просмотре рабочий сервер 105 кэширует переименование каждой папки. На втором проходе рабочий сервер 105 может вычислить соответствующий путь на сервере 110 резервного копирования на основе кэшированных переименований и текущих путей. Например, в конце первого прохода рабочий сервер 105 может кэшировать следующую информацию об удаленных и/или переименованных каталогах:

{FRN = bFRN, replica_parent = aFRN, replica_name = b}

{FRN = aFRN, replica_parent = root, replica_name = a}

Для вычисления пути к файлу y.txt рабочий сервер 105 сначала идентифицирует, что родительским номером FRN (то есть "идентифицирующим номером файла") для файла y.txt в записи "1" является номер cFRN. На следующем этапе рабочий сервер 105 вычисляет имя файла для номера cFRN, а также имя файла для родительского номера FRN. Затем рабочий сервер 105 просматривает кэш, прежде чем сделать запрос к файловой системе. Поскольку в этом примере кэш не имеет никаких записей имен файла для родительского номера cFRN, рабочий сервер 105 делает запрос к файловой системе и определяет, что имя файла представляет собой "c" и что родителем является номер bFRN.

Затем рабочий сервер 105 вычисляет имя файла для номера bFRN, а также имя соответствующего родительского файла для номера bFRN. Как и раньше, рабочий сервер 105 сначала просматривает кэш, прежде чем сделать запрос к файловой системе. Так как в этом примере в кэше имеется запись для номера bFRN, рабочий сервер 105 определяет, что имя файла представляет собой "b" и что родителем является номер aFRN. Затем рабочий сервер вычисляет имя файла для номера aFRN и имя родительского файла для номера aFRN. Снова рабочий сервер 105 сначала просматривает кэш, прежде чем сделать запрос к файловой системе, и поскольку в этом примере кэш имеет запись для номера aFRN, рабочий сервер 105 определяет, что имя файла для номера FRN представляет собой "a" и родительский номер FRN представляет собой "root".

В итоге рабочий сервер 105 вычисляет окончательный путь как "c:\a\b\c\y.txt". Затем, когда запись 3 (rename-new) обрабатывается при втором проходе, кэш обновляется для нового имени родительского файла следующим образом.

{FRN = bFRN, replica_parent = rFRN, replica_name = b}

{FRN = aFRN, replica_parent = root, replica_name = a}

Когда рабочий сервер 105 обрабатывает запись 4 даже при том, что запись является идентичной записи 1, путь, вычисленный для файла y.txt, теперь представляет собой "C:\p\q\r\b\c\y.txt". Вычисленный путь является разным в данном случае, так как родительский номер bFRN в кэше теперь является номером rFRN. В соответствии с этим предшествующий текст иллюстрирует, как алгоритм с двумя проходами может помочь оптимизировать объем данных, который рабочий сервер 105 передает серверу 110 резервного копирования. В частности, предшествующий текст описывает несколько способов, которыми рабочий сервер 105 может идентифицировать во время второго прохода любые созданные файлы, а также любые файлы, которые изменяются и затем удаляются, и тем самым должным образом коррелировать пути к файлам с сервером 110 резервного копирования.

В соответствии с этим фиг.1A-1B и соответствующий текст представляют несколько систем, компонентов и механизмов для эффективного резервного копирования данных рабочего сервера практически непрерывным образом. В дополнение к предшествующему реализации настоящего изобретения могут быть также описаны в терминах блок-схем последовательности операций способов, имеющих последовательность действий для выполнения конкретного результата. В частности, фиг.2 иллюстрирует блок-схемы последовательности операций со стороны рабочего сервера 105 и сервера 110 резервного копирования в соответствии с реализациями настоящего изобретения для резервного копирования и восстановления данных. Действия, проиллюстрированные на фиг.2, описываются ниже относительно компонентов и диаграмм, проиллюстрированных на фиг.1A-1B.

Предварительно следует отметить, что иногда здесь делается ссылка на "первое", "второе" или "третье" событие (или "момент") во временной последовательности. Однако следует понимать, что такие обозначения должны лишь отличать уникальные моменты на непрерывном отрезке, так что "первое" событие или момент является не только отличным от "второго" или "третьего" момента, но также происходит в некоторый момент перед "вторым" и/или "третьим" моментами. Например, создание и отправка базовой "полной" копии данных (например, 145) также может рассматриваться как второй или третий (или более поздний) момент относительно некоторого предшествующего события (не показано), даже при том, что оно первоначально описано как первый момент относительно обновления 150. Аналогично обновление 150 может быть описано, как происходящее в "первый" момент времени относительно обновления 155 (например, "второго" момента) и т.д., хотя эти термины первоначально описаны здесь как "второй" и "третий" моменты времени в проиллюстрированных примерах относительно базовой полной копии 145. Такой относительный смысл для последовательных событий также применяется здесь к использованию терминов "начальный" или "последующий".

Например, фиг.2 показывает, что со стороны рабочего сервера 105 способ репликации данных рабочего сервера практически непрерывным и целостным для приложений (то есть для файловой системы) образом, с тем чтобы последние данные могли быть легко восстановлены с сервера резервного копирования, содержит этап 200 отправки целостной копии данных тома на сервер резервного копирования. Этап 200 включает в себя отправку копии данных тома от рабочего сервера на сервер резервного копирования, причем данные являются целостными для первого момента времени. Например, рабочий сервер 105 (например, в ответ на команду агента реплики или другую команду от сервера 110 резервного копирования) создает резервную копию 145 всего тома, которая является целостной на конкретный момент времени (например, момент t₀). В одной реализации это включает в себя вызов всех приложений записи на рабочем сервере 105 для приостановки и начала приготовления к резервному копированию. Затем рабочий сервер 105 копирует все данные на томе (или в заданных файлах, папках или типах файлов и т.д.) и готовит эти данные для отправки на сервер 110 резервного копирования (и хранения на нем).

Аналогично фиг.2 показывает, что со стороны сервера 110 резервного копирования способ репликации данных рабочего сервера практически непрерывным и целостным образом, с тем чтобы последние данные могли быть легко восстановлены с сервера резервного копирования, содержит этап 240 приема целостной резервной копии тома от рабочего сервера. Этап 240 включает в себя прием одной или более резервных копий тома от рабочего сервера, причем одна или более резервных копий тома являются целостными (то есть целостными для приложений или для файловой системы) для начального момента времени. Например, фиг.1A показывает, что сервер 110 резервного копирования принимает и сохраняет полную резервную копию 145, которая принята по сети от рабочего сервера 105 или принята от устройства чтения ленты или от другого узла хранения, в некоторый момент подключенного к серверу 110 резервного копирования. В частности, администратор резервного копирования может взять аппаратную копию рабочего сервера 105 и затем присоединить копию к серверу 110 резервного копирования.

Кроме того, фиг.2 показывает, что со стороны рабочего сервера 105 способ содержит этап 210 идентификации одного или более изменений данных тома. Этап 210 включает в себя идентификацию одного или более изменений данных тома через один или более файлов журнала тома. Например, как показано на фиг.1A и 1B, драйвер 115 фильтра тома может отследить изменения в файлах 120, 125 и 130 и сохранить эти изменения в файле 135 журнала тома. В одной реализации это одно или более изменений альтернативно могут быть сохранены в памяти 170 как битовые карты в памяти, прежде чем они будут помещены в файл 135 журнала тома.

Фиг.2 также показывает, что со стороны рабочего сервера 105 способ содержит этап 220 сохранения на диск одного или более целостных обновлений. Этап 220 включает в себя сохранение одного или более изменений данных в одном или более файлах журнала тома после идентификации события цикла репликации, причем одно или более изменений данных являются целостными для второго момента времени. Например, после идентификации события инициализации цикла репликации (например, от агента реплики) драйвер фильтра тома передает битовые карты 193, 195 в месте 190a памяти в выделенное на физическом диске пространство 190b (например, также соответствующее файлу 135 журнала тома). Это место 190b на физическом диске, таким образом, содержит копию для одного момента времени, которая отличается от копии 187, хранящейся в месте 185b на диске (то есть "всех битовых массивов" 187).

Кроме того, фиг.2 показывает, что со стороны рабочего сервера 105 способ содержит этап 230 отправки копии целостных обновлений на сервер резервного копирования во время репликации. Этап 230 включает в себя отправку на сервер резервного копирования копии одного или более изменений данных, с тем чтобы сервер резервного копирования имел копию данных, которые являются действительными на первый момент времени и на второй момент времени. Например, в дополнение к передаче полного обновления 145 на сервер 110 резервного копирования рабочий сервер также отправляет целостные обновления 150 и 155 копий, каждое из которых является действительным на различные моменты времени (то есть на моменты t₁, t₂ и т.д.).

В соответствии с этим фиг.2 показывает, что со стороны сервера 110 резервного копирования способ содержит этап 250 приема одного или более целостных обновлений. Этап 250 включает в себя прием одного или более целостных обновлений резервной копии, по меньшей мере одно из которых является целостным обновлением по меньшей мере для одной из одной или более резервных копий тома для последующего момента времени. Например, сервер 110 резервного копирования принимает любое из целостных обновлений 150, 155 копии, с тем чтобы теперь сервер резервного копирования имел копии данных для различных задаваемых приращениями моментов времени (то есть моментов t₁, t₂ и т.д.) по сравнению с полной резервной копией 145 (на момент t₀ или некоторой другой базовой полной копией).

Кроме того, фиг.2 показывает, что со стороны сервера 110 резервного копирования способ содержит этап 260 приема запроса восстановления. Этап 260 включает в себя прием запроса восстановления данных, которые являются действительными в соответствии с последовательным моментом времени. Например, сервер 110 резервного копирования принимает запрос (не показан) конкретного файла, который является действительным на момент времени t₁, представляющего собой файл, находящийся и в базовой полной резервной копии 145, и в обновлении 150. Кроме того, фиг.2 показывает, что со стороны зрения сервера 110 резервного копирования способ содержит этап 270 идентификации запрашиваемых данных, действительных на последующий момент времени. Этап 270 включает в себя идентификацию запрашиваемых данных для последующего момента времени в одном или более томах сервера резервного копирования, причем запрашиваемые данные включают в себя по меньшей мере часть по меньшей мере одного целостного обновления резервной копии.

Например, в отношении данных из базы данных сервер 110 резервного копирования может свести вместе копии файла на каждый предшествующий и текущий момент времени, который является действительным для запроса; то есть сервер 110 резервного копирования 110 объединяет копии файла на момент t₀ и момент t₁. С другой стороны, с данными файловой системы каждое последующее обновление (например, 150, 155) может включать в себя полную обновленную копию запрашиваемого файла, и, таким образом, серверу 110 резервного копирования может потребоваться только идентифицировать запрашиваемые данные в самом последнем обновлении (или некотором другом последующем обновлении) на запрашиваемый момент времени. Таким образом, в зависимости от типа запрашиваемых данных серверу 110 резервного копирования может потребоваться идентифицировать каждое дифференциальное обновление, начиная с запрашиваемого момента и назад до последней базовой полной копии, или может потребоваться лишь идентифицировать запрашиваемые данные в обновлении на последний момент времени.

Фиг.2 также показывает, что со стороны сервера 110 резервного копирования способ содержит этап 280 возвращения запрашиваемых данных. Этап 280 включает в себя отправку запрашиваемых данных, которые являются действительными на последующий момент времени, на рабочий сервер. Например, для случая данных из базы данных сервер 110 резервного копирования предоставляет восстановление 160, которое включает в себя как данные базовой полной копии (например, 145), так и данные дифференциального обновления (например, 150, 155), в то время как для данных файловой системы сервер 110 резервного копирования предоставляет восстановление, которое имеет по меньшей мере файловые данные из обновления на запрашиваемый момента времени. Ответ 160 сервера 110 резервного копирования также может включать в себя указание на то, на какое время восстановления ответ является действительным. Как показано на фиг.1A, данные 160 восстановления показывают, что данные являются действительными на момент времени t₁.

Диаграммы, компоненты и способы в соответствии с реализациями настоящего изобретения предоставляют многие преимущества перед традиционными системами резервного копирования. В частности, реализации настоящего изобретения предоставляют способы резервного копирования данных, которые являются независимыми от источника данных (например, через драйвер 115 фильтра тома), не обязательно требуют версию приложения, работающего на сервере резервного копирования, и предоставляют практически непрерывную репликацию. Как описано ранее, эта оптимизация основана по меньшей мере частично на отслеживании изменений с низкими накладными затратами на уровне тома с использованием драйвер фильтра тома (например, 115), а также на выполнении циклов репликации на уровне файлов с использованием, например, журнала USN, с тем чтобы включения/исключения на уровне файлов по-прежнему могли применяться.

Кроме того, реализации настоящего изобретения предусматривают создание полных базовых копий данных рабочего сервера на сервере резервного копирования оптимизированным образом и без необходимости переноса всех данных через сеть. Уменьшение количества последовательных данных, которые передаются серверу резервного копирования, может обеспечить существенное сокращение потенциальных расходов ресурсов в сети и на рабочих серверах. Также реализации настоящего изобретения дополнительно предоставляют многие альтернативные способы удовлетворения строгим требованиям времени восстановления. Реализации настоящего изобретения также предоставляют многие способы отслеживания изменений данных (например, на уровне байтов или блоков байтов) с низкими накладными расходами и отслеживания изменений данных независимым от файловой системы и аппаратных/программных копий способом. Кроме того, реализации настоящего изобретения также предоставляют один или более способов воссоздания информации о пути (например, с помощью репликации на основе журнала USN) без необходимости запроса состояния на соответствующих рабочих серверах.

Варианты воплощения настоящего изобретения могут содержать специализированный или универсальный компьютер, включающий в себя различные аппаратные средства, как рассмотрено более подробно ниже. Варианты воплощения в рамках объема настоящего изобретения также включают в себя машиночитаемые носители для переноса или хранения на них исполняемых на компьютере команд или структур данных. Такие машиночитаемые носители могут являться любыми доступными носителями, к которым может получать доступ универсальный или специализированный компьютер.

В качестве примера, но без ограничения, такие машиночитаемые носители могут содержать оперативное запоминающее устройство (ОЗУ; RAM), постоянное запоминающее устройство (ПЗУ; ROM), электронно-стираемое программируемое постоянное запоминающее устройство (ЭСППЗУ; EEPROM), компакт-диск, предназначенный только для чтения (CD-ROM) или другое запоминающее устройство на оптических дисках, запоминающее устройство на магнитных дисках или другие магнитные запоминающие устройства, или любой другой носитель, который может использоваться для переноса или хранения желаемого средства программного кода в виде исполняемых на компьютере команд или структур данных, и к которому может получать доступ универсальный или специализированный компьютер. Когда информация передается или предоставляется по сети или другому соединению связи (либо проводному, либо беспроводному, либо комбинации проводного или беспроводного) на компьютер, компьютер должным образом рассматривает соединение как машиночитаемый носитель. Таким образом, любое такое соединение должным образом называется машиночитаемым носителем. Комбинации упомянутого выше также должны быть включены в объем машиночитаемых носителей.

Исполняемые на компьютере команды содержат, например, команды и данные, которые заставляют универсальный компьютер, специализированный компьютер или специализированное устройство обработки выполнять некоторую функцию или группу функций. Хотя предмет был описан на языке, специальном для структурных признаков и/или действий способов, следует понимать, что предмет, определенный в приложенной формуле изобретения, не обязательно ограничивается конкретными признаками или действиям, описанными выше. Конкретные признаки и действия, описанные выше, раскрыты в качестве иллюстративных форм реализации пунктов формулы изобретения.

Настоящее изобретение может быть воплощено в других конкретных формах без отступления от его сущности или существенных характеристик. Описанные варианты воплощения должны рассматриваться во всех отношениях лишь как иллюстративные и не ограничивающие. Таким образом, объем изобретения указан посредством приложенной формулы изобретения, а не посредством предшествующего описания. Все изменения, которые находятся в пределах значения и диапазона эквивалентности формулы изобретения, должны быть охвачены ее объемом.

Группа изобретений относится к средствам резервирования копий целостных приложений. Техническим результатом является защита от потерь данных. Данные могут быть защищены на рабочем сервере практически непрерывным образом без необходимости наложения серьезных ограничений на приложения - источники. Рабочий сервер может создать целостную для приложений резервную копию одного или более томов, резервные копии соответствуют первому моменту вовремя. Драйвер фильтра тома может отслеживать изменения данных с использованием битовых массивов памяти, в то время как файл журнала и/или журнал номеров последовательного обновления может отслеживать, какие файлы были изменены. Обновления тома также являются целостными для (более поздних) моментов времени. В следующем цикле репликации, например каждые несколько минут (каким-либо образом настраиваемый параметр), драйвер фильтра тома передает каждый битовый массив памяти на физический диск на рабочем сервере. Затем рабочий сервер отправляет обновления на сервер резервного копирования, который таким образом сохраняет целостные для приложений резервные копии для тома для нескольких моментов времени. 3 н. и 17 з.п. ф-лы, 3 ил.

1. Способ репликации данных рабочего сервера практически непрерывным и целостным образом с тем, чтобы недавние данные могли быть легко восстановлены, с сервера резервного копирования, осуществляемый на рабочем сервере (105) в компьютеризированной среде (100), в которой один или более рабочих серверов производят резервное копирование данных, которые должны быть защищены в одном или более томах (175), на одном или более серверах (110) резервного копирования, причем способ содержит этапы, на которых:
отправляют (200) копию данных для одного или более томов с рабочего сервера (105) на сервер (110) резервного копирования, причем данные являются целостными на первый момент времени (145);
идентифицируют (210) одно или более изменений (121, 122, 123) в данных для одного или более томов (175) в одном или более файлах (135) журнала тома;
после идентификации события цикла репликации сохраняют (220) одно или более изменений данных в одном или более файлах журнала тома, причем одно или более изменений данных являются целостными на второй момент времени (150); и
отправляют (230) серверу резервного копирования копию одного или более изменений данных для одного или более томов с тем, чтобы сервер резервного копирования имел копию данных для одного или более томов, которые являются действительны на первый момент времени (145) и на второй момент времени (150).

2. Способ по п.1, дополнительно содержащий этап, на котором сохраняют изменения данных на уровне файла для тома в одном из: фильтре изменений, журнале изменений или журнале (140) USN.

3. Способ по п.2, дополнительно содержащий этап, на котором коррелируют один или более файлов (135) журнала тома с одним из: с фильтром изменений, с журналом изменений, либо с журналом (140) USN для идентификации одного или более измененных файлов (120), которые соответствуют одному или более изменениям данных в каждом измененном файле.

4. Способ по п.1, дополнительно содержащий этап, на котором маркируют одно или более изменений данных (121, 122, 123) либо на уровне байтов, либо на уровне блоков байтов в одном или более файлах журнала тома.

5. Способ по п.1, дополнительно содержащий этап, на котором идентифицируют изменения данных для одного или более томов через один или более битовые карты (117а) в памяти, причем одна или более битовых карт в памяти соответствуют второму моменту времени (150).

6. Способ по п.5, дополнительно содержащий этап, на котором сохраняют одну или более битовых карт (187) в памяти в одном или более файлах журнала тома во время события цикла репликации, причем один или более файлов журнала тома сохраняют на диске (117b, 185b).

7. Способ по п.5, дополнительно содержащий этапы, на которых:
фиксируют одну или более битовых карт в памяти, соответствующих второму моменту времени; и
создают новый набор из одной или более битовых карт (193, 195) в памяти, соответствующий новым записям в один или более измененных файлов для третьего момента времени (155).

8. Способ по п.1, в котором драйвер (115) фильтра тома принимает одно или более изменений данных и применяет одно или более изменений данных к одному или более файлам (135) журнала тома.

9. Способ по п.1, в котором одно или более изменений данных, которые являются целостными для первого и второго моментов времени, являются по меньшей мере либо целостными для приложений, либо целостными для файловой системы.

10. Способ по п.1, дополнительно содержащий этап, на котором изменяют путь к файлу для файла (120), соответствующего любому из одного или более изменений данных (121, 122, 123) на рабочем сервере, с тем, чтобы путь к файлу на рабочем сервере (105) отличался от пути к файлу на сервере (110) резервного копирования.

11. Способ по п.10, дополнительно содержащий этап, на котором коррелируют пути для файла (120) на рабочем сервере (105) и на сервере резервного копирования (110), с тем, чтобы новые изменения файла можно было отправить на сервер резервного копирования с изменением в пути для файла.

12. Способ по п.11, в котором этап корреляции пути к файлу для файла (120) содержит этапы, на которых:
идентифицируют начальный путь для файла (120); и
сохраняют начальный путь к файлу для файла на рабочем сервере (105).

13. Способ по п.11, в котором этап корреляции пути к файлу для файла (120) содержит этапы, на которых:
сканируют журнал (140) USN по меньшей мере первый раз для кэширования изменения в пути к файлу в рабочем сервере;
сканируют журнал USN по меньшей мере второй раз для идентификации начального пути к файлу на рабочем сервере (105); и
вычисляют откорректированный путь к файлу на сервере (110) резервного копирования на основе первого и второго сканирований.

14. Способ по п.1, дополнительно содержащий этап, на котором отправляют новое обновление данных тома на рабочем сервере на сервер резервного копирования, причем новое обновление является целостным для третьего момента времени (155), и причем время, прошедшее между вторым (150) и третьим (155) моментами времени, может быть установлено либо меньше приблизительно одного часа, либо меньше приблизительно получаса.

15. Способ по п.14, дополнительно содержащий этап, на котором отправляют запрос на сервер (110) резервного копирования копии одного или более файлов, причем запрос на сервер резервного копирования является запросом копии одного или более файлов, при этом запрос включает в себя указание на то, что один или более файлов являются действительными либо на второй (150), либо на третий (155) момент времени.

16. Способ по п.15, дополнительно содержащий этап приема ответа (160) восстановления от сервера (110) резервного копирования, причем ответ восстановления включает в себя полную копию данных для запрашиваемого одного или более файлов на второй или третий момент времени.

17. Способ репликации данных одного или более томов (175) рабочего сервера практически непрерывным и целостным образом с тем, чтобы недавние данные могли быть легко восстановлены с сервера резервного копирования, осуществляемый на сервере (110) резервного копирования в компьютеризированной среде (100), в которой один или более серверов резервного копирования производят резервное копирование данных с одного или более томов одного или более рабочих серверов (105), причем способ содержит этапы, на которых:
принимают (240) одну или более резервных копий тома от рабочего сервера (105), причем одна или более резервных копий тома являются целостными для начального момента времени (145);
принимают (250) одно или более целостных обновлений резервной копии, по меньшей мере одно из которых является целостным для приложений обновлением для по меньшей мере одной из одной или более резервных копий тома для последующего момента времени (150, 155);
принимают (260) запрос восстановления данных, которые являются действительными в соответствии с последующим моментом времени;
идентифицируют (270) запрашиваемые данные для последующего момента времени в одном или более томах сервера резервного копирования, причем запрашиваемые данные включают в себя по меньшей мере часть по меньшей мере одного целостного обновления резервной копии; и
отправляют (280) запрашиваемые данные (160), которые являются действительными на последующий момент времени, на рабочий сервер.

18. Способ по п.16, дополнительно содержащий этапы, на которых:
идентифицируют базовую полную копию (145) запрашиваемых данных;
идентифицируют каждое из одного или более целостных обновлений (150, 155) резервной копии для запрашиваемых данных, которые были приняты между приемом базовой полной копии и приемом по меньшей мере одного обновления резервной копии для последующего момента времени; и объединяют базовую полную копию запрашиваемых данных с идентифицированным одним или более целостными обновлениями резервной копии для запрашиваемых данных.

19. Способ по п.18, в котором одна или более резервных копий тома и одно или более целостных обновлений резервной копии являются по меньшей мере либо целостными для приложений, либо целостными для файловой системы.

20. Машиночитаемый носитель информации, хранящий исполняемые на компьютере команды, которые при их исполнении заставляют один или более процессоров на рабочем сервере выполнять способ репликации данных рабочего сервера практически непрерывным и целостным для приложений образом с тем, чтобы недавние данные могли быть легко восстановлены с сервера резервного копирования, осуществляемый на рабочем сервере (105) в компьютеризированной среде (100), в которой один или более рабочих серверов производят резервное копирование данных, которые должны быть защищены, на одном или более серверах (110) резервного копирования, причем способ содержит этапы, на которых:
отправляют (200) копию данных для одного или более томов с рабочего сервера (105) на сервер (110) резервного копирования, причем данные являются целостными на первый момент времени (145);
идентифицируют (210) одно или более изменений (121, 122, 123) в данных для одного или более томов (175) в одном или более файлах (135) журнала тома; после идентификации события цикла репликации сохраняют (220) одно или более изменений данных в одном или более файлах журнала тома, причем одно или более изменений данных являются целостными на второй момент времени (150); и
отправляют (230) серверу резервного копирования копию одного или более изменений данных для одного или более томов, с тем, чтобы сервер резервного копирования имел копию данных для одного или более томов, которые являются действительны на первый момент времени (145) и на второй момент времени (150).