Abstract:
Performing a backup is disclosed. A first set of data associated with a second set of data is backed up. The first set of data is made available for use before backing up the second set of data. The second set of data is backed up within a prescribed interval after completing the backup of the first set of data. One of the first set of data and the second set data comprises metadata associated with the other of the first set of data and the second set of data and the other comprises one or more items of managed content.

Description:
BACKGROUND OF THE INVENTION 
   Some storage systems include multiple storage components that are required to be in a consistent state for proper operation of the storage system and/or an associated system, application, or process. For example, a managed content repository typically includes a content storage area in which user and/or application data, such as files, are stored and a database storage area containing metadata associated with user and/or application content in the content storage area. Traditionally, creating a consistent backup of related multiple storage areas required holding the multiple storage areas in a consistent state during a backup process, e.g., by preventing the data stored in the respective areas from being accessed, modified, deleted, added to, or otherwise used during at least a substantial portion of the backup process. Such an approach has been used, e.g., to prevent a situation in which data in a first storage area was no longer in a consistent state with corresponding data in a second storage area as backed up by the time the first storage area was backed up, e.g., because data was added, modified, or deleted in the period between the completion of the backup of one area and the backing up of the other. Since in the typical approach the multiple storage areas are rendered inaccessible while the backup is performed, users of the multiple storage areas incur inconvenience and loss of productivity. Therefore, there exists a need for a way to efficiently backup related multiple storage areas in a consistent state 

   
     BRIEF DESCRIPTION OF THE DRAWINGS  
     Various embodiments of the invention are disclosed in the following detailed description and the accompanying drawings. 
       FIG. 1  is a block diagram illustrating an embodiment of a backup environment. 
       FIG. 2  is a block diagram illustrating an embodiment of a content system. 
       FIG. 3  is a flow chart illustrating an embodiment of a process for performing a backup of a content system. 
       FIG. 4  is a block diagram illustrating an embodiment of a process for performing a backup of content system components. 
       FIG. 5  is a block diagram illustrating an embodiment of a process for restoring data. 
       FIG. 6  is a block diagram illustrating an embodiment of a process for displaying correlated backups. 
       FIG. 7  is a diagram of at least a portion of a display illustrating correlated component backups. 
       FIG. 8  is a flow chart illustrating an embodiment of a process for restoring a backup. 
   

   DETAILED DESCRIPTION  
   The invention can be implemented in numerous ways, including as a process, an apparatus, a system, a composition of matter, a computer readable medium such as a computer readable storage medium or a computer network wherein program instructions are sent over optical or electronic communication links. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. A component such as a processor or a memory described as being configured to perform a task includes both a general component that is temporarily configured to perform the task at a given time or a specific component that is manufactured to perform the task. In general, the order of the steps of disclosed processes may be altered within the scope of the invention. 
   A detailed description of one or more embodiments of the invention is provided below along with accompanying figures that illustrate the principles of the invention. The invention is described in connection with such embodiments, but the invention is not limited to any embodiment. The scope of the invention is limited only by the claims and the invention encompasses numerous alternatives, modifications and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the invention. These details are provided for the purpose of example and the invention may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the invention is not unnecessarily obscured. 
   Consistent backup of components of a managed content repository is disclosed. In some embodiments, loss of availability of content management functionality is minimized by limiting update access to at least one component and associated functionality, e.g., metadata used to manage underlying content data comprising a body of managed content, only to the extent and for as long as required to back up data associated with the at least one component in an internally consistent and/or settled state, with the at least one component coming back on line before a backup of one or more other components has been performed and/or completed. 
     FIG. 1  is a block diagram illustrating an embodiment of a backup environment. Content system  102 , backup server  104 , client  108 , and backup administrator console  110  are connected together through network  106 . Network  106  comprises a public or private network and/or combination thereof, for example an Ethernet, serial/parallel bus, intranet, Internet, NAS, SAN, LAN, WAN, and other forms of connecting multiple systems and/or groups of systems together. Client  108  accesses data associated with content system  102 . For example, client  108  reads, saves, modifies, and/or searches data stored in a storage area associated with content system  102 . Content system  102  is associated with data to be backed up using backup server  104 . In some cases, client  108  desires to access the data to be backed up while a backup of the data in content system  102  is being performed. The data associated with content system  102  is stored one or more storage areas of content system  102  and/or on a remote storage area associated with content system  102 . In some embodiments, the data to be backed up includes managed content that must be backed up in a consistent manner with metadata associated with the managed content. Backup server  104  backups at least a portion of data associated with content system  102 . Data to be backed up from content system  102  is received by backup server through network  106  and/or another data communication path between backup server  104  and content system  102 . For example, a SAN (storage area network) between backup server  104  and content system  102  is used. Backup admin console  110  is used configure backup server  104 . In some embodiments, backup admin console  110  and client  108  exist together in a single system. In some embodiments, backup server  104  and content system  102  exist together in a system. Any number of backup servers, contents systems, backup admin consoles, and clients may exist. 
     FIG. 2  is a block diagram illustrating an embodiment of a content system. In some embodiments, content system  200  is included in content system  102  of  FIG. 1 . Content system  200  includes content server  202 , FTI (Full Text Index)  204 , DB (Database)  206 , and SA (Storage Area content)  208 . Content server  202  manages/controls access, configuration, and data contained in FTI  204 , DB  206  and SA  208 . Content server  202  may manage other storage in content system  200  or a remote storage not contained in content system  200 . SA  208  includes one or more data files stored in a file system. For example, content files (e.g, word processing documents) created by a user are stored in SA  208 . In some embodiments, SA  208  comprises multiple physical storage area that are logically combined together. In various embodiments, data versioning information is stored in SA  208 . For example, when a new version of an old file is stored, the new version is saved as a new file rather than replacing the old version. DB  206  includes metadata associated with data stored in SA  208 . The metadata includes one or more of the following: document version information, document owner information, and folder and directory information. In the example shown, information associated with DB  206  is at least in part stored in a database format. A database entry includes metadata information and an identifier associated with corresponding data in SA  206 . In some embodiments, metadata associated with data in SA  208  is at least in part stored in a format other than a database. For example, an index data and/or a log data is used. FTI  204  includes an index of at least a portion of data contained in SA  208 . FTI  204  can be used to locate data in SA  208  through a search query. For example, a search engine uses index data of FTI  204  to locate desired data in SA  208 . In some embodiments, data in SA  208  is indexed to create/update search data associated with FTI  204 . In some embodiments, FTI  204  is not implemented in content system  200 . In various embodiments, content system  200  includes other logical and/or physical storage components. For example, install and configuration data is associated with content system  200 . In some embodiments, at least a portion of FTI  204 , DB  206 , and/or SA  208  is stored together in a single physical file system. In some embodiments, FTI  204 , DB  206 , and/or SA  208  is stored across more than one physical storage. 
   Traditionally, backing up content system  200  requires placing content system  200  offline in order to guarantee content system  200  is in a consistent state for backup. For example, if backup of content server  202  was performed without any guarantee of consistency, a backup of DB  206  can include a reference to a data that a related backup of SA  208  does not contain because the reference was created in between the backup of the SA 208  and the backup of DB  206 . While content system  200  is offline, users are unable to access content system  200  until the backup is complete and content system  200  placed back online. When traditionally performing the backup, FTI  204 , DB  206 , and SA  208  are manually backed up individually. Performing the individual manual component backups can be tedious, especially to devise a workload to continually achieve efficient backup performance. When restoring data from backup, it can be difficult browse, unify, and/or correlate the separate backups of the components. Attempting to restore only a portion of data in the backups can pose challenges of locating relevant data in the various backup components. It is desirable for a process of backing up content system  200  to be automated, efficient, consistent, and configurable while being transparent to a user of the system. 
     FIG. 3  is a flow chart illustrating an embodiment of a process for performing a backup of a content system. In some embodiments, the content system includes content system  200  of  FIG. 2 . At  302 , configuration preferences are received. Receiving configuration preferences may include one or more of the following: accessing a configuration file, using a predetermined default configuration for an unspecified configuration, using a system configuration data, and accepting command-line input from a user and/or an administrator for a configuration. Examples of configurations include one or more of the following: source data configuration, destination backup data configuration, system configuration, user access configuration, backup consistency configuration, security configuration, and specification of one or more backup tools/utilities/scripts. At  304 , an indication of a backup to be performed is received. In some embodiments, the indication includes a specification of a portion of data to be backed up in a content system. For example, only content data associated with a specific storage area is specified for backup. In some embodiments, the specification of data to be backed up is specified using configuration preferences. In various embodiments, the indication includes a request for initiation of a backup process. The backup may be performed periodically, on a prescribed basis, and/or substantially concurrent with a received indication. At  306 , a live backup of content system components is performed in a manner that enables the system to be restored in a consistent state. In some embodiments, the live backup is performed in accordance with the received configuration parameters. In some embodiments, a component backup is performed as a snapshot backup that does not require traversal of a directory structure associated with the component. In some embodiments, a component backup is performed as a direct file copy. In some embodiments, a component backup can be performed using one or more various backup methods. Performing the live backup does not render the content system inaccessible by a user for the entire backup process. In some embodiments, restoring data to a consistent state includes restoring data to the system in a state recoverable by the system. For example, a content system is restored to a consistent state even if the system contains an inconsistency when the inconsistency is known by the system, the inconsistency is tolerated by the system, the inconsistency is recoverable by the system, and/or the inconsistency will not cause an error in the system. The inconsistency, in some embodiments, is tolerated if the inconsistency was generated within a specified amount of time in between component backups during a backup session. 
     FIG. 4  is a block diagram illustrating an embodiment of a process for performing a backup of content system components. In some embodiments, the process of  FIG. 4  is included in  306  of  FIG. 3 . At  402 , FTI component is quiesced. In some embodiments, the FTI component is FTI  204  of  FIG. 2 . Quiescing a component includes preparing the component for creating a consistent backup state. For example, updates are not allowed to the component but reads are allowed. In some embodiments, quiescing is associated with performing one or more operations to ensure intra-component consistency. In some embodiments quiescing a storage component includes performing one or more following: flushing one or more buffers associated with the storage component, disabling updates to the component, and logging transactions associated with the component. In various embodiments, the type of operations associated with performing quiescing is configurable. For example, configuration parameters in  302  of  FIG. 3  may specify the type of operations and/or configuration associated with the operations performed during quiescing. At  404 , SA component is quiesced. In some embodiments, the SA component is SA  208  of  FIG. 2 . At  406 , the FTI component is backed up. In various embodiments, the type of backup method used to back up the FTI component is configurable and/or specified by configuration preference in  302  of  FIG. 3 . At  408 , DB component is quiesced. In some embodiments, the DB component is DB  206  of  FIG. 2 . At  410 , DB component is backed up. In various embodiments, the type of backup method used to back up the DB component is configurable and/or specified by configuration preference in  302  of  FIG. 3 . In some embodiments, a database backup tool/utility/script is used to perform the DB backup. The database backup utility may be a third party backup database utility. At  412 , DB component is unquiesced. In some embodiments, unquiescing a component includes performing one or more of the following: re-enabling updates, ending hot backup transaction logging, and implementing changes requested to the component while quiesced. At  414 , the SA component is backed up. In various embodiments, the type of backup method used to back up the SA component is configurable and/or specified by configuration preference in  302  of  FIG. 3 . In some embodiments, the SA component backup is initiated within a prescribed or indicated amount of time from unquiescing the DB component. The time constraint may guarantee a tolerable level of consistency in the created backup of the components. At  416 , the SA component is unquiesced. At  418 , the FTI component is unquiesced. 
   In some embodiments, at least a portion of the order of the process of  FIG. 4  is important in ensuring the backup is created in a consistent state. For example, in a consistent backup, the SA component backup may contain data not referenced by the DB component backup, but the DB component backup may not reference data not contained in the SA component backup. To ensure such a consistency, the DB component must be backed up before the SA component. In some embodiments, the DB backup is initiated after the FTI backup. In such a case, data associated with the FTI backup will only reference data referenced by metadata in the DB backup. The order of the backup process, in some embodiments, is dependent upon one or more characteristics of a storage component and/or a content system. In various embodiments, amount of time between and/or taken during the process portions of  FIG. 4  is important in ensuring the backup is created in a consistent state. For example, the backup of the SA component must be initiated within the de-facto standard five minutes after the unquiescing of the DB component to ensure the amount of data present in the SA component backup not referenced by the DB component backup is within a tolerated level. The order of process portions shown in  FIG. 4  is merely an example. Various ordering that guarantees consistency in the created backup exists. In some embodiments, the FTI is unquiesced after the SA component is backed up 
     FIG. 5  is a block diagram illustrating an embodiment of a process for restoring data. In some embodiments, the data is restored to content system  200  of  FIG. 2  using component backups created at least in part using the process of  FIG. 4 . At  502 , an indication of a desired recovery is received. In some embodiments, the indication includes initialization of a backup restore process. At  504 , available backup/restore points are displayed and/or determined. In some embodiments, the backup/restore points include one or more groups of related backups. For example, a restore point includes a FTI, a DB, and a SA component backups associated with a singe backup session. In various embodiments, the backup/restore points are organized by backup creation times. At  506 , a selection of a backup/restore point to be restored is received. In some embodiments, the selection is automatic. For example, when a user specifies a time of a desired restore point, a backup/restore point is automatically determined. At  508 , the selected backup/restore point is restored. In some embodiments, only a portion of data associated with a restore point is selected and restored. 
     FIG. 6  is a block diagram illustrating an embodiment of a process for displaying correlated backups. In some embodiments, the process of  FIG. 6  is included in  504  of  FIG. 5 . At  602 , a time frame is determined. In some embodiments, determining the time frame includes determining a time value and/or a range of time values. In various embodiments, the time frame is user defined and/or predetermined. At  604 , component backups from the time frame are determined. In some embodiments, determining the component backups includes locating one or more component backups created in the determined time frame. At  606 , the determined component backups are correlated. In some embodiments, correlating the component backups include associating together related backups and/or component backups created in the same backup session. The backup component correlation can be preprocessed and/or performed during backup recovery. For example, while component backups are created (e.g., the process of  FIG. 4 ), the component backups are stored together with metadata correlating the component backups. Examples of the correlation metadata include one or more of the following: a unique point-in-time backup timestamp, a list of related component backup instances, pointers to a backup storage index, and backup/restore parameter settings. This correlation metadata can be used when restoring component backups to determine correlated component backups. At  608 , the correlated backups are displayed as a related set. In some embodiments, at least a portion of information associated with the displayed set and/or data contained in a component backup of the displayed set is browseable by a user. 
     FIG. 7  is a diagram of at least a portion of a display illustrating correlated component backups. In some embodiments, display portion  700  is associated with the display in  504  of  FIG. 5  and/or  608  of  FIG. 6 . In the display example shown, display portion  700  includes two sets of correlated component backups. Component backups are correlated by backup sessions. The backup sessions are associated with a timestamp indicating a backup session creation time. The session listings include a listing of a FTI backup instance, a DB backup instance, and a SA backup instance. Each listing of the component instance may include a display of component backup creation time and/or other data associated with the component backup. In some embodiments, correlated component backups are displayed using a command line prompt. In some embodiments, at least a portion of data contained in a listed component backup can be displayed by selecting the listed component backup. 
     FIG. 8  is a flow chart illustrating an embodiment of a process for restoring a backup. In some embodiments, the process of  FIG. 8  is included in  508  of  FIG. 5 . At  802 , a first component is restored. Restoring a first component includes using a component backup to restore the first component to a specified restore point. At  804 , if it is determined that not all components have been restored, at  806 , a next component is restored, and the process returns to  804 . At  804 , if it is determined that all components have been restored, at  810 , process ends. The order of the component restoration may be preconfigured, specified by a configuration, or dependent upon characteristics of the components and/or a system associated with the components. 
   Although the foregoing embodiments have been described in some detail for purposes of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways of implementing the invention. The disclosed embodiments are illustrative and not restrictive.