Method for restoring data from a monolithic backup

A computer system and methods for restoring data from a copy of a database file. The method includes receiving a request to restore an item from the copy of the database file. The item includes a file and associated context information describing the file in a first intranet portal application environment. The method further includes retrieving a schema including the item from the copy of the database file and generating an item file comprising a copy of the file. The item file is independent of the context information. The method further includes generating a metadata file based on the context information, associating the metadata file with the item file, storing the item file and associated metadata file in a file system, and restoring the item to a second intranet portal application or to a third application via the file system.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to the field of computer processing and, more particularly, to restoring electronic documents.

2. Description of the Related Art

As computer memory storage and data bandwidth increase, so does the amount and complexity of data that business and industry manage each day. A large portion of the data that must be managed in an enterprise involves content managed for a company or workgroup by a dedicated server, such as an enterprise information portal, which provides employees and customers the ability to search and access corporate information, including electronic documents, announcements, task, discussion topic, etc., that may be organized as lists of items. The enterprise information portal can serve as the single gateway to log into the corporate network and retrieve electronic documents. It is noted that enterprise information portals are typically secure and private (also known as intranet portals), but also may include external gateways for wider or even public access.

An enterprise information portal often includes a back-end database system, which may server as a document management system. The back-end database system can store data in the form of electronic documents, metadata and other content associated with the portal, such as web pages. The back-end database in an enterprise information portal can be a variant of a stand-alone database system, which has been configured for document and content management.

Because electronic documents frequently contain crucial information, the contents of electronic document servers (e.g., an enterprise information portal along with its back-end database) may be archived, or backed up, to an archival storage to prevent loss or corruption of data. In particular, a back-end database is often backed up as a single, monolithic database file, which contains all the tables, records, and indexing information for the database.

When a user wants to restore one or more items or lists to the portal, the single database file may be reinstalled as a target of the portal. Unfortunately, reinstallation of a large, monolithic database may be time-consuming and inefficient when restoration of only a small number of items or lists is desired. There may also be occasions when a user desires the portal to be able to access an item in a raw file format rather than as a portal item or list. In addition, there may be occasions when a user desires to have an application other than the portal access an electronic document, announcement, task, discussion topic, etc.

Thus it would be desirable to restore individual data objects from an archived database file without having to reinstall the database system and in a format that is accessible to either an enterprise information portal or another application.

SUMMARY OF THE INVENTION

Various embodiments of a computer system and methods for restoring data from an archived copy of a database file are disclosed. In one embodiment, the method includes receiving a request to restore an item from the archived copy of the database file. The item comprises a file and associated context information describing the file in an environment that is specific to a first intranet portal application. The method further includes retrieving a schema including the item from the archived copy of the database file and generating an item file comprising a copy of the file. The item file is independent of the context information. The method further includes generating a metadata file based on the context information, associating the metadata file with the item file, and storing the item file and the associated metadata file in a file system. The method further includes restoring the item to a second intranet portal application via the file system.

In a further embodiment, the first and second intranet portal applications are the same application. In another embodiment, the method further includes redirecting the file to a third application directly through the file system without accessing the context information. In this and other embodiments, the third application is different from the first and the second applications.

In a still further embodiment, the context information comprises one or more file attributes. For each file attribute, the metadata file includes a corresponding tagged element. In some embodiments, the element tags conform to the Collaborative Application Markup Language (CAML). In yet another embodiment, the item comprises an electronic document.

In yet another embodiment, the method further includes receiving a request to restore a list comprising two or more items from the archived copy of the database file. The list includes files all having the same file type. Each file is associated with context information describing the file in an environment that is specific to the first intranet portal application. The method further includes retrieving a list schema that includes the items from the archived copy of the database file. For each item in the list, the method further includes generating an item file comprising a copy of the file. The item file is independent of the context information. For each item in the list, the method further includes generating a metadata file based on the context information, associating the metadata file with the item file, and storing the item file and the associated metadata file in a file system. The method further includes restoring the list to a second intranet portal application via the file system.

DETAILED DESCRIPTION

FIG. 1is a generalized block diagram of one embodiment of a computer system100. Computer system100includes a processor160coupled to a main memory110. Processor160and main memory110are in turn connected to an I/O subsystem150, which comprises an I/O interface155, a hard disk drive151, a network interface152, and a removable storage153. Computer system100may be representative of a laptop, desktop, server, workstation, terminal, personal digital assistant (PDA) or any other type of computer system.

Processor160is representative of any of various types of processors such as an x86 processor, a PowerPC processor or a SPARC processor. Similarly, main memory110is representative of any of various types of memory, including DRAM, SRAM, EDO RAM, Rambus RAM, etc.

I/O interface150is operational to transfer data between processor160and/or main memory110and one or more internal or external components such as hard disk drive151, network interface152and removable storage153, as desired. For example, I/O interface155may embody a PCI bridge operable to transfer data from processor160and/or main memory110to one or more PCI devices. I/O interface155may additionally or alternatively provide an interface to devices of other types, such as SCSI devices and/or Fibre channel devices.

Hard disk drive151may be a non-volatile memory such as a magnetic media. Network interface155may be any type of network adapter, such as Ethernet, fiber optic, or coaxial adapters. Removable storage153is representative of a disk drive, optical media drive, tape drive, or other type of storage media, as desired.

In addition to the depicted hardware components, computer system100may additionally include various software components. For example,FIG. 1illustrates an operating system115stored in main memory110. Operating system115is representative of any of a variety of specific operating systems, such as, for example, Microsoft Windows, Linux, or Sun Solaris. As such, operating system115may be operable to provide various services to the end user and provide a software framework operable to support the execution of various programs such as an Intranet Portal application120, a backup application140or any of a variety of other applications represented in the illustrated embodiment by application130. It is noted that the depicted software components ofFIG. 1may be paged in and out of main memory110in a conventional manner from a storage medium such as hard drive151.

In various embodiments, intranet portal120is operable to manage and maintain a plurality of electronic documents for a plurality of system users. In one particular implementation, intranet portal120is embodied by a Microsoft SharePoint Server or a similar enterprise information portal program.

Turning now toFIG. 2, a block diagram of one embodiment of a backup system200is illustrated. Backup system200includes intranet portal120, application130, and backup application140that may be included in computer system100ofFIG. 1. Backup system200also includes a file system220that may be stored within hard drive151, removable storage153, or otherwise employed by computer system100for data storage. As referred to herein, a “file system” shall mean an information system which references and stores data, hierarchically organized in files and directories, in a volume created on a storage medium. The file system provides access to the data on the storage medium. Backup system200may further include a backup medium250coupled to backup application140that may be used by backup application140to store backup datasets.

In one embodiment, intranet portal120may manage and organize electronic content as items within lists. As referred to herein, an “item” shall mean a document, announcement, task, discussion topic, or other electronic content that is managed by an intranet portal and a “list” shall mean a logical group of items. In the illustrated embodiment, intranet portal120includes lists230and240. List230includes items231-234and list240includes items241-243. In the illustrated embodiment, intranet portal120may also include an encapsulated version of a database210for storing lists and items. In one embodiment, intranet portal120may be configured to be the ‘user’ of database210. In one specific implementation, database210is embodied by Microsoft SQL Server or a similar database server system. It is further noted that one or more client computers (not shown inFIG. 1) may be coupled via network to computer system100. The client systems may access the intranet portal120centrally via one or more web pages, including access to database210.

Database210represents both a database program and one or more actual databases implemented therein (not shown inFIG. 2). The database program refers to the executable commands, user interfaces and other program code for operating database210. The databases included in database210may further include various tables, indexes, relationships, queries, stored procedures, file systems, security layers, networking interfaces, etc., which are configured to operate on a plurality of data records, also referred to as records or entries, that constitute the “database.” In one embodiment in which database210is a relational database, the records are arranged in tables (row and column arrangement). The term “record” as used herein shall refer to an entry in a database. A collection of associated records may be collectively described as a “table” in the database. A record may consist of one or more fields, which may serve as indexes (or keys) to other records in other tables. For example, in a document management database, each record in a document table may represent a document (or data object) stored in the database. In one embodiment, the document (data object) may be stored in the fields of the record itself. In some embodiments, the document (data object) is represented in a record by a reference to the document, such as a memory location. In addition, database210may create and modify a mounted database file (not shown inFIG. 2) for storing and accessing any given implementation of a relational database. In some embodiments, database210executes on a dedicated computing system that is configured for access by other server and client computers via a communications network.

In particular, database210is shown inFIG. 2to include two functions, query214and add212. These functions are shown as an example of functionality included within a relational database. In various embodiments, other kinds of functions, store procedures, or programs may be executed in a relational database. The query function214represents a function used to retrieve information from database210, whereas the add function212represents a function to store information in database210. It is noted that the query214and212functions may operate on data related to the relational database program or on data from any of the databases implemented therewith in a given instance of database210. The query function214may be accessed via interface281, while the add function is shown with access via interface282. For example, as shown intranet portal120may query database214via interface281to retrieve one or more of items231-234in list230. Further, intranet portal120may access add function212via interface282to store in database214one or more of items241-244of list240. The interfaces281and282may include a local or remote network interface, and may also include network and/or software driver layers for communicating with database210. In one embodiment, interfaces281and282provide access to database210using SQL (Structured Query Language).

Backup system200is operable to perform a backup of content managed by intranet portal120and stored in database210. In particular, backup application140may include a backup function142that may communicate with database210via interface283for selecting and retrieving content for archiving. Backup function142may generate a schema of table and index information along with the backed up contents of a database and store the generated schema to a database copy260on backup medium250via interface284. As used herein, “schema” refers to the data structure of a database file. It is noted that the database copy260may be an identical instance of a database file (not shown inFIG. 2) previously created by database210. In one embodiment, database copy260is a binary file that is sequentially accessed, using standard file I/O calls to the file system of the storage medium on which the binary file is stored. It is further noted that database copy260may be structured in block units of memory, also referred to as pages or allocation units. The schema may then be used to access or restore the contents of database copy260, without using database210. Backup medium250represents any of a variety of storage media including removable media, network attached storage, etc. (or any other type of archive storage). In various embodiments, interfaces283and284may include a network connection along with the necessary network and software drivers, as previously mentioned.

Additionally, backup application140may include a restore function144that can read specific documents from database copy260via interface291and add them to file system220via interface292. Various embodiments of methods for restoring documents from a database file are described in a U.S. patent application Ser. No. 11/551,018, entitled “METHOD FOR RESTORING DOCUMENTS FROM A DATABASE FILE,” the entirety of which is incorporated herein by reference. The restore function may also include a means for selecting one or more documents for restoration. In one embodiment, a user interface for selecting and restoring documents is provided with the restore function144as described further below. In various embodiments, backup system200is further operable to direct specific documents that have been restored to file system220either to database210via interface293or to application130via interface294according to a process that is described further below. Backup application140may also be configured to provide other known archiving functionality, as desired, such as various features provided by the Enterprise Vault™ or Backup Exec™ products from Veritas.

Turning now toFIG. 3, one embodiment of user interface300that may be presented by backup application140for selecting specific lists or items to be restored is illustrated. Interface300may include features such as drop-down menus, a navigation bar, an address field, and so on. Within interface300are shown a “Lists” pane301and a “Restore Items” pane303. Within Lists pane301, a hierarchy of lists and items may be seen and navigated. The illustrated hierarchy includes lists310,320,330,340, and350. List310includes items311-314. List350includes items351-355. Lists and items may be selected as indicated by a highlighted background and added to Restore Items pane303via an Add button. Restore Items pane303includes a restore folder360that includes items314and351to be restored. Lists and items may be selected and removed from Restore Items pane303via a Remove button. Restore Items pane303also includes a Restore button and a Clear button. Once a set of restore items has been selected, restoration may proceed. If the Restore button is selected, the items listed in Restore Items pane303may be added to a file system where they may be accessed by various applications. If the Clear button is selected, the items listed in the Restore Items pane are removed from the pane.

It is noted that the naming conventions depicted inFIG. 3(e.g., “List310”, “Item311”, etc.) are provided for ease of discussion. In a typical embodiment, names reflective of those used in ordinary business or other environments (e.g., Documents, Spreadsheets, Tasks, Discussion Topics, as well as user-defined list and/or items names, etc.) may be used, as desired.

Once a set of items and/or lists has been selected to be restored to the file system, restore function144may perform retrieval and formatting operations that enable various applications to access the retrieved lists/items.FIG. 4is a block diagram illustrating the operation of one embodiment of restore function144. In the illustrated embodiment, restore function144includes a metadata generator440that is coupled to and operable to retrieve records from database copy260via interface291. Metadata generator440is further coupled to and operable to store files within file system220via interface292.

In the example shown, database copy260includes records410,420, and430that represent any number of stored database records. Each record may include one or more data objects. In the example shown, record410includes data objects411-414, record420includes data objects421-424, and record430includes data objects431-435. For each item that it stores in file system220, metadata generator440may store an item file and a corresponding metadata file. For example, in the illustrated example, file system220includes item files451,453, and455and associated metadata files452,454, and456, respectively.

In one embodiment, metadata files generated by metadata generator440may be formatted in Collaborative Application Markup Language (CAML). CAML, as used herein, refers to an XML-based markup language that includes specific groups of tags that may be used by intranet portal applications to both define and display data objects. More particularly, during operation, metadata generator may use interface291to retrieve a record that corresponds to a requested item, identifying attributes of the item that are also stored in the record. Metadata generator440may extract the item from the record and generate an item file comprising the item stored in a raw or well-known file format that may be commonly understood by various software programs such as a .txt text file, a .jpg or .gif image file, etc. In addition, metadata generator440may generate an associated CAML element with appropriate tags for each item attribute that is found. Metadata generator440may store the tagged attributes in a metadata file that is associated with the item file. Metadata generator440may then use interface292to store the item or list and associated metadata as associated files in file system220.

Once an item file and an associated metadata file have been stored in file system220, they may be accessed by intranet portal application120, application130, or another application as follows. Since the attributes that are described in an item's associated metadata file originated from an intranet portal application, they describe the intranet portal environment sufficiently to enable restoration of the item to a similar environment in an intranet portal. Thus, intranet portal120may retrieve items from file system220via interface293including accessing an item's associated metadata file to retrieve sufficient environmental information to restore the item to the intranet portal environment. Alternatively, another application such as application130may ignore an item's associated metadata file and access the file item directly via interface294in a raw or well-known file format. Accordingly, by providing an item file for each item, various types of items may be redirected from there original environment in a copy of a database used by an intranet portal to any other application environment that can access files in a file system.

FIG. 5illustrates one embodiment of a process500that may be used to restore or redirect items from a backup copy of a database used by an intranet portal application. Process500may begin with recovery of a backup dataset from a copy of a database (block510). For example, a dataset that has been stored as a backup copy of a database used by an intranet portal application to store lists and items may be recovered to a temporary location. A user may then be presented with a browsable view of the recovered dataset (block520), such as the graphical user interface illustrated inFIG. 3. A user may browse the view of the recovered dataset and select items to be restored. A request to restore the user's selected items may be received (block530). In response to the request, for each selected item (decision block535) a raw file form of the item may be reconstructed from the backup dataset using a well-know file format (block540). In one embodiment, the well-know format files may be referred to as item files. In addition, a metadata file may be generated that includes a tagged entry for each attribute that is stored in the recovered dataset and associated with the selected item (block550). The metadata file describes the items in the database schema from which the backup copy was taken; for example, the schema may describe the item in the environment of the intranet portal application. Both the item file and the associated metadata file may then be stored in the file system (block560). Once item files and metadata files have been created for each selected item (decision block565), if the request is a request to restore the item or items to the environment of the intranet portal application (decision block570), the information in the metadata file associated with each item file may be used to restore the item to the intranet portal application environment (block580), completing process500. It is noted that the metadata file information may use a standard markup language format that is well-know to intranet portal applications, such as CAML, so that the metadata file information be alternatively be used to enter the item as a new item in a different intranet portal application environment or the environment of a different instance of the same intranet portal application. In addition, if the request is not a request to restore the item or items to the environment of the intranet portal application (decision block570), the item may be re-directed for use by another application that has access to the file system and therefore to item files in raw or well-known file format (block590), completing process500.

FIG. 6illustrates a more detailed embodiment of a sub-process550of process500that may be used to generate a metadata file for an item stored in a backup copy of a database used by an intranet portal application. Sub-process550may begin with identification of a selected item in a recovered dataset (block610), such as through the GUI illustrated inFIG. 3. Once an item has been identified, its schema in the recovered dataset may be examined to identify associated attributes of the item (block620). For each attribute (decision block630), a tag may be added to the attribute (block640) and the tagged attribute stored in a metadata file associated with the item (block650). Once all the identified item attributes have been tagged and added to the metadata file (decision block660), sub-process550is complete.

It is noted that the foregoing flow charts are for purposes of discussion only. In alternative embodiments, the elements depicted in the flow charts may occur in a different order, or in some cases concurrently. Additionally, some of the flow chart elements may not be present in various embodiments, or may be combined with other elements. All such alternatives are contemplated.

It is further noted that the above-described embodiments may comprise software. In such an embodiment, the program instructions that implement the methods and/or mechanisms may be conveyed or stored on a computer readable medium. Numerous types of media which are configured to store program instructions are available and include hard disks, floppy disks, CD-ROM, DVD, flash memory, Programmable ROMs (PROM), random access memory (RAM), and various other forms of volatile or non-volatile storage.