U.S. patent application number 15/198269 was filed with the patent office on 2016-10-20 for de-duplication systems and methods for application-specific data.
The applicant listed for this patent is Commvault Systems, Inc.. Invention is credited to Parag GOKHALE, Rajiv KOTTOMTHARAYIL, Anand PRAHLAD, Manoj Kumar VIJAYAN.
Application Number | 20160306708 15/198269 |
Document ID | / |
Family ID | 43465981 |
Filed Date | 2016-10-20 |
United States Patent
Application |
20160306708 |
Kind Code |
A1 |
PRAHLAD; Anand ; et
al. |
October 20, 2016 |
DE-DUPLICATION SYSTEMS AND METHODS FOR APPLICATION-SPECIFIC
DATA
Abstract
Content-aware systems and methods for improving de-duplication,
or single instancing, in storage operations. In certain examples,
backup agents on client devices parse application-specific data to
identify data objects that are candidates for de-duplication. The
backup agents can then insert markers or other indictors in the
data that identify the location(s) of the particular data objects.
Such markers can, in turn, assist a de-duplication manager to
perform object-based de-duplication and increase the likelihood
that like blocks within the data are identified and single
instanced. In other examples, the agents can further determine if a
data object of one file type can or should be single-instanced with
a data object of a different file type. Such processing of data on
the client side can provide for more efficient storage and back-end
processing.
Inventors: |
PRAHLAD; Anand; (Bangalore,
IN) ; VIJAYAN; Manoj Kumar; (Marlboro, NJ) ;
KOTTOMTHARAYIL; Rajiv; (Marlboro, NJ) ; GOKHALE;
Parag; (Marlboro, NJ) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Commvault Systems, Inc. |
Tinton Falls |
NJ |
US |
|
|
Family ID: |
43465981 |
Appl. No.: |
15/198269 |
Filed: |
June 30, 2016 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
13931654 |
Jun 28, 2013 |
9405763 |
|
|
15198269 |
|
|
|
|
12724292 |
Mar 15, 2010 |
8484162 |
|
|
13931654 |
|
|
|
|
61165071 |
Mar 31, 2009 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06F 11/1453 20130101;
G06F 11/1448 20130101; G06F 16/162 20190101; G06F 21/604 20130101;
G06F 11/1464 20130101; G06F 11/1469 20130101; G06F 16/1748
20190101; G06F 16/9574 20190101 |
International
Class: |
G06F 11/14 20060101
G06F011/14; G06F 21/60 20060101 G06F021/60; G06F 17/30 20060101
G06F017/30 |
Claims
1. A system for creating a backup copy of data, the system
comprising: computer readable memory comprising at least a first
de-duplication database associated with data generated by at least
first and second clients; a de-duplication module executing on one
or more computer processors comprising computer hardware, the
de-duplication module receives the data and performs de-duplication
as part of a backup of the data, the de-duplication module further
configured to: determine if a duplicate copy of a first portion of
the data from the first client exists in the first de-duplication
database; and if a duplicate copy does not exist in the first
de-duplication database, storing first metadata that identifies the
first client in association with the duplicate copy; determine if a
duplicate copy of a second portion of the data from the second
client exists in the first de-duplication database; if a duplicate
copy of the second portion of the data exists in the first
de-duplication database, removing the duplicate data in the second
portion of the data; determining whether second metadata in the
second portion of the data identifies whether the second client is
unique; and if the second metadata is unique, storing the second
metadata in association with the duplicate copy in the first
de-duplication database, store the first and second metadata
associated with the duplicate copy wherein the first metadata that
identifies the first client and the second metadata that identifies
the second client are stored in association with the duplicate
copy.
2. The system of claim 1 wherein the first and second metadata
identify differing operating systems.
3. The system of claim 1 wherein the first and second metadata
identify differing permissions.
4. The system of claim 1 wherein the data comprises first
application-specific data associated with a first application and
second application-specific data associated with a second
application.
5. The system of claim 4, further comprising a third module
executing on one or more computer processors configured to: parse
the second application-specific data that is different in format
than the first application-specific data, the second
application-specific data comprising a second plurality of data
objects; identify portions within the second plurality of data
objects to be considered for de-duplication; and insert at least
one de-duplication indicator in the second application-specific
data that identifies at least one location of the identified
portions in the second plurality of data objects to be considered
for de-duplication.
6. The system of claim 4 wherein the de-duplication module is
further configured to determine whether a duplicate copy of the
second portion of the data exists in a second de-duplication
database.
7. The system of claim 4 wherein the inserted at least one
de-duplication indicator in the second application-specific data
further identifies that the second de-duplication database is to be
used in de-duplicating the application-specific data.
8. The system of claim 4 wherein: the first de-duplication database
is configured to store unique blocks of the first portion of the
data associated with the first application-specific data; and the
second de-duplication database is configured to store unique blocks
of the second portion of the data associated with the second
application-specific data, wherein the first de-duplication
database is separate and different from the second de-duplication
database.
9. The system of claim 4 wherein the inserted at least one
de-duplication indicator indicates at least one of the first
de-duplication database and the second de-duplication database.
10. The system of claim 4 wherein the first application-specific
data is associated with an electronic mail server application.
11. A method for creating a backup copy of data, the method
comprising: storing a first de-duplication database associated with
data generated by at least first and second clients; performing
de-duplication of the data as part of a backup of the data;
determining if a duplicate copy of a first portion of the data from
the first client exists in the first de-duplication database; if a
duplicate copy of the first portion of the data does not exist in
the first de-duplication database, storing first metadata that
identifies the first client in association with the duplicate copy;
determining if a duplicate copy of a second portion of the data
from the second client exists in the first de-duplication database;
if a duplicate copy associated with the second portion of the data
exists in the first de-duplication database, removing the duplicate
data in the second portion of the data; determining whether second
metadata in the second portion of the data identifies whether the
second client is unique; and if the second metadata is unique,
storing the second metadata in association with the duplicate copy
in the first de-duplication database, wherein the backup copy
stores the first and second metadata associated with the duplicate
copy wherein the first metadata that identifies the first client
and the second metadata that identifies the second client are
stored in association with the duplicate copy.
12. The method of claim 11 wherein the first and second metadata
identify differing operating systems.
13. The method of claim 11 wherein the first and second metadata
identify differing permissions.
14. The method of claim 11 wherein the data comprises first
application-specific data associated with a first application and
second application-specific data associated with a second
application.
15. The method of claim 14 further comprising: parsing the second
application-specific data that is in a different format than the
first application-specific data, the second application-specific
data comprising a second plurality of second data objects;
identifying portions within the second plurality of second data
objects to be considered for de-duplication; and inserting at least
one de-duplication indicator in the second application-specific
data that identifies at least one location of the identified
portions in the second plurality of data objects to be considered
for de-duplication.
16. The method of claim 14 further comprising determining whether
the duplicate copy of the second portion of the data exists in a
second de-duplication database.
17. The method of claim 14 wherein the inserted de-duplication
indicators in the second application-specific data further identify
that the second de-duplication database is to be used in
de-duplicating the application-specific data.
18. The method of claim 14 wherein: the first de-duplication
database is configured to store unique blocks of the first portion
of the data associated with the first application-specific data;
and the second de-duplication database is configured to store
unique blocks of the second portion of the data associated with the
second application-specific data, wherein the first de-duplication
database is separate and different from the second de-duplication
database.
19. The method of claim 14 wherein the inserted at least one
de-duplication indicators indicate at least one of the first
de-duplication database and the second de-duplication database.
20. The method of claim 14 wherein the first application-specific
data is associated with an electronic mail server application.
Description
RELATED APPLICATIONS
[0001] Any and all applications for which a foreign or domestic
priority claim is identified in the Application Data Sheet, or any
correction thereto, are hereby incorporated by reference into this
application under 37 CFR 1.57.
BACKGROUND
[0002] 1. Field
[0003] Embodiments of the invention relate to data management and,
in particular, to systems and methods for reducing duplicate data
in a computer system.
[0004] 2. Description of the Related Art
[0005] With the increased reliance on computer systems to store
critical information, the importance of protecting information has
grown. As a result, certain storage systems receive an
identification of a file to protect and then create one or more
secondary copies, such as backup files, containing the contents of
the file. These secondary copies can then later be used to restore
the original data should anything happen to the original data.
[0006] In corporate environments, protecting information is
generally part of a routine process that is performed for many
computer systems within an organization. For example, a company
might back up critical computing systems related to e-commerce such
as databases, file servers, web servers, and so on as part of a
daily, weekly, or monthly maintenance schedule. The company may
also protect computing systems used by each of its employees, such
as those used by an accounting department, marketing department,
engineering department, and so forth.
[0007] Although each computer system contains certain unique
information, many systems may contain very similar information. For
example, although a computing system used by a marketing employee
and a computing system used by an engineering employee will
generally contain unique information created by each employee in
the course of their work, both computing systems will likely have
the same operating system installed, with thousands of identical or
similar files used by the operating system. Similarly, both
computing systems will likely have at least some similar
application programs installed, such as a word processor,
spreadsheet, Internet browser, and so on. Both systems may also
have similar corporate information. For example, each employee may
have an electronic copy of an employee manual distributed by the
company. Information other than files may also be identical or
similar between systems. For example, user settings and preferences
may have similar default values on each system and application
programs may contain similar templates on each system that are
stored as application-specific information. As another example,
several employees may have received a copy of the same email, and
the email may be stored in each employee's electronic mailbox.
[0008] As a result of the amount of redundant information in an
organization, secondary copies of an organization's information are
often very large and can require the purchase of expensive storage
devices and storage media. The restoration of data in the event of
data loss is also slowed by the large size of the secondary copies.
As the size of secondary copies increases, locating and restoring
information requires more actions to be taken. For example, it may
be necessary to search many tapes or other media to find the
correct secondary copy. The great quantity of storage media, such
as tapes, may mean that some secondary storage media has been moved
offsite requiring that it first be retrieved before information can
be recovered from it. Each of these factors increases the cost of
protecting information and the time required to recover information
in the event of data loss. Quick recovery of information is often
critical to today's businesses, and any additional delay can affect
business operations and customers' satisfaction with the
business.
SUMMARY
[0009] Single instancing in a data management system is the process
of attempting to store only a single instance of a file or data
object. Certain objects are often stored in large, monolithic files
that are intended to be read only by the application that created
them. For example, a MICROSOFT EXCHANGE email server stores email
messages in one or more large data files that typically hold
thousands of different users' mailboxes. As another example, a
database server often stores tables, forms, reports, and other data
objects in one or two large data files that provide persistence for
the entire database.
[0010] Thus, typical data management systems are only able to
perform data management operations on the large data file, rather
than the data objects themselves. In the case of the email server,
a given electronic mail application may generate multiple email
messages that all differ, but which all contain the same
attachment. Prior systems may not be able to differentiate these
messages, and thus each would be stored with the attachment.
Further, if two files had different properties or metadata, such
prior systems would store both files, even though the data they
contain are identical and differ only by their metadata.
[0011] In view of the foregoing, certain embodiments of the
invention include a de-duplication system for managing
application-generated data objects. The system comprises a first
backup agent executing on a first client device and a
de-duplication module executing on a computing device. The first
backup agent is configured to, in response to a storage operation
request: parse first application-specific data of the first client
device that is the subject of the storage operation request, the
first application-specific data comprising a plurality of first
data objects having different sizes; identify, based at least on an
application that generated the first application-specific data, one
or more of the plurality of first data objects of the first
application-specific data to be considered for de-duplication,
wherein the one of more first data objects comprises less than the
entire first application-specific data; and insert at least one
indicator in the first application-specific data that identifies at
least one location of the one or more first data objects within the
first application-specific data. The de-duplication module is in
communication with the first backup agent to receive the first
application-specific data and is configured to: process each of the
one or more data objects; and, based on said processing, determine
if a duplicate copy of any of the one or more first data objects
exists in a storage device.
[0012] In certain embodiments, a method is disclosed for managing
application-generated data objects. The method comprises receiving
a first storage operation request for first data generated by a
first application executing on a first client device, the first
data comprising a plurality of first data objects having
non-uniform sizes. The method further comprises parsing the first
data to identify one or more of the plurality of first data objects
to be considered for de-duplication. The method also includes
inserting at least one indicator in the first data that identifies
at least one location of the one or more first data objects within
the first data and processing each of the one or more first data
objects to determine if a duplicate copy of the one or more first
data objects exists in at least one storage device. For each of the
one or more first data objects, if a duplicate copy does not exist
in the storage device, the method stores the first data object in
the at least one storage device. Otherwise, a stub file and/or a
pointer is stored in place of the first data object in the storage
device.
[0013] In certain embodiments, a method is disclosed for managing
application-generated data objects. The method includes receiving a
first storage operation request for first data generated by a first
application executing on a first client device, the first data
comprising a plurality of first data objects. The method also
includes parsing the first data to identify one or more of the
first data objects to be considered for de-duplication and
receiving a second storage operation request for second data
generated by a second application, the second data comprising a
plurality of second data objects, and the second data having a
different file format than the first data. The method further
includes parsing the second data to identify one or more of the
plurality of second data objects to be considered for
de-duplication. In addition, the method includes inserting in the
first data and/or the second data an indicator that denotes, based
on the first and second file formats, that the one or more first
data objects should not be single instanced with the one or more
second data objects.
[0014] In certain embodiments, a system is disclosed for managing
application-generated data objects. The system includes means for
receiving a first storage operation request for first data
generated by a first application executing on a first client
device, the first data comprising a plurality of first data objects
having differing sizes. The system also includes means for parsing
the first data to identify one or more of the first data objects to
be considered for de-duplication, wherein the one of more first
data objects comprises less than the entire first data; means for
inserting at least one indicator in the first data that identifies
at least one location of the one or more first data objects within
the first data; and means for processing each of the one or more
first data objects to determine if a duplicate copy of the first
data object exists in at least one storage device. In addition, the
system includes means for (i) storing each of the one or more first
data objects in the storage device that does not have a duplicate
copy and (ii) storing a stub and/or a pointer in place of each of
the one or more first data objects that does have a duplicate copy
in the at least one storage device.
[0015] In certain embodiments, a method is disclosed for managing
data in a computer system. The method comprises accessing first
data, the first data comprising at least one first data object in a
first file format, and accessing second data, the second data
comprising at least one second data object in a second file format,
the second file format being different than the first file format.
The method further comprises inserting in at least one of a copy of
the first data and a copy of the second data an indicator that
denotes that, based on the first and second file formats, the at
least one first data object cannot or should not be single
instanced with the at least one second data object.
[0016] In certain embodiments, the method is performed by one or
more content-aware data agents residing on one or more client
devices. Such agents can advantageously identify portions of data
to be backed up, archived or otherwise stored to be considered for
possible de-duplication.
[0017] In certain embodiments, a de-duplication system is disclosed
for managing application-generated data objects. The system
comprises a first backup agent executing on a first client device,
the first backup agent being configured to, in response to a
storage operation request: (i) parse first application-specific
data of the first client device that is the subject of the storage
operation request,(ii) identify one or more first data objects of
the first application-specific data to be considered for
de-duplication, and (iii) insert an indicator in a copy of the
application-specific data that identifies the one or more first
data objects to be considered for de-duplication.
[0018] For purposes of summarizing the disclosure, certain aspects,
advantages and novel features of the inventions have been described
herein. It is to be understood that not necessarily all such
advantages may be achieved in accordance with any particular
embodiment of the invention. Thus, the invention may be embodied or
carried out in a manner that achieves or optimizes one advantage or
group of advantages as taught herein without necessarily achieving
other advantages as may be taught or suggested herein.
BRIEF DESCRIPTION OF THE DRAWINGS
[0019] FIG. 1 is a block diagram that illustrates components of a
single instancing system in accordance with one embodiment of the
invention.
[0020] FIG. 2 is a block diagram that illustrates an example data
file containing data objects.
[0021] FIG. 3A is a block diagram that illustrates the flow of data
during a storage operation, in one embodiment.
[0022] FIG. 3B is a block diagram that illustrates components of a
content-aware de-duplication system in accordance with certain
embodiments of the invention.
[0023] FIG. 3C illustrates exemplary fields of a chunk file usable
with the de-duplication system of FIG. 3B in accordance with
certain embodiments of the invention.
[0024] FIG. 4 is a flow diagram that illustrates processing of a
storage operation manager component of the single instancing
system, in one embodiment.
[0025] FIG. 5 is a flow diagram that illustrates processing of the
single instancing system to determine whether a data object is
unique, in one embodiment.
[0026] FIG. 6 is a flow diagram that illustrates processing of the
storage operation manager component to restore data, in one
embodiment.
[0027] FIG. 7 is a block diagram that illustrates an environment in
which the single instancing system may be configured to
operate.
[0028] FIG. 8 is a flow diagram that illustrates copying a remote
file or data object in the environment of FIG. 7
[0029] FIG. 9 is a block diagram that illustrates another
environment in which the single instancing system may be configured
to operate.
[0030] FIG. 10 is a flow diagram that illustrates copying a remote
file or data object in the environment of FIG. 9.
[0031] FIG. 11 is a block diagram that illustrates another
environment in which the single instancing system may be configured
to operate.
[0032] FIG. 12 is a flow diagram that illustrates copying a remote
file or data object in the environment of FIG. 11.
[0033] In the drawings, the same reference numbers and acronyms
identify elements or acts with the same or similar functionality
for ease of understanding and convenience. To easily identify the
discussion of any particular element or act, the most significant
digit or digits in a reference number refer to the Figure number in
which that element is first introduced (e.g., element 604 is first
introduced and discussed with respect to FIG. 6).
DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS
[0034] The headings provided herein are for convenience only and do
not necessarily affect the scope or meaning of the claimed
invention.
[0035] Overview
[0036] Described in detail herein are single instancing systems
that more intelligently identify multiple copies of the same data
object. For example, certain embodiments of the single instancing
system recognize documents, files, or data objects produced by
multiple different applications, and can parse through and identify
those data objects common among data blocks within a file, and
thereby only copy a single instance of those common data objects.
Further embodiments parse the proprietary data formats of many
applications and can identify data objects related to the
application, even when those data objects are stored in large,
monolithic data files. In addition, if two documents, files, or
data objects are substantially similar, but have differing
metadata, such as different user permissions, embodiments of the
single instancing system can store a single instance of the data
object, but retain all differing versions of the metadata (for
example, such as by retaining the different user permissions). When
a client requests the data object, the single instancing system
returns appropriate metadata based on the identity of the client or
other information.
[0037] According to other embodiments of the single instancing
system, if multiple clients and associated media agents are in
remote locations, the single instancing system may perform backup
of data to a local, single instance database or data store at each
remote location. Then, the single instancing system may use
continuous data replication (CDR) to copy the data contained in
each local data store to a central location.
[0038] In further embodiments, content-aware systems and methods
are disclosed for improving de-duplication/single instancing in
storage operations. In certain examples, backup agents on client
devices parse application-specific data to identify data objects
that are likely candidates for de-duplication. The backup agents
can then insert markers or other indictors in the data that
identify the location(s) of the particular data objects. Such
markers can, in turn, assist a de-duplication manager to perform
object-based de-duplication and increase the likelihood that like
blocks are identified within the data. In other examples, the
agents can further determine if a data object of one file type can,
or should, be single-instanced with a data object of a different
file type. Such processing of data on the client side can provide
for more efficient storage and back-end processing in a data
storage system.
[0039] The invention will now be described with respect to various
embodiments. The following description provides specific details
for a thorough understanding of, and enabling description for,
these embodiments of the invention. However, one skilled in the art
will understand that the invention may be practiced without these
details. In other instances, well-known structures and functions
have not been shown or described in detail to avoid unnecessarily
obscuring the description of the embodiments of the invention.
[0040] The terminology used in the description presented below is
intended to be interpreted in its broadest reasonable manner, even
though it is being used in conjunction with a detailed description
of certain specific embodiments of the invention. Certain terms may
even be emphasized below; however, any terminology intended to be
interpreted in any restricted manner will be overtly and
specifically defined as such in this Detailed Description
section.
[0041] Unless described otherwise below, embodiments of the
invention may be practiced with various data processing systems.
Thus, the construction and operation of the various blocks shown in
FIG. 1 need not be described in further detail herein to make and
use the invention, because such blocks will be understood by those
skilled in the relevant art. One skilled in the relevant art can
readily make any modifications necessary to the blocks in FIG. 1
(or other embodiments or figures) based on the detailed description
provided herein.
[0042] FIG. 1 is a block diagram that illustrates components of a
single instancing system 100, in one embodiment. The single
instancing system 100 contains a file identification component 110,
an identifier generation component 120, an identifier comparison
component 130, a single instance database component 140, a restored
file cache component 150, a storage operation manager component
160, an application data extraction component 170, and a remote
synchronization component 180.
[0043] The file identification component 110 identifies files or
data objects, such as in response to a storage operation. As used
herein, the terms "file" or "data object" are broad terms and are
used in their ordinary sense and include, without limitation, any
collection or grouping of bytes of data that can be viewed as one
or more logical units. For example, a file could be a computer file
on a file system (for example, a word processing file, a
spreadsheet file, a database file, etc.) As another example, a data
object could be a file or within a file (e.g., an embedded object
within a word processing file, a cell or a row in a spreadsheet
file, a table or an entry in a table in a database file, a string,
an array, or any other collection of electronic information).
Moreover, data objects need not be limited to units of the same
size but can comprise, in certain embodiments, multiple objects of
differing sizes. The file identification component 110 may retrieve
additional information related to a file or data object, such as
its size, that is used by the single instancing system 100 to
uniquely identify the data object.
[0044] When the file identification component 110 identifies a
file, the application data extraction component 170 determines
whether the file contains additional data objects. For example, the
file may be an application-specific container (for example, a
database file), that stores data objects such as documents, email
messages, and other collections of data. The application data
extraction component 170 would determine that each of the data
objects within the application-specific container should be
identified.
[0045] The identifier generation component 120 generates a
substantially unique identifier of a file or data object that is
used to determine if another file or data object already stored by
the single instancing system matches the file or data object used
to generate the substantially unique identifier. The identifier
comparison component 130 performs comparisons of identifiers of
various files or data objects to determine if the files or data
objects contain similar data (for example, the identifier
comparison component 130 can compare substantially unique
identifiers of two or more files or data objects to determine if
the files or data objects contain similar data).
[0046] The single instance database component 140 is a data store
that contains entries identifying files or data objects managed by
the single instancing system 100, and may also contain supplemental
information associated with files or data objects, such as a
substantially unique identifier, a path, a location, a reference
count, a file size or other information. The restored file cache
component 150 provides an intermediate location that may be used by
the single instancing system 100 during a restore operation to hold
instances of files or data objects for which additional references
may need to be restored.
[0047] For example, during a restore operation, the single
instancing system may restore files or data objects to the cache
and then transfer the files or data objects to a target location of
the restore operation. When the single instancing system 100
encounters a reference to a single instance copy of a file or data
object, the single instancing system 100 may consult the restored
file cache component 150 or an index. The single instancing system
100 does so to determine if the file or data object is present in
the cache before attempting to restore the file or data object from
another location, such as from secondary storage (for example, a
tape).
[0048] The storage operation manager component 160 coordinates
storage operations and invokes the other components of the single
instancing system 100 as needed to perform requested storage
operations. For example, the storage operation manager component
160 may include an application used by an administrator to manage
the single instancing system 100. The storage operation manager
component 160 may also maintain indexes of the data objects and
each of the references to those data objects through the single
instancing system 100, as well as pending operations on the data
objects that are part of a data management plan of an organization
implementing the single instancing system 100.
[0049] The remote synchronization component 180 performs single
instancing between a remote location and a central location, such
as between an enterprise or organization having a headquarters or
central office and one or more satellite offices or remote offices,
or vice-versa. The remote synchronization component 180 uses the
techniques described in further detail herein to determine whether
a file or data object should be copied from the remote location to
the central location.
[0050] FIG. 1 and the discussion herein provide a brief, general
description of a suitable computing environment in which the
invention can be implemented. Although not required, embodiments of
the invention are described in the general context of
computer-executable instructions, such as routines executed by a
general-purpose computer, e.g., a server computer, wireless device
or personal computer. Those skilled in the relevant art will
appreciate that the invention can be practiced with other
communications, data processing, or computer system configurations,
including: Internet appliances, hand-held devices (including
personal digital assistants (PDAs)), wearable computers, all manner
of cellular or mobile phones, multi-processor systems,
microprocessor-based or programmable consumer electronics, set-top
boxes, network PCs, mini-computers, mainframe computers, and the
like. Indeed, the terms "computer," "host," and "host computer" are
generally used interchangeably herein, and refer to any of the
above devices and systems, as well as any data processor.
[0051] Aspects of the invention can be embodied in a special
purpose computer or data processor that is specifically programmed,
configured, or constructed to perform one or more of the
computer-executable instructions explained in detail herein.
Embodiments of the invention can also be practiced in distributed
computing environments where tasks or modules are performed by
remote processing devices, which are linked through a
communications network, such as a Local Area Network (LAN), Wide
Area Network (WAN), or the Internet. In a distributed computing
environment, program modules may be located in both local and
remote memory storage devices.
[0052] Embodiments of the invention may be stored or distributed on
computer-readable media, including magnetically or optically
readable computer discs, hard-wired or preprogrammed chips (e.g.,
EEPROM semiconductor chips), nanotechnology memory, biological
memory, or other data storage media. Indeed, computer implemented
instructions, data structures, screen displays, and other data
under embodiments of the invention may be distributed over the
Internet or over other networks (including wireless networks), on a
propagated signal on a propagation medium (e.g., an electromagnetic
wave(s), a sound wave, etc.) over a period of time, or they may be
provided on any analog or digital network (packet switched, circuit
switched, or other scheme). Those skilled in the relevant art will
recognize that portions of the invention may reside on a server
computer, while corresponding portions reside on a client computer
such as a mobile or portable device, and thus, while certain
hardware platforms are described herein, embodiments of the
invention are equally applicable to nodes on a network.
[0053] Single Instancing
[0054] Reducing or eliminating redundant instances of data
resulting from a storage operation is sometimes referred to here as
de-duplication or "single instancing," because what would
traditionally be stored as many instances of the same data is
reduced to as few as one. Redundant instances may be detected and
reduced at several locations or times throughout the operation of
the system that will now be described. These embodiments are
provided only as examples, and are not intended to be an exhaustive
list of the way in which the system can be implemented.
[0055] In some embodiments, the single instancing system performs
single instancing of data at a computing system that contains or
originally generated the data, such as a client computing system.
For example, a client computing system that is providing data that
is the target of a storage operation may receive a request from the
single instancing system to provide a substantially unique
identifier (for example, a hash value, message digest, checksum,
digital fingerprint, digital signature or other sequence of bytes
that substantially uniquely identifies the file or data object) of
each file or data object included in the storage operation.
[0056] The word "substantially" is used to modify the term "unique
identifier" because algorithms used to produce hash values may
result in collisions, where two different files or data objects
result in the same hash value. However, depending upon the
algorithm or cryptographic hash function used, collisions should be
suitably rare and thus the identifier generated for a file or data
object should be unique throughout the single instancing system. As
an alternative to the single instancing system generating the
substantially unique identifier, the client computing system may
itself generate substantially unique identifiers for each file or
data object that is stored on the client computing system on an
ongoing or other basis. When a storage operation is requested, the
single instancing system determines if another file or data object
exists with a substantially unique identifier matching that of the
one provided by the client computing system. If the single
instancing system is already aware of a similar file or data
object, then the client computing system does not need to send the
redundant file or data object to a secondary storage location or
destination.
[0057] Rather than operating only at the file level, in some
embodiments, the single instancing system may also operate at a
lower level of granularity by enumerating data objects within files
of understood types. For example, the single instancing system may
read and parse data files from email servers (for example,
MICROSOFT EXCHANGE email servers, Sendmail email servers, etc.),
database servers (for example, MICROSOFT SQL Server database
servers, ORACLE database servers, etc.), web servers (for example,
MICROSOFT IIS web servers, APACHE web servers, etc.), word
processing applications (for example, MICROSOFT WORD, COREL
WORDPERFECT, etc.), spreadsheet applications (for example,
MICROSOFT EXCEL, APPLE NUMBERS, etc.), and many others and
enumerate the data objects within these files.
[0058] The single instancing system may then generate a
substantially unique identifier for each data object within the
file, rather than each file, and store this substantially unique
identifier in the single instance database component 140 or other
index. The single instancing system may also store information
about the associations between the data objects and their
containing files. Therefore, the single instancing system enables
data storage operations such as searching, backing up, restoring,
replicating, copying and so forth to be performed at the data
object level. Enabling data storage operations at the data object
level enables the single instancing system to store data using much
less space than traditional single instancing storage systems,
because files containing data objects are likely to have redundant
data objects, of which only one instance or copy need be
stored.
[0059] For example, the data of two email servers that each contain
similar email messages in a large data file can be stored in much
less space than if the entire data files of each email server were
to be stored, because the data files are likely to contain
redundant email messages, of which only one instance or copy need
be stored. This is because traditional single instancing systems
would determine that the two data files differed and would store
both data files, thereby consuming more storage space.
[0060] FIG. 2 illustrates an example data file produced by an email
server. The data file 210 holds containers 220 of data related to
each user that has a mailbox on the email server. Each container
220 holds email messages 230 for a specific user, and each email
message 230 may contain one or more attachments 240. Email messages
are often forwarded to many users, and the users may be assigned to
the same or different email servers. The single instancing system
may know or understand the structure of the data file 210 before
performing any single instancing operations, as discussed in more
detail with respect to FIGS. 3B and 3C.
[0061] For example, the single instancing system may identify the
type of the data file based on the data file's filename extension.
The identified data file type may be used to identify a format or
specification that describes the structure (e.g., at which bytes
specific data is stored, its particular encoding, etc.) of the data
file. This knowledge of the structure enables the application data
extraction component 170 to parse the data file 210, identify
containers 220, and extract email messages 230 or attachments 240
from each container 220. Alternatively, the data file 210 may
contain metadata, a header or other information that describes its
data structure.
[0062] The application data extraction component 170 can obtain
this metadata or other information, which enables it to parse the
data file 210, identify containers 220, and extract email messages
230 or attachments 240 from each container 220. The single
instancing system can then store only a single instance or copy of
the extracted email messages 230 or attachments 240 that are
similar. By operating on the data at the data object level, the
single instancing system provides substantial benefit by
identifying the redundancy of data objects stored within the data
files and providing single instancing of the individual data
objects.
[0063] In some embodiments, the single instancing system or another
system performs additional operations on the data after single
instancing has occurred. For example, another system may encrypt
backup data that is being stored offsite to prevent unauthorized
parties from accessing the data. Another system may also compress
the data to reduce its size. The single instancing system enables
these additional operations to be performed more efficiently,
because there is less data on which to perform these additional
operations after redundant data has been reduced or eliminated.
[0064] Single Instanced Archive and Backup Data Using Single
Storage Policy
[0065] One example of a single instancing system employs a single
storage policy or data store. A storage policy is generally a
virtual container with preferences that contains a set of rules for
data retention of data objects associated with the storage policy.
The single instancing system in this example stores single instance
data in a single location and in a manner to ensure that any
relevant, unique data is retained, but only a single instance of
common data is copied to the data store. Notably, a single
instancing agent creates, updates, or maintains a single instance
database or index that represents or stores the substantially
unique identifiers of each file or data object. The single instance
database or index is associated with a single storage policy that
is separate from one or more data stores that store the data
copies. A single storage policy may represent a storage location
that includes existing data, as well as new data that has been
compared to the existing data and identified as being unique.
[0066] FIG. 3A is a block diagram that illustrates the flow of data
during a storage operation, in one embodiment. Data is initially
stored on a server 310 or other source of data. A storage policy
320 or other configuration information specifies a storage
operation to be performed on the data. For example, the storage
policy 320 may specify that the data stored on the server 310 is to
be backed up daily to tape. The application of the storage policy
320 causes the backup to occur, resulting in the creation of the
data copy 330. The data copy 330 may contain many redundant files
or other data objects.
[0067] A media agent 340 manages the data copy 330, and creates a
single instance copy 350. The single instance copy 350 is a copy in
which at least some of the redundant files or data objects have
been removed. The media agent 340 uses the methods described herein
to eliminate redundant instances of files or data objects contained
in the data copy 330, and to produce the single instance copy 350.
The single instance copy 350 may then be stored on tape or other
media.
[0068] The single instancing system may employ one or more
specialized single instancing agents. For example, as described
below, the single instancing system may employ application agents
associated with types of applications, metadata agents for
analyzing metadata, encryption/compression agents, and so forth.
Alternatively, a single agent employing all of the functions
described herein may be employed. These agents operate on all types
of data, including documents, files, data objects, or any data
blocks.
[0069] An application agent associated with each type of
application may analyze incoming or previously stored data to
identify redundant data. For example, an email agent analyzes
incoming or previously stored emails, including attachments to
emails, to identify duplicate attachments. The email agent provides
a first instance of an email with an attachment to the storage
policy, but for subsequent emails having the same attachment, the
email agent strips them of their attachments and stores them with a
stub or pointer to the previously stored attachment.
[0070] A metadata agent analyzes files or data objects for
similarities in data, but differences in metadata that is
associated with the files or data objects. For example, two files
may have the same data, but separate permissions, properties,
access control lists (ACLs), operating system metadata (e.g., UNIX
and WINDOWS metadata), application-specific metadata, ownership
metadata, anti-virus information, security metadata, other
metadata, combinations of the same or the like. The metadata agent
ascertains that the two files contain the same data but have
differing metadata, and thus stores only one instance of the file,
but two or more instances of the associated metadata, as well as
information about the associations between the metadata, the
providers of the files and the files. Such embodiments of the
invention can advantageously allow for single instancing, or
de-duplication, of files or data objects across different operating
systems.
[0071] When a client requests the file, the single instancing
system provides the file to the client with the appropriate
instance of the metadata based on the identity of the requestor.
For example, a data file may be stored on a user computer with
permissions restricting access to the data file to the user of that
computer, and the same data file may be stored on a second computer
with permissions restricting access to the data file to an
administrator of the single instancing system. The user will still
be able to access the data file from the single instance store even
though the user is not an administrator of the single instancing
system. This is because the single instancing system will use the
metadata from the file from the user's computer to ascertain that
the user has the permissions needed to access the file, and permit
the requested access to the user.
[0072] As another example, two files may have the same data, but
different properties, such as the creation date or access date. The
metadata agent ascertains that the two files contain the same
content but have different properties. The metadata agent thus
stores only one instance of the file, but two or more instances of
the properties, as well as information about the associations
between the metadata, the providers of the files and the files.
Because an association between the provider of the file and the
file is stored, when a client requests the file, the single
instancing system can provide the file with the proper metadata to
the client.
[0073] In yet other embodiments, one or more agents on one or more
client devices can perform one or more functions of the
above-described metadata agent. Embodiments of agents usable with
embodiments of the invention are described in more detail below,
with particular reference to FIGS. 3B and 3C.
[0074] The single instancing system can single instance both
non-encrypted and encrypted data received from client computers.
Each client computer may generate a substantially unique identifier
for the file or data object before the file or data object is
encrypted. The client computer does this before encryption because
an encrypted file or data object would almost certainly result in a
substantially unique identifier that is different from a
substantially unique identifier generated from the file or data
object before encryption. Alternatively, a client computer could
generate a substantially unique identifier for a file or data
object after the file or data object is encrypted. An encryption
agent may compare the substantially unique identifiers to identify
identical files or data objects, and thus only store one instance
of them.
[0075] In some embodiments, the single instancing system determines
whether to store an instance of an encrypted or unencrypted file
(or data object, but file is used in this and the following
paragraphs discussing encryption for brevity) based on whether the
files are encrypted using the same encryption scheme, whether the
encrypted files can be decrypted by the single instancing system,
and/or other factors.
[0076] For example, consider the following three situations
involving encrypted files: 1) where the single instancing system
has previously stored an instance of a file that is encrypted and a
request is made to store another instance of the file that is also
encrypted; 2) where the single instancing system has previously
stored an instance of a file that is unencrypted and a request is
made to store another instance of the file that is encrypted; and
3) where the single instancing system has previously stored an
instance of a file that is encrypted and a request is made to store
another instance of the file that is unencrypted. Metadata
associated with the file is typically not encrypted. Moreover,
information about the encryption scheme (for example, what public
key is used to encrypt the file) may be provided as metadata to the
single instancing system.
[0077] For the first situation, if the two file instances are
encrypted using the same encryption scheme (for example, using the
same public key), the single instancing system can avoid storing
the second instance of the file. If the two files are encrypted
using different encryption schemes, the single instancing system
stores the second instance of the file. This is because the single
instancing system has to be able to provide the second instance of
the file to the requestor when requested.
[0078] Alternatively, if both encryption schemes are known to the
single instancing system (for example, using two different public
keys of the single instancing system), the single instancing system
can avoid storing the file. This is because the single instancing
system can decrypt the first instance of the file and re-encrypt it
using the encryption scheme used to encrypt the second instance of
the file. However, this decryption and re-encryption may be too
computationally expensive, depending upon various factors (for
example, the time needed to decrypt and re-encrypt the file, the
algorithm, etc.), and so the single instancing system may simply
store the second instance of the file.
[0079] For the second situation, if the second instance of the file
is encrypted using an encryption scheme that is known to the single
instancing system (for example, using a public key of the single
instancing system), the single instancing system can avoid storing
the second instance of the file. This is because, when the provider
of the second encrypted instance requests the file, the single
instancing system can retrieve the first unencrypted instance,
encrypt it using the known encryption scheme and provide it to the
requestor. However, if such encryption is too computationally
expensive, the single instancing system may simply store the second
encrypted instance of the file. If the second instance of the file
is encrypted using an encryption scheme that is not known to the
single instancing system, the single instancing system stores the
second instance of the file. This is because the single instancing
system has to be able to provide the second encrypted instance of
the file to the requestor when requested.
[0080] For the third situation, if the first instance of the file
is encrypted in such a way that it can be decrypted by the single
instancing system, the single instancing system can avoid storing
the second unencrypted instance of the file. This is because, when
the provider of the second unencrypted instance requests the file,
the single instancing system can retrieve the first encrypted
instance, decrypt it, and provide it to the requestor. However, if
such decryption is too computationally expensive, the single
instancing system may simply store the second unencrypted instance
of the file. If the first instance of the file is encrypted in such
a way that it cannot be decrypted by the single instancing system,
the single instancing system stores the second unencrypted instance
of the file. This is because the single instancing system has to be
able to provide the second unencrypted instance of the file to the
requestor.
[0081] The single instancing system may also handle compressed
files. Each client computer may generate a substantially unique
identifier for the file or data object before the file or data
object is compressed. The client computer does this before
compression because a compressed file or data object would almost
certainly result in a substantially unique identifier that is
different from a substantially unique identifier generated from the
file or data object before compression. Alternatively, a client
computer could generate a substantially unique identifier for a
file or data object after the file or data object is compressed. A
compression agent may compare the substantially unique identifiers
to identify identical files or data objects, and thus only store
one of them.
[0082] In some embodiments, the single instancing system determines
whether to store an instance of a compressed or uncompressed file
(or data object, but file is used in this and the following
paragraphs discussing compression for brevity) based on whether the
files are compressed using the same compression scheme, whether the
compressed files can be decompressed by the single instancing
system, and/or other factors.
[0083] For example, consider the following three situations
involving compressed files: 1) where the single instancing system
has previously stored an instance of a file that is compressed and
a request is made to store another instance of the file that is
also compressed; 2) where the single instancing system has
previously stored an instance of a file that is uncompressed and a
request is made to store another instance of the file that is
compressed; and 3) where the single instancing system has
previously stored an instance of a file that is compressed and a
request is made to store another instance of the file that is
uncompressed. Metadata associated with the file is typically not
compressed. Moreover, information about the compression scheme (for
example, what compression algorithm is used to compress the file)
may be provided as metadata to the single instancing system.
[0084] For the first situation, if the two file instances are
compressed using the same compression scheme (for example, using
the same compression algorithm), the single instancing system can
avoid storing the second instance of the file. Otherwise, the
single instancing system stores the second instance of the file.
However, if the second instance of the file is compressed using a
different compression scheme, the single instancing system may
avoid storing the second instance of the file, if the single
instancing system is able to decompress the first instance of the
file and recompress the first instance of the file using the
different compression scheme. If the single instancing system is
not able to do so, the single instancing system stores the second
instance of the file. However, this decompress and recompression
may be too computationally expensive, depending upon various
factors (for example, the time needed to decompress and recompress
the file, the algorithm, etc.), and so the single instancing system
may simply store the second instance of the file.
[0085] For the second situation, if the second instance of the file
is compressed using a compression scheme that is known to the
single instancing system (for example, using a known compression
algorithm), the single instancing system can avoid storing the
second instance of the file. This is because, when the provider of
the second compressed instance requests the file, the single
instancing system can retrieve the first uncompressed instance,
compress it using the known compression scheme and provide it to
the requestor. However, if such compression is too computationally
expensive, the single instancing system may simply store the second
compressed instance of the file. If the second instance of the file
is compressed using a compression scheme that is not known to the
single instancing system, the single instancing system stores the
second instance of the file. This is because the single instancing
system has to be able to provide the second compressed instance of
the file to the requestor when requested.
[0086] For the third situation, if the first instance of the file
is compressed in such a way that it can be decompressed by the
single instancing system, the single instancing system can avoid
storing the second uncompressed instance of the file. This is
because, when the provider of the second uncompressed instance
requests the file, the single instancing system can retrieve the
first compressed instance, decompress it, and provide it to the
requestor. However, if such decompression is too computationally
expensive, the single instancing system may simply store the second
uncompressed instance of the file. If the first instance of the
file is compressed in such that it cannot be decompressed by the
single instancing system, the single instancing system stores the
second uncompressed instance of the file. This is because the
single instancing system has to be able to provide the second
uncompressed instance of the file to the requestor.
[0087] The single instancing system may be configurable to reduce
processing time, transmission bandwidth, and the like with small
files. For example, an administrator-configurable value would allow
the administrator to configure the single instancing system to
ignore files or data objects below a given size. For example, any
file or data object below a certain threshold (for example, one
kilobyte) may simply be stored, and a substantially unique
identifier would not determined for it. Any file or data object
greater than the threshold (for example, one kilobyte) would then
be single instanced. An administrator may adjust this threshold up
or down. As another example, the single instancing system may allow
the administrator to configure it to always single instance files
or data objects of a certain type or category (for example,
executable files or modules may always be single instanced if they
rarely change).
[0088] Alternatively, embodiments of the single instancing system
may allow the administrator to never single instance files or data
objects of a certain type or category (for example, log files may
never be single instanced, because they typically change quite
frequently) or compare data objects of certain different data
formats.
[0089] In yet other embodiments, the single instancing system can
comprise multiple single instancing, or de-duplication, components
(e.g., databases) for processing and/or storing single instance
copies 350 of data from different applications and/or file formats.
For example, in certain embodiments, a file when processed (e.g.,
checked in) by a SHAREPOINT application can be fundamentally
altered such that it differs from the same file when processed in
an EXCHANGE server environment.
[0090] In view of the foregoing, certain embodiments of the single
instancing system can determine that files or data objects from
these two applications should not be considered together for single
instancing since the copies of the same file will contain different
data. Rather, the single instancing system can comprise different
components that are each dedicated to single instance processing of
the data from the two applications. For example, in certain
embodiments, a first single instance database can allocated for
SHAREPOINT data, while a second single instance database can be
allocated for EXCHANGE data.
[0091] Moreover, the same single instancing system components can
be dedicated for single instancing data of different applications
that process data in a similar manner. For instance, in certain
embodiments, the second single instance database described above
could be allocated for both EXCHANGE and file system data, while
the first single instance database is reserved for SHAREPOINT
data.
[0092] In such embodiments, storage space can be advantageously
allocated on one or more storage devices based on the expected
amount of single instanced, or de-duplicated, data from the
different applications. For example, a main or primary
de-duplication database (e.g., having media with a faster access
time) can be set aside for de-duplication of files or data objects
from one or more applications or application formats producing a
relatively large amount of data within a system, while a secondary
de-duplication database can be reserved for data of one or more
applications or application formats producing a relatively small
amount of data in the system.
[0093] In certain embodiments, as discussed below with reference to
FIGS. 3B and 3C, agents operating on one or more client devices can
be used for identifying such application data that should or should
not be considered together for possible de-duplication. Such
identification could be performed, for example, when processing the
client data to be sent to be backed up, archived or otherwise
stored in secondary storage.
[0094] The single instancing system may further associate
timestamps with the files or data objects or with their generated
substantially unique identifiers. A timestamp may indicate the time
at which the file or data object was created, last accessed or
modified, or the time at which the single instancing system
generated the substantially unique identifier for it, or the time
at which the file or data object was stored by the single
instancing system. The single instancing system may do so to
determine whether a file or data object is substantially newer than
another file or data object already stored in the single instancing
system.
[0095] For example, two files or data objects may have the same
substantially unique identifier, meaning that they contain the same
data. The single instancing system may compare the timestamp of the
first, previously stored, file or data object with that of the
second file or data object. If the timestamp of the second file or
data object is substantially newer than the timestamp of the first
file or data object, the single instancing system may nonetheless
store the second file or data object, even though it is duplicative
of a file or data object that is already stored.
[0096] In this context, substantially newer means that the age (as
determined by its timestamp) of the second file or data object is
less than the age of the first, previously stored, file or data
object by a certain amount or more (configurable by an
administrator). The single instancing system could then prune off
older versions as the data ages and is migrated to other storage,
such as longer-term storage. For example, a first file or data
object could have a timestamp indicating that its age is ten
months. A second file or data object could have a timestamp
indicating that its age is three months. If the administrator has
configured the amount to be six months, then the second file or
data object is substantially newer than the first file or data
object, because the age of the second file or data object is less
than the age of the first file or data object by more than the
configured amount. Therefore, the single instancing system would
store the second file or data object, and the first file or data
object could be migrated to longer-term storage, such as to
tape.
[0097] The single instancing system may be employed in any variety
of architectures. For example, it may be employed with
heterogeneous storage hardware, and thus is not reliant on a
specific hardware platform to perform all of the single instancing
functions. Instead, multiple, different data storage platforms may
be employed for storing data under the storage policies. Further,
the architecture may be tiered or federated wherein one server
manages multiple cells (and each of those cells in turn may manage
lower tier cells). In some embodiments, the cells may be arranged
in hierarchies or organized in configurations such as those
described in U.S. patent application Ser. No. 12/060,186, filed
Mar. 31, 2008, published as U.S. Patent Application Publication No.
2008-0250204 A1, the entirety of which is hereby incorporated
herein by reference.
[0098] The single instancing system may employ many other
functions. For example, it may employ content indexing agents to
index the content all data blocks. These content indexes may then
be searched to permit users to readily locate desired data objects.
Further details regarding content indexing may be found in U.S.
patent application Ser. No. 11/694,869, filed Mar. 30, 2007,
published as U.S. Patent Application Publication No. 2008-0091655
A1, the entirety of which is hereby incorporated herein by
reference.
[0099] FIG. 3B is a block diagram that illustrates components of a
content-aware de-duplication, or single-instancing, system 360,
according to certain embodiments of the invention. In general, the
de-duplication system 360, in certain embodiments, advantageously
utilizes knowledge of file content to improve the de-duplication
process by identifying the location(s) of files or data objects,
such as data blocks, that are eligible and/or should be considered
together for de-duplication.
[0100] In certain embodiments, the de-duplication system 360
provides an end-to-end, block-based and/or file-based
de-duplication system that can extend across multiple tiers of
secondary storage (including disk and tape) and/or encompass
reduction of stored data across multiple backups, archives, clients
and/or platforms. Embodiments of the de-duplication system 360
further employ application-aware or content-aware de-duplication
processes to more accurately find and reduce common patterns in
data across disparate applications, operating systems, file systems
and/or data types.
[0101] As illustrated, the content-aware de-duplication system 360
comprises a de-duplication manager 362 that performs de-duplication
of data received from one or more client devices 364. In certain
embodiments, the de-duplication manager 362 can comprise the single
instancing system 100, or one or more components thereof. For
example, the de-duplication manager 362 can receive secondary
copies (e.g., backup, migration and/or archive copies) of data from
the client devices 364 and store at least portions of the secondary
copies on the storage device 366.
[0102] A de-duplication database 368 can utilize one or more tables
or other data structures to store substantially unique identifiers
of data objects (e.g., files, blocks) that have already been stored
on the storage device 366. If a copy or instance of a data object
received by the de-duplication manager 362 has already been stored
on the storage device 366, the de-duplication database 368 can be
used to avoid sending an additional copy of the same data to the
storage device 366. Examples of similar single instancing
configurations and methods usable with embodiments of the invention
are further disclosed in U.S. Provisional Patent Application No.
61/100,686, filed Sep. 26, 2008, which is hereby incorporated
herein by reference in its entirety.
[0103] As further illustrated by FIG. 3B, each of the clients 364
comprises one or more agents 370 operating thereon, or associated
therewith, for performing data and/or storage tasks related to the
corresponding client 364. In certain embodiments, the agents 370
are data agents configured to generate secondary copies of data
stored on, or accessible by, the corresponding client 364 for
storage on the storage device 366. For instance, in certain
embodiments, the agents 370 can advantageously be configured to
translate or convert data on the client devices 364 into a
particular backup format for facilitating de-duplication by the
de-duplication manager 362.
[0104] In certain further embodiments, the agents 370 comprise
application-specific, or content-aware, modules that are configured
to access and process one or more particular data formats and/or
data associated with a particular application. In certain
embodiments, the agents 370 are advantageously used to process data
within a database file, blob data and/or data encapsulated in
another data format. For instance, each agent 370 can be aware of
the various files, folders, registry files and/or system resources
that are impacted by a particular application. In certain
embodiments, different individual agents 370 may be designed to
handle MICROSOFT EXCHANGE data, SQL SERVER data, LOTUS NOTES data,
MICROSOFT WINDOWS 2000 file system data, SHAREPOINT data, and other
types of data.
[0105] In certain embodiments, multiple agents 370 may be treated
as separate agents even though they reside on the same client 364.
In other embodiments, the separate agents may be combined to form a
virtual agent for performing storage operations related to a
specific application. Also, although the agents 370 are illustrated
as executing on the client devices 364, it will be understood that
embodiments of the agents 370 can also be configured to remotely
access data stored on the client devices 364 through one or more
application programming interfaces (APIs), remote procedure calls
(RPCs) or the like.
[0106] In certain embodiments, the agent 370 is configured to
perform data management or storage operations in accordance with
one or more storage policies or other preferences. The storage
polices and/or preferences may include, but are not limited to,
information regarding storage locations, relationships between
system components, network pathways, retention policies, data
characteristics, compression or encryption requirements, preferred
system components, combinations of the same or the like.
[0107] In certain embodiments, each agent 370 can prepare the
secondary copy of the data to facilitate subsequent de-duplication
of data objects within the backup data. Such embodiments can
advantageously improve the speed of de-duplication since the
de-duplication preparation can be integrated with the normal backup
process and since the agents 370 can use knowledge of both specific
file formats of the client data and the de-duplication process
occurring on the back end of the de-duplication system 360.
[0108] In certain embodiments, the agent 370 identifies the
locations of data objects within a file that should be considered
for de-duplication. For instance, the agent 370 can indicate (e.g.,
via offsets) where the de-duplication manager 362 should start
and/or stop considering data for possible de-duplication.
[0109] For instance, suppose the agent 370 is instructed to process
the data file 210 (see FIG. 2), which was generated by an email
server, to be backed up. In certain embodiments, because the agent
370 is familiar with the data format and structure of the data file
210, which contains multiple email messages 230 and attachments 240
in multiple user mailboxes 220, the agent 370 can identify to the
de-duplication manager 362 where to begin within the data file 210
the de-duplication evaluation process.
[0110] For example, the agent 370 may insert one or more markers
within the data file 210 that identify location(s) where a data
object (e.g., the body of an email message, an attachment) begins
and/or ends. In certain embodiments, such identification
information can be advantageously used by the de-duplication
manager 362 to more quickly identify portions of one or more data
files that may be more likely to contain duplicate data (e.g.,
attachments between multiple email messages). In certain
embodiments, the marker can further identify the type of data
associated with the data object.
[0111] In embodiments of the invention that utilize block-level
de-duplication, the information inserted by the agent 370 can
advantageously assist the de-duplication manager 362 to know where
to begin the de-duplication comparison of data such that a higher
likelihood of detecting duplicate data is achieved. For instance,
the agent 370 can process metadata and/or other file information
regarding a particular data file to detect where logical or natural
divisions within the file should be identified (e.g., an offset of
a mail data file at which an attachment begins). As a result, it is
more likely that like blocks are detected since the de-duplication
manager 362 can proceed with its comparison and analysis of data
blocks in corresponding locations of the data.
[0112] For example, suppose two different email messages to be
backed up contain the same data object as an attachment, but the
bodies of the email messages differ in size. If a block-level
de-duplication manager 362 begins its comparison process at the
beginning of each email message by comparing set de-duplication
block sizes (e.g., 32 KB), the de-duplication manager 362 may not
detect a match of the attachments of the two email messages since
the attachments may be located at different offsets within the
respective email messages (e.g., 40 KB and 46 KB).
[0113] However, using the identifying information generated by the
agents 370, the de-duplication manager 362 can be instructed to
begin the block-level comparison at the respective offsets within
the two email messages whereat the particular attachments begin. As
a result, such embodiments can advantageously increase the
likelihood that duplicate data will be detected between data of
like files (e.g., generated from the same application).
[0114] Although the agent 370 has been described as processing
particular types of data (e.g., mail data), it will be understood
that other embodiments of the invention can be used with a variety
of different types of data and that different agents 370 can be
associated with the different types of data to identify possible
common duplicate data therein. For instance, a first agent can be
used to identify data objects within an EXCHANGE server data file,
while a second agent can be used to identify data objects within
file system data such that the de-duplication manager 362 can more
easily detect duplicate data objects between the two types of
data.
[0115] In yet other embodiments, the agent 370 can generate
substantially unique identifiers, as discussed above with respect
to FIG. 1, for one or more files or data objects to be backed
up.
[0116] FIG. 3C illustrates exemplary fields of a chunk file 380
usable with the de-duplication/single instancing systems disclosed
herein. In particular, the chunk file 380 can be used for
transmitting client data to be backed up or archived on one or more
storage devices. Moreover, the chunk file 380 can advantageously
comprise one or more file markers or other information added by one
or more content-aware agents 370 that identify data to be
considered for possible de-duplication. For exemplary purposes, the
chunk file 380 will be described with reference to the components
of the de-duplication system 360 of FIG. 3B.
[0117] The chunk file 380 includes a chunk header 382 comprising
metadata regarding the chunk file 380. The chunk file 380 further
comprises a plurality of tag headers 384 that are each associated
with a data payload 386 containing the actual data to be backed up.
In certain embodiments, each tag header 384 comprises metadata
(e.g., size, data type, or the like) regarding the data in the
corresponding payload section 386.
[0118] As shown, each of the tag headers 384 comprises a
de-duplication identifier 388. In certain embodiments, the
identifier 388 indicates whether or not one or more data objects
within the corresponding payload 386 should be considered for
de-duplication. For instance, in certain embodiments, the
identifier 388 comprises a single bit that indicates whether or not
the de-duplication manager 362 should consider the data of the
corresponding payload 386 for de-duplication.
[0119] In yet other embodiments, the identifier 388 can comprise a
file marker or other data structure that demarcates payload data
for possible de-duplication. For instance, the identifier 388 may
identify particular offsets within the payload 386 whereat the
de-duplication manager 362 should start and/or stop considering
data objects for de-duplication. In certain embodiments, the
identifier 388 can comprise a tag, a pointer, an index or table
entry, a flag, a bit, a header, combinations of the same or the
like.
[0120] In yet other embodiments, the identifier 388 can identify
data objects that can or cannot be single instanced with other data
objects (e.g., based on file types). In such embodiments,
identifiers 388 may indicate that data of a particular payload 386
should be considered for de-duplication with reference to a first
de-duplication database, while data of a second payload 386 should
be considered for de-duplication with reference to a second
de-duplication database.
[0121] In certain embodiments, the agent 370 inserts the identifier
388 in the chunk file 380. In certain embodiments, one or more
agents 370 can also separate data of different applications and/or
formats that should not be considered together for single
instancing into separate payloads (e.g., under different tag
headers) or separate chunk files.
[0122] Although FIG. 3C and the accompanying disclosure refer to
chunk files for transmitting data, other embodiments of the
invention can utilize different means or methods for transmitting
data in which data therein is selectively identified for possible
de-duplication. For instance, the agents 370 can be configured to
insert similar file markers, bits and/or other data structures in a
data stream being sent to the de-duplication manager 362 or other
de-duplication reader/listener for consideration for
de-duplication. In yet other embodiments, the described chunk file
380 can be used in archiving, migration, and/or other data storage
methods that generate secondary copies of data.
[0123] Determining Data Obiect Similarity
[0124] Various methods of determining if one file or data object is
similar (e.g., two instances of the same data) to another file or
data object will now be described. However, those of ordinary skill
in the art will recognize that many other methods besides those
described herein may be used to achieve similar results.
[0125] In some embodiments, the single instancing system determines
if two files or data objects are similar by performing a binary
comparison. For example, a first file or data object can be
compared byte by byte with a second file or data object, or
portions of the first file or data object can be compared with
portions of the second file or data object. If each byte of the
compared data in each file or data object matches, then the two
files or data objects are identical and therefore similar.
Otherwise, the two files or data objects do not match and are not
treated as similar.
[0126] In some embodiments, the single instancing system determines
if two files or data objects are similar by creating a digest or
fingerprint of the data contained in each file or data object. For
example, as storage operations are performed, the single instancing
system may perform a cryptographic hash on each file or data object
to create a digest of the file or data object. The single
instancing system compares the digest of the file or data object
with stored digests created for other files or data objects. If the
digests of two files or data objects match, then the single
instancing system may consider the files or data objects to be
identical. The single instancing system can use any suitable
hashing algorithm, such as SHA512. For applications that create
data files having embedded data objects, the single instancing
system identifies the embedded data objects, and determines the
similarity of each data object with other data objects found either
within the same data file or in other data files or stores managed
by the single instancing system.
[0127] FIGS. 4-6 are representative flow diagrams that depict
processes used in some embodiments. These flow diagrams do not show
all functions or exchanges of data, but instead they provide an
understanding of commands and data exchanged under the single
instancing system. Those skilled in the relevant art will recognize
that some functions or exchange of commands and data may be
repeated, varied, omitted, or supplemented, and other (less
important) aspects not shown may be readily implemented.
[0128] FIG. 4 is a flow diagram that illustrates the processing of
the storage operation manager component 160 of the single
instancing system in one embodiment. The storage operation manager
component 160 is invoked when a storage operation that creates a
copy of a file is requested (e.g., when backing up the application
file (block 400)). In block 410, the storage operation manager
component 160 identifies data objects within the file to be copied,
such as by using information about the application that created the
file and the format used by the application to store data
objects.
[0129] For example, the application may provide an object model
that the storage operation manager component 160 can invoke to
enumerate objects within the file, or the storage operation manager
component 160 may understand the format used by the application for
storing objects in the file. An application author, manufacturer or
third party may also provide a module for parsing the application
file that the storage operation manager component 160 can invoke.
In this way, the application author, manufacturer or third party
can provide access to the data objects within the file without
exposing the actual format used to third parties.
[0130] In certain embodiments, the storage operation manager
component 160 further identifies files or data objects from
different applications that should be considered separately for
de-duplication. For instance, the storage operation manager
component 160 can identify one or more files or data objects from a
first application or data format to be associated with a first
de-duplication database, while identifying one or more files or
data objects from a second application or data format to be
associated with a second de-duplication database. In yet other
embodiments, one or more agents 370 can perform one or more of the
functions described above with respect to blocks 400 and/or
410.
[0131] In block 415, the storage operation manager component 160
selects the first identified data object. In block 420, the storage
operation manager component 160 determines whether the data object
is unique, or if the storage manager component has previously
copied the data object. For example, the storage operation manager
component 160 may compute a digest in the manner described herein,
and compare the digest to the digests of previously copied data
objects to determine if the data object is an instance of a
previously copied data object. In decision block 430, if the data
object is unique, then the storage operation manager component 160
continues at block 450, else the storage operation manager
component 160 continues at block 440. In block 440, the storage
operation manager component 160 adds a reference (e.g., to an index
of data managed by the single instancing system, such as by
incrementing a reference count in the index) to the already backed
up instance of the data object, and then continues to block 460. In
block 450, the component stores the unique data object. In decision
block 460, if the storage operation manager component 160
identified more data objects within the file, then the storage
operation manager component 160 loops to block 415 to select the
next data object, else the storage operation manager component 160
completes.
[0132] FIG. 5 is a flow diagram that illustrates the processing of
the single instancing system to determine whether a file or data
object is unique, in one embodiment. These blocks may be invoked by
the storage operation component 160, such as when performing a
storage operation as described in FIG. 4 or at other times. In
block 510, the identifier generation component 120 generates a
substantially unique identifier of the file or data object that is
the target of the storage operation. In block 520, the file
identification component 110 gathers (for example, by querying the
file system of a client) additional information about the file or
data object, such as the file or data object's size, security
information, or other attributes. In block 530, the identifier
comparison component 130 determines if the substantially unique
identifier of the file or data object and any supplemental
information matches that of any existing file or data object
tracked by the single instance database component 140.
[0133] In decision block 540, if the data objects match, then the
single instancing system continues at block 550, otherwise the
single instancing system continues at block 570. In block 550, the
single instancing system reports to the entity that invoked the
storage operation manager component 160 that the file or data
object is not unique. In block 560, the single instancing system
updates the substantially unique identifier reference count tracked
by the single instance database component 140 and then concludes.
In block 570, the single instancing system reports to the entity
that invoked the storage operation manager component 160 that the
file or data object is unique. In block 580, the single instancing
system adds the file or data object's substantially unique
identifier and other information to the list of files and data
objects tracked by the single instance database component 140. The
process then concludes.
[0134] FIG. 6 is a flow diagram that illustrates the processing of
the storage operation manager component 160 to restore data, in one
embodiment. The single instancing system invokes the storage
operation manager component 160 when it receives a request, for
example, to restore data. In block 610, the storage operation
manager component 160 receives a request to restore data. In block
620, the storage operation manager component 160 selects the next
file or data object referred to by the request. For example, the
request may identify ten files or data objects, and the storage
operation manager component 160 selects the first file or data
object on which to perform the following blocks.
[0135] In decision block 630, if the selected file or data object
is a reference to an instance of a file or data object stored
somewhere else, then the storage operation manager component 160
continues at block 640, else the storage operation manager
component 160 continues at block 650. In block 640, the storage
operation manager component 160 locates the referenced instance of
the file or data object and continues to block 655. In block 655,
the storage operation manager component 160 restores the file or
data object from the referenced instance of the file or data
object. In block 650, the storage operation manager component 160
restores the file or data object directly from the file or data
object. In decision block 660, if there are more files or data
objects referred to by the received request, then the storage
operation manager component 160 loops to block 620 to select the
next file or data object on which to perform these blocks, else the
storage operation manager component 160 completes.
[0136] Single Instance Continuous Data Replication
[0137] Where multiple computing systems containing data that is to
be single instanced are located remotely from a single instancing
database, various system configurations may be employed to avoid
transferring data that is common to the remote multiple computing
systems to the single instancing database. Three example
configurations are described herein. Under a first configuration, a
single instancing database is maintained at a first location and at
each remote location (e.g., a second location, a third location,
etc.). De-duplicated information in the single instancing database
at each remote location is transferred to the single instancing
database at the first location.
[0138] Under a second configuration, a single instancing database
is maintained at a first location, and a computing system at each
remote location (e.g., a second location, a third location, etc.)
sends queries to the single instancing database at the first
location to identify what data to transfer to the single instancing
database. Under a third configuration, each computing system at
each remote location (e.g., a second location, a third location,
etc.) queries a single instancing database at a first location
before transferring any data to the single instancing database.
Each of these configurations is discussed separately below. In the
discussed configurations, the example of a central or home office
with one or more remote or satellite offices is used, where each
remote office includes one or more computing systems. Although the
terminology used to discuss these configurations implies a certain
geographical positioning of computing systems, the single
instancing system described herein may be used in a wide variety of
configurations and is not limited to a specific geographical
positioning.
[0139] Furthermore, the single instancing system described herein
is not limited to the hub-and-spoke model implied by the
terminology used to discuss these configurations. For example, a
multi-tier hierarchical configuration could be employed, in which
computing systems at the leaf nodes transfer data to computing
systems at their respective parent nodes, which transfer data to
computing systems at their parent nodes, and so on, up to the
computing system at the top-most node of the hierarchy. As another
example, a mesh configuration could be employed, in which a first
computing system in the mesh configuration transfers data to a
second computing system, the data to be ultimately transferred to a
third computing system.
[0140] CDR, also called continuous data protection or continuous
backup, refers to copying computer data by automatically saving a
copy of every change made to that data, essentially capturing every
version of the data that the user saves. It allows an administrator
(or other user) to restore data to previous point(s) in time. There
are multiple methods known in the art for capturing the continuous
changes involving different technologies that serve different
needs. CDR-based solutions can provide fine granularities of
restorable objects ranging from disk images to logical data objects
such as files, email data files, email messages, and database files
and logs.
[0141] CDR differs from traditional backup or copy operation in
that an administrator (or other user) does not have to specify the
point in time to which the administrator would like to recover
until the administrator is ready to perform a restore. Traditional
backups or copy operations can only restore data to the point at
which the backup or copy was made. With CDR, there are typically no
backup or copy schedules. When data is written to disk, it can also
be synchronously or asynchronously written to a second location,
usually another computer over the network. In some situations, CDR
will require less space on secondary storage media (usually disk)
than traditional backup or copy operations. Most CDR solutions save
byte- or block-level differences rather than file-level
differences. This means that if one byte of a 100 GB file is
changed, only the changed byte or block is backed up or copied. In
contrast, traditional incremental and differential backups and copy
operations generally make copies of entire files when those files
change.
[0142] FIG. 7 illustrates an environment according to the first
example configuration. In the environment of FIG. 7, two remote
offices 710a and 710b are connected to a home office 730. Although
FIG. 7 depicts two remote offices 710, only a single remote office,
or more than two remote offices, may be connected to the home
office 730. Each remote office includes its own single instance
database 740. For example, remote office 710a includes single
instance database 740a and remote office 720 includes single
instance database 740b. Multiple client computing systems 760a and
760b at each remote office 710 provide data to the single instance
database 740 at their respective locations.
[0143] Clients 760a are part of remote office 710a, and store data
in single instance database 740a. Clients 760b are part of remote
office 710b, and store data in single instance database 740b. The
clients 760 may be connected to their respective remote office 710
by way of a local area network (wired or wireless), with the remote
offices 710 being connected to the home office 730 by a wide area
network, or other network such as a public computer network (e.g.,
the Internet). By employing known CDR techniques, data from each
remote single instance database 740 is sent to the home office 730
to be stored in a central data store (not shown in FIG. 7) at the
home office 730. Accordingly, data is copied from clients 760 to a
local single instance database 740, and then data blocks unique to
that remote office 710 are provided using CDR to create a copy at
the home office 730.
[0144] Each remote office 710 tracks incremental changes for its
clients 760, and then employs CDR to transmit those incremental
changes to the home office 730. The home office 730 may then in
turn employ its own single instance database 790 to avoid any
duplication between the remote offices 710. For example, clients
760 that run MICROSOFT WINDOWS typically will each have a similar
C:\Windows directory containing operating system files. Multiple
client computing systems 760 will have stored a single copy of the
C:\Windows directory at the remote single instance database 740,
which will then be replicated to the central data store at the home
office 730. The home office 730 will in turn store a single copy of
the C:\Windows directory in the single instance database 790.
[0145] FIG. 8 is a flow diagram that illustrates copying a remote
file or data object in the environment of FIG. 7. In block 810, the
single instancing system receives a request to perform a storage
operation. For example, the request may be a routinely scheduled
request to backup or copy the contents of a client computing system
760. For each file or data object involved in the request, the
single instancing system performs the following blocks. In block
820, the single instancing system copies the file or data object
from the client computing system 760 to a single instance database
740 located at the remote office 710. The single instance database
740 ensures that only one copy of each file or data object is
stored.
[0146] For example, the single instance database 740 may create or
have created a substantially unique identifier for each stored file
or data object and create or have created a substantially unique
identifier for each new file or data object to be stored. The
single instance database 740 may then compare the substantially
unique identifier of the new file or data object with that of each
previously stored file or data object to determine whether the new
file or data object is already stored. In some embodiments, the
single instance database 740 may store metadata that is specific to
some clients while only storing one instance of the file or data
object itself.
[0147] Accordingly, the client 760 copies data to a computing
system that is geographically close, and then later the data from
each client 760 can be copied to the home office 730 by copying the
single instance or unique data from the single instance database
740 at the remote office 710. In this context, computing systems
that are geographically close refers to computing systems that may
be in the same room, in the same building or on the same campus.
Computing systems that are geographically remote refers to
computing systems that are not geographically close. In block 830,
the single instancing system replicates the contents of the remote
single instance database 740 to the home office 730. This block can
be performed using CDR or other traditional methods of copying
data. After block 830, these blocks conclude. Using this method,
each remote single instance database 740 may send identical files
or data objects to the home office single instance database 790
(i.e., data that is unique as to each individual remote office 710,
but duplicative as to both remote offices 710). However, only one
instance of each file or data object at the remote office 710 is
stored by the home office single instance database 790.
[0148] FIG. 9 illustrates an environment according to the second
example configuration. In the environment of FIG. 9, two remote
offices 910a and 910b are connected to a single home office 930.
Although FIG. 9 depicts two remote offices 910, only a single
remote office, or more than two remote offices, may be connected to
the home office 930. Remote office 910 includes multiple client
computing systems 960a and a data store 940a. Remote office 910b
includes multiple client computing systems 960b and a data store
940b. The home office 930 maintains a single instance database 990.
The remote office 910 generates a substantially unique identifier
for each file or data object that is to be potentially stored.
[0149] For example, the remote office 910 may include a computing
system (not shown in FIG. 9) that generates the substantially
unique identifier for each file or data object that is to be
potentially stored on behalf of clients 960. The remote office 910
then transmits the substantially unique identifier to the home
office 930. The home office 930 checks the single instancing
database 990 to determine whether the transmitted substantially
unique identifier matches any existing substantially unique
identifier in the single instance database 990 in order to
determine whether the file or data object that is to be potentially
stored is redundant. The home office 930 then sends a response back
to the remote office 910 that indicates whether the file or data
object that is to be potentially stored is unique. The remote
office 910 stores the unique files or data objects locally in a
data store 940. The remote office 910 then employs CDR to
incrementally transfer new changes or updates to the home office
930.
[0150] The single instancing system may employ various optimization
techniques. For example, the remote office 910 may cache
substantially unique identifiers and only transmit one instance of
a substantially unique identifier to the home office 930 if it
detects more than one instance of the same substantially unique
identifier. After the single instancing system has made a request
to the single instance database 990 to determine if a particular
file or data object is unique, the remote office 910 may cache the
response so that subsequent identical files or data objects do not
generate a new request to the single instance database 990. Rather,
the single instancing system consults the cache first to determine
if a previous request determined whether the file or data object is
unique. If the cache responds that the file or data object is not
unique, then the remote office 910 does not need to query the
single instance database 990 to determine if the file or data
object is unique.
[0151] FIG. 10 is a flow diagram that illustrates copying a remote
file or data object in the environment of FIG. 9. In block 1010,
the single instancing system receives a request to perform a
storage operation. For each file or other data object involved in
the request, the single instancing system performs the following
blocks. In block 1020, the single instancing system copies the file
or data object to a data management server (not shown in FIG. 9)
that caches files or data objects at the remote office 910. Thus,
the client copies data to a computing system that is geographically
close. The data management server in this method may contain
duplicate files or data objects from many clients 960. According to
this method the data management server does not do single
instancing of its own.
[0152] In block 1030, the single instancing system queries the
single instance database 990 at the home office 930 to determine
whether the single instance database 990 already has a copy of the
file or data object. In decision block 1040, if the file or data
object is new to the single instance database 990, then the single
instancing system continues at block 1050, else these blocks
conclude. In block 1050, the single instancing system copies the
new file or data object to the single instance database 990. If
there are duplicates of the file or data object, then later when
the single instance database 990 is queried for the duplicate files
or data objects, the single instance database 990 will indicate
that the file or data object is not new and need not be copied. In
this way, duplicate data is not sent to the home office 930. After
block 1050, these blocks conclude. This method differs from the
method of FIG. 8 in that duplicate data may be stored at the remote
office 910, but duplicate data is not sent to the home office 930.
In general, in comparison with the method of FIG. 8, the method of
FIG. 10 will send more queries to the home office 930, but less
data.
[0153] FIG. 11 illustrates an environment according to the third
example configuration. In the environment of FIG. 11, each remote
client 1160 (as opposed to each remote office 1110) transmits a
query with a substantially unique identifier to the home office
1130. Each client 1160 may have generated the substantially unique
identifier itself, or another computing system may generate them on
behalf of the clients 1160. The single instance database 1190
determines whether the substantially unique identifier is already
stored (i.e., indicating that the corresponding file or data object
has previously been stored) and transmits a response to the client
1160. If the response indicates that the file or data object is
new, then the client 1160 sends that file or data object to the
home office 1130. The single instancing system typically does not
employ CDR, and each remote office 1110 typically does not include
a local data store used by its clients 1160. The single instancing
system may employ caching for optimization at each client 1160. The
home office 1130 also uses a single instance database 1190 to store
only a single instance of each file or data object.
[0154] FIG. 12 is a flow diagram that illustrates copying a remote
file or data object in the environment of FIG. 11. In block 1210,
the single instancing system receives a request to perform a
storage operation. For each file or other data object involved in
the request, the single instancing system performs the following
blocks. In block 1220, the single instancing system queries the
single instance database 1190 at the home office 1130 to determine
whether the single instance database 1190 already has a copy of the
file or data object. In decision block 1230, if the file or data
object is new to the single instance database 1190, then the single
instancing system continues at block 1240, else these blocks
conclude. In block 1240, the single instancing system copies the
new file or data object directly from the client 1160 to the single
instance database 1190. In this way, duplicate data is not sent to
the home office 1130. After block 1240, these blocks conclude. This
method differs from the method of FIG. 10 in that the remote office
110 does not employ a remote file cache. Therefore, the method of
FIG. 12 results in the sending of additional queries from the
clients 1160 to the home office 1130 because each client 1160 will
query the single instance database 1190.
[0155] As shown in FIGS. 7-12, the single instancing system does
not always maintain a single instance database in the same
location. Various benefits are derived by maintaining a single
instance database in various locations. For example, a single
instance database may be maintained in a production environment
(for example, geographically close to production servers) so as to
reduce the amount of time needed to single instance data or to
reduce the amount of data to be transmitted between computing
systems. The data stored in the single instance database may then
be replicated to another single instance database or secondary
storage.
[0156] Conclusion
[0157] From the foregoing, it will be appreciated that specific
embodiments of the storage system have been described herein for
purposes of illustration, but that various modifications may be
made without deviating from the spirit and scope of the invention.
For example, although backup operations have been described, the
single instancing system may be used to reduce many types of
redundant storage operations. As one example, the storage system
may be employed by an Internet proxy server to reduce downloading
of redundant files over the Internet by tracking a digest of each
downloaded file and the location of a downloaded instance of the
file behind the proxy server such that subsequent requests for the
file can be serviced from the previously downloaded instance
without accessing the file over the Internet. Similarly, the
storage system could be used by a file system to reduce storage
space by storing a single copy of data placed in multiple locations
throughout the file system.
[0158] Unless the context clearly requires otherwise, throughout
the description and the claims, the words "comprise," "comprising,"
and the like are to be construed in an inclusive sense, as opposed
to an exclusive or exhaustive sense; that is to say, in the sense
of "including, but not limited to." The word "coupled", as
generally used herein, refers to two or more elements that may be
either directly connected, or connected by way of one or more
intermediate elements. Additionally, the words "herein," "above,"
"below," and words of similar import, when used in this
application, shall refer to this application as a whole and not to
any particular portions of this application. Where the context
permits, words in the above Detailed Description using the singular
or plural number may also include the plural or singular number
respectively. The word "or" in reference to a list of two or more
items, that word covers all of the following interpretations of the
word: any of the items in the list, all of the items in the list,
and any combination of the items in the list.
[0159] The above detailed description of embodiments of the
invention is not intended to be exhaustive or to limit the
invention to the precise form disclosed above. While specific
embodiments of, and examples for, the invention are described above
for illustrative purposes, various equivalent modifications are
possible within the scope of the invention, as those skilled in the
relevant art will recognize. For example, while processes or blocks
are presented in a given order, alternative embodiments may perform
routines having steps, or employ systems having blocks, in a
different order, and some processes or blocks may be deleted,
moved, added, subdivided, combined, and/or modified. Each of these
processes or blocks may be implemented in a variety of different
ways. Also, while processes or blocks are at times shown as being
performed in series, these processes or blocks may instead be
performed in parallel, or may be performed at different times.
[0160] The teachings of the invention provided herein can be
applied to other systems, not necessarily the system described
above. The elements and acts of the various embodiments described
above can be combined to provide further embodiments.
[0161] While certain embodiments of the inventions have been
described, these embodiments have been presented by way of example
only, and are not intended to limit the scope of the disclosure.
Indeed, the novel methods and systems described herein may be
embodied in a variety of other forms; furthermore, various
omissions, substitutions and changes in the form of the methods and
systems described herein may be made without departing from the
spirit of the disclosure. The accompanying claims and their
equivalents are intended to cover such forms or modifications as
would fall within the scope and spirit of the disclosure.
* * * * *