Эффективное создание частых резервных копий целостных для приложений

Эффективное создание частых резервных копий целостных для приложений

Иллюстрации

Показать все

Реферат

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

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

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

Однако следует понимать, что может иметься любое количество трудностей, связанных с созданием целостных для приложений резервных копий данных. Например, традиционные механизмы для создания резервных копий обычно включают в себя приложение, например, компонент резервного копирования почты или приложение базы данных, вызывающую один или более интерфейсов приложений (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 резервного копирования реализу