JP2015108966A - Document management system, information processing apparatus in document management system, document management method, and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To solve the problem in a document management system using both a database and a file server that, if they are separately backed up, compatibility between the database and the file server is lost when backup data is restored.SOLUTION: A document management system comprising a database server that keeps first data on a document, a file server that keeps second data on the document and a backup file server that keeps backup data of the second data kept by the file server, is further provided with means to restore, when restoration of the first data occurs in the database server, the second data kept by the file server in a manner matching the content of the restoration of the first data by using the data backed up by the backup file server.

Description

  The present invention relates to a technology for data backup and restoration in a document management system.

  In order to manage a large amount of data at low cost, the document management system includes both a high-speed but high-cost database with a relatively small capacity and a low-speed but low-cost and relatively large file server. There is a system to use together. In such a document management system, it is required to maintain consistency between data on a database and data on a file server, and various methods have been studied for that purpose (see, for example, Patent Document 1). In addition, file server backup has been studied so that restoration can be performed at a finer timing, such as periodically performing differential backup (see, for example, Patent Document 2).

JP 2001-282593 A JP 2007-179552 A

  In the case of a document management system in which the data storage destination is divided into a database and a file server as described above, data backup is performed separately in each of the database and the file server. As a result of performing the backup separately, the data after restoration may not be consistent depending on the execution of the backup or the timing of the failure.

  A document management system according to the present invention stores a database server that stores first data of a document, a file server that stores second data of a document, and backup data of the second data stored in the file server When the restoration of the first data occurs in the database server, the data backed up in the backup file server is used for the second data stored in the file server. And a means for performing restoration in accordance with the contents of restoration of the first data.

  In a document management system that uses both a database and a file server, it is possible to maintain data consistency between the database and the file server during restoration.

1 is a diagram illustrating an example of a configuration of an information processing apparatus as each server or client terminal that configures a document management system according to Embodiment 1. It is a figure which shows an example of a structure of the document management system based on Example 1. FIG. FIG. 5 is a diagram illustrating a processing flow in the document management system according to the first embodiment. In the document management system which used both a database and a file server, it is the figure which compared and showed the recovery procedure of a database and a file server when a failure generate | occur | produces in a database. 1 is a functional block diagram of a document management system according to Embodiment 1. FIG. It is a flowchart which shows the flow of the file update process in a file server. It is a figure which shows an example of a journal file. It is a figure explaining the outline | summary of the backup by a backup execution part. It is a flowchart which shows the detail of the backup process by a backup agent. It is a figure which shows how a backup file is preserve | saved by a backup agent. It is a figure explaining the state of the journal file after an update. It is a flowchart which shows the flow of a restore process. It is a flowchart which shows the detail of a process cost determination process. It is the figure which showed the relationship with the backup process in each case when FS restore is performed and when FS restore is not performed. It is a flowchart which shows the detail of a restore process of a file. FIG. 5 is a diagram illustrating a history data storage structure after file restoration. It is a figure explaining the state of the journal file after restoring a file. It is a figure explaining a mode that the historical data before the last FS backup based on Example 2 is deleted. FIG. 10 is a diagram illustrating an example of a configuration of a document management system according to a third embodiment.

  Hereinafter, embodiments for carrying out the present invention will be described with reference to the drawings.

  FIG. 1 is a diagram illustrating an example of a configuration of an information processing apparatus as each server and client terminal that configure a document management system according to the present embodiment. In FIG. 1, the information processing apparatus 100 includes a CPU 102, a memory 103, a storage device 104, a video interface 105, an input / output (hereinafter “I / O”) interface 106, and a communication interface 107. In addition, each component in the information processing apparatus 100 is connected to each other via a system bus 101.

  The CPU 102 is a central processing unit that controls each component via the system bus 101 and performs data calculation and processing.

  The memory 103 is a device that stores data and programs, and includes a RAM (Random Access Memory) and a ROM (Read Only Memory).

  The storage device 104 writes / reads stored data. Examples of the storage device 104 include a hard disk drive (HDD), a magnetic tape drive, a DVD-ROM, and a USB memory. The above-described program is read from the storage device 104, stored in the memory 103, and then executed by the CPU. The program may be read from the ROM or read from the outside via the communication interface 107.

  The video interface 105 controls display output on the display 114.

  Some displays 114 use a CRT, liquid crystal display, or the like.

  Input devices such as a keyboard 115 and a pointing device 116 are connected to the I / O interface 106. The operator issues an operation command to the information processing apparatus 100 by operating the keyboard 115.

  The pointing device 116 moves a cursor on the display 114 to select and operate menus and objects. In addition, there is a display 114 that can input an operation using a touch panel or the like. In this case, the display 114 serves as both an output device and an input device.

  The communication interface 107 communicates with an external device through the network 117. The network 117 includes a public line such as a LAN, a WAN, and the Internet. The communication interface 107 also communicates with other devices such as the local printer 118.

  FIG. 2 is a diagram illustrating an example of the configuration of the document management system according to the present embodiment. The document management system 200 includes server computers (hereinafter referred to as servers) 201 to 205 and a client terminal 211 that are connected to each other via a network 117. As described above, the network 117 includes a LAN, a WAN, the Internet, and the like. In particular, connection between servers includes a connection form such as an interconnect.

  The server 201 is a Web server and is a server for communicating with the client terminal 211.

  A server 202 is an application server (hereinafter referred to as an APP server) and stores a program for controlling the document management system.

  The server 203 is a database server (hereinafter referred to as DB), and stores, for example, bibliographic information of a document to be managed among various data used by the APP server 202.

  The server 204 is a file server (hereinafter referred to as FS), which stores, for example, an entity file of a document to be managed among various data used by the application, and is managed in time series.

  A server 205 is a backup file server (hereinafter referred to as BFS), which stores backup data of document files stored in the FS 204 and manages them in time series.

  In this embodiment, it is assumed that the servers 201 to 205 and the client terminal 211 have the configuration of the information processing apparatus shown in FIG. However, the present invention is not limited to the configuration shown in FIG. 1 and may have other functions.

  The document management system 200 according to the present embodiment is realized by the cooperation of the server groups 201 to 205 described above. Here, the document management system means a system on a computer that stores and manages electronic documents and digitized paper documents. An electronic document (hereinafter referred to as a document) refers to data that can be expressed in a file format on a computer, and its contents are not limited to characters. The document includes various contents such as images and moving images, and all data stored in the file format is included in the “document” here.

  In the document management system 200 according to the present embodiment, a server application is installed on each server. A document management service is provided by combining the functions of the server groups 201 to 205. In FIG. 2, the server groups 201 to 205 are described as separate server housings, but a plurality of server applications may be installed in the same server and the functions may be integrated. Further, it may be a rack mount type system.

  FIG. 3 is a diagram illustrating a processing flow in the document management system 200 according to the present embodiment. A web browser or a dedicated client application is installed on the client terminal 211. When a request is transmitted from the client terminal 211 to the Web server 201, the Web server 201 transmits the received request to the APP server 202. The APP server 202 interprets the request contents and inquires the DB 203 and the FS 204 for necessary information. Then, the APP server 202 transmits information corresponding to the request to the client terminal 211 through the Web server 201. When the client terminal 211 receives the information, the client terminal 211 displays the acquired information on the display.

  Here, the APP server 202 uses the DB 203 and the FS 204 as information storage locations. The database application installed on the DB 203 has excellent searchability, and the FS 204 is suitable for storing large data. That is, by placing an entity file having a large data size in the FS 204 with a low operation cost, a low cost can be realized, and the data amount in the DB 203 can be reduced to improve performance when searching in the DB 203.

  Thus, in a document management system, a database and a file server are sometimes used together, and the present invention is also premised on such a combination. In this embodiment, the APP server 202 performs data storage processing (requests) in the DB 203 and the FS 204 in synchronization, thereby maintaining data consistency as the document management system 200.

  FIG. 4 is a diagram comparing the recovery procedures of the database and the file server when a failure occurs in the database in the document management system using both the database and the file server. In FIG. 4, a right arrow line 400 represents a time passage in the database, a right arrow line 410 represents a time passage in the file server, and the arrow lines 400 and 410 are on the same time axis. The database periodically backs up to generate backup data. In addition, the file server also regularly backs up (hereinafter referred to as FS backup) using an independent backup function to generate backup data. The backup includes a method of backing up all data, a method of backing up a difference from a specific time point to the current time each time, a method of backing up a difference from the previous backup time point, and the like. Note that FS backup is distinguished from backup executed by a backup agent described later. Some file servers do not have an FS backup function.

  When a failure occurs, the database first restores the backed up data at the point in time (when normal) before the failure occurred. Then, the redo log is applied to the data obtained by the restoration. Here, the REDO log is a log recorded so that the database application itself can re-execute the operation (processing) performed on the database. Restoration restores the contents of the database to the point in time when the backup was executed. Therefore, if the restoration is performed alone, the contents of the processing performed between the time of backup execution and the time of failure will be lost. Therefore, the redo log is applied to the data obtained by the restoration in order to return to the normal state immediately before the failure. The REDO log is stored in a database application instance existing in the memory 103 or a database existing in the storage device 104. For this reason, depending on the content of the failure, the REDO log is not always recorded until the immediately preceding process. For example, when a problem occurs in an instance of a database application, only the REDO log saved in the database of the storage device 104 may remain. Therefore, the redo log is applied in consideration of the consistency of processing in the entire system within the range of the recorded redo log.

  On the other hand, the file server can restore the data by restoring the backup data by the FS backup, as in the case of the database. However, the database and the file server are separate mechanisms, and data is not always consistent between the backup in the database and the FS backup in the file server. Further, the file server has no recovery means such as a REDO log. Therefore, when the REDO log is applied to the restored data on the database side, it is not possible to achieve data consistency between the file server and the database.

  Therefore, in a document management system using both a database and a file server, there is a problem that data inconsistency occurs when data is restored when a failure occurs. In the above example, the case where a failure occurs has been described as an example. However, if it is desired to return to the state at a specific time, a similar problem occurs.

  Next, a solution to the above problem will be described.

  FIG. 5 is a functional block diagram of the document management system 200 according to the present embodiment. Each function described below is realized on the FS 204 and the BFS 205. Since the FS 204 and the BFS 205 have different roles, not all of the functions shown in FIG. 5 operate in each of the two servers, but the roles can be switched because both servers have equivalent functions.

  The request receiving unit 501 receives requests from other servers.

  The update information management unit 502 creates and manages a journal file described later based on the received request.

  A file management unit 503 operates and manages files in the FS 204.

  The temporary file management unit 504 temporarily stores the original file when changing or deleting the file, and manages the stored file (temporary file).

  The backup execution unit 505 performs backup to ensure data consistency with the DB 203. Although details will be described later, the backup by the backup execution unit 505 is a process different from the above-described FS backup, and is performed by a dedicated backup agent.

  The FS backup inquiry unit 506 inquires about the contents of the FS backup described above.

  The restore execution unit 507 executes a later-described restore process based on the backup data generated by the backup execution unit 505.

  Prior to the description of the backup process for ensuring data consistency with the DB 203, the file update process in the FS 204 will be described.

  FIG. 6 is a flowchart showing the flow of file update processing in the FS 204. Note that a program for executing a series of processes according to this flowchart is stored in the storage device 104 of the FS 204, read out to the memory 103, and executed by the CPU 102.

  In step 601, the request reception unit 501 of the FS 204 receives a file update request from the APP server 202.

  In step 602, the file management unit 503 of the FS 204 determines the command type of the received request. There are various types of commands, but in the following, description will be made using typical file addition (ADD), change (MOD), and deletion (DEL). If it is determined that the command type of the received request is file addition (ADD), the process proceeds to step 603. On the other hand, if it is determined that the command type of the received request is file change (MOD) or deletion (DEL), the process proceeds to step 604.

  In step 603, the file management unit 503 of the FS 204 stores the processing target file related to the received request in a predetermined position.

  In step 604, the file management unit 503 of the FS 204 cooperates with the temporary file management unit 504 to save the processing target file being saved at a predetermined location in the temporary area.

  In step 605, the file management unit 503 of the FS 204 determines again the command type of the received request. If it is determined that the command type of the received request is delete (DEL), the process proceeds to step 606. As a result, the processing target file saved in the temporary area in step 604 is deleted. On the other hand, if it is determined that the command type of the received request is change (MOD), the process proceeds to step 603, and the file to be processed is stored in a predetermined position.

  In step 606, the update information management unit 502 of the FS 204 updates the journal file. FIG. 7 is a diagram illustrating an example of a journal file managed in the FS 204. In FIG. 7, a column 701 contains information on a time stamp when there is a request. This time stamp becomes information necessary for synchronizing with the data update processing in the DB 203. A column 702 contains information on a time stamp when a backup described later is performed. Since FIG. 7 is in a non-backup state, no value is entered and a null character is stored. The column 703 contains information on the command type of the received request (in this embodiment, any one of the above-mentioned addition (ADD), change (MOD), and deletion (DEL)). A column 704 contains information on the location where the file is stored.

  Next, backup of the file updated as described above by the backup execution unit 505 will be described. FIG. 8 is a diagram for explaining the outline of backup by the backup execution unit 505.

  As shown in FIG. 8A, the file 802 is copied from the FS 204 to the BFS 205 via the network 117 by the backup agent 801 described above. The backup agent 801 performs file backup in the order of data recorded in the journal file. FIG. 8B is a sequence diagram showing a rough flow of the backup processing. An arrow line 821 indicates a request from the APP server 202 to the FS 204, an arrow line 822 indicates the file update process described above, and an arrow line 823 indicates a response to the request (arrow line 821). An arrow line 824 indicates a backup request from the FS 204 to the BFS 205, and an arrow line 826 indicates a response to the backup request (arrow line 824). An arrow line 825 indicates a portion executed in the BFS 205 in a backup process to be described later, and an arrow line 827 indicates a portion executed in the FS 204.

  As described above, the backup process by the backup agent 801 is performed asynchronously with the file update process indicated by the arrow 822, and is executed in cooperation with the backup execution unit 505 of the FS 204 and the BFS 205. In the example of FIG. 8, the backup agent 801 is configured to operate on the FS 204, but may be configured to operate on another server.

  FIG. 9 is a flowchart showing details of the backup processing by the backup agent 801 executed in the BFS 205 and the FS 204. Steps 901 to 912 correspond to the aforementioned arrow line 825 executed in the BFS 205, and steps 913 and 914 correspond to the aforementioned arrow line 827 executed in the FS 204. Note that a program for executing a series of processes according to this flowchart is stored in the storage device 104 of the FS 204 or the BFS 205, read out to the memory 103, and executed by the CPU 102.

  In step 901, the request reception unit 501 of the BFS 205 receives a backup request from the FS 204.

  In step 902, the file management unit 503 of the BFS 205 determines the command type of the received backup request. The backup request from the FS 204 includes information on each command stored in the above-described journal file column 703, and backup according to the command is executed. That is, as described below, files are saved (copied) in response to backup requests corresponding to each command, and backup files are accumulated as a history.

  In step 903, the backup execution unit 505 of the BFS 205 creates a history data storage folder. FIG. 10 is a diagram showing how a backup file is stored by the backup processing by the backup agent 801. In the example of FIG. 10, a state in which backup is performed for two types of files “aaa.pptx” and “bbb.xlsx” is shown. The history data storage folder created in this step refers to the folders 1002 and 1012 in FIG. In this history data storage folder, a copy of the file updated for each request is stored as a backup file.

  In step 904, the backup execution unit 505 of the BFS 205 determines the file name of the backup file. The file name assigned to the backup file is obtained by adding a time stamp and a command type to the original file name. The request time (see column 701 in FIG. 7) is used as the time stamp at this time, not the backup time. As described above, the backup here is performed asynchronously with the file update process, but the consistency of data with the DB 203 can be achieved by using the time stamp used for the file name of the backup file as the request time. it can.

  In step 905, the backup execution unit 505 of the BFS 205 stores the backup file with the file name determined in step 904 in a predetermined position. Files 1003, 1004, 1014, and 1015 in FIG. 10 correspond to the backup files saved in this step. The files 1003, 1014, and 1015 are backup files in the case of a change (MOD) command, and the file 1004 is a backup file in the case of an add (ADD) command.

  In step 906, the backup execution unit 505 of the BFS 205 confirms whether or not it is set to use the BFS 205 as a standby environment of the FS 204. If it is set to be used as a standby environment, the process proceeds to step 907. On the other hand, if it is not set to be used as a standby environment, the process proceeds to step 912. Whether the BFS 205 is used as a standby environment for the FS 204 is set in advance.

  In step 907, the backup execution unit 505 of the BFS 205 updates the current file. In order for the BFS 205 to operate as a standby environment, the BFS 205 needs to hold the same data as the FS 204, and the current data corresponds to the same data (file). A file 1001 in FIG. 10 corresponds to the current file “aaa.pptx”. The history data storage folder 1002 and the file group in the folder 1002 are data that does not exist in the FS 204. Therefore, the latest file is arranged with the same configuration as the file on the FS 204. That is, the file 1001 and the file 1003 have the same contents. When the BFS 205 is not set to operate as a standby environment of the FS 204, the BFS 205 functions as a simple backup file storage, and thus no current file is required.

  In step 908, the backup execution unit 505 of the BFS 205 generates a deletion status identification file (dummy file). This deletion state identification file is a dummy file with no content, but is generated and held to indicate that it has been deleted.

  In step 909, the backup execution unit 505 of the BFS 205 stores the generated deletion status identification file in a predetermined position. A file 1013 in FIG. 10 corresponds to this deletion state identification file.

  In step 910, the backup execution unit 505 of the BFS 205 confirms whether or not the BFS 205 is set to be used as a standby environment of the FS 204 as in the case of addition or update. If it is set to be used as a standby environment, the process proceeds to step 911. On the other hand, if it is not set to be used as a standby environment, the process proceeds to step 912.

  In step 911, the backup execution unit 505 of the BFS 205 deletes the current file. For example, in FIG. 10, there is no current file for the file “bbb.xlsx”. This shows a state in which the current file for the file “bbb.xlsx” has been deleted, and thus the BFS 205 is in the same state as the environment of the FS 204.

  In step 912, the update information management unit 502 of the BFS 205 updates the journal file. The journal file updated in this step is the same as the journal file of the FS 204 shown in FIG. 7 described above, but exists in the BFS 205. (A) of FIG. 11 is a journal file of the BFS 205 and shows a state after being updated in this step, and information on a time stamp when backup is performed is stored in a column 702.

  As described above, the processing after step 913 is executed in the FS 204.

  In step 913, the backup execution unit 505 of the FS 204 deletes the file saved in the temporary area. This is a process accompanying the saving of a file to a temporary area (step 604) in the above-described flowchart of the file update process of FIG. Since the backup process by the backup agent 801 is performed asynchronously with the file update process, the file saved in the temporary area after the backup process is completed is deleted.

  In step 914, the update information management unit 502 of the FS 204 updates the journal file. The journal file updated in this step is the journal file shown in FIG. FIG. 11B shows the state of the journal file after being updated in this step. Compared with FIG. 7, in FIG. 11B, it can be seen that the time stamp information indicating that the backup has been performed is stored in the column 702. However, for the record 1101 related to the unbackup request at this time, the value in the column 702 is in an empty character state.

  The above is the content of the backup process performed by the backup agent 801 to ensure data consistency with the DB 203.

(Restore processing)
Next, restore processing that is performed in conjunction with backup processing by the backup agent will be described with reference to FIGS.

  FIG. 12 is a flowchart showing the flow of restore processing. Note that a program for executing a series of processes according to this flowchart is stored in the storage device 104 of the BFS 205, read out to the memory 103, and executed by the CPU 102. This restore processing is performed from the BFS 205 to the FS 204, but the file update processing on the FS 204 is naturally executed in the FS 204.

  In step 1201, the restore execution unit 507 of the BFS 205 first acquires the recovery point of the DB 203. The recovery point of the DB 203 is information indicating how far recovery has been performed as a result of restoring data in the DB 203 and applying the REDO log (see FIG. 4 described above).

  In step 1202, the restore execution unit 507 of the BFS 205 determines a recovery point of the backup file based on the acquired recovery point of the DB 203. Specifically, referring to a journal file managed by the FS 204, the content of the update process in the FS 204 performed in synchronization with the update process in the DB 203 is specified. Thus, it is specified how far the data in the FS 204 is recovered in order to maintain data consistency with the DB 203. This will be described in detail below.

  First, information on the last recovery time (the latest time from the present) in the DB 203 is acquired from the REDO log. In that case, information on the final time may be acquired directly from the REDO log, or may be acquired indirectly (for example, information on the final process of recovery is acquired and acquired based on the information). Then, the acquired final recovery time is compared with the time in the request time column 701 of the journal file of the FS 204 (see (b) of FIG. 11 described above). Then, the process performed immediately before the final recovery time is specified as the recovery point of the backup file. The specific method may differ depending on the data storage synchronization processing in the Web server 201. For example, when a request to the FS 204 is transmitted after the database commit, the processing performed immediately after the recovery last time of the DB 203 is specified as the recovery point of the backup file. In addition, when the data storage synchronization processing in the Web server 201 is performed by a plurality of requests, information for identifying processing such as a session ID or a thread ID is also stored in the journal file.

  In step 1203, the restore execution unit 507 of the BFS 205 determines whether there is data that has not yet been backed up. If unbacked data exists, the process proceeds to step 1204. On the other hand, if no unbackup data exists, the process proceeds to step 1205.

  In step 1204, the restore execution unit 507 of the BFS 205 performs backup of unbackup data and saves the backup file in the BFS 205. For example, the temporarily stored data indicated by the record 1101 in FIG. 11B means the unbackup data here. In FIG. 11B, the data indicated by the record 1101 is stored in the FS 204 in the process related to the command (ADD), but the column 702 is in an empty character state, indicating that backup has not been performed. Yes. As a restoration method, a method of directly restoring from a temporary storage destination without performing backup of unbacked data is conceivable. In this case, however, no history remains in the BFS 205.

  In step 1205, the FS backup inquiry unit 506 of the BFS 205 performs processing cost determination processing described later to determine whether to perform FS restoration. If the FS 204 does not have an FS backup function, the processing from this step to step 1207 is omitted. If it is determined that it is better to restore the FS in this step, the process proceeds to step 1207. On the other hand, if it is determined not to restore the FS, the process proceeds to step 1208. FIG. 13 is a flowchart showing details of the processing cost determination processing. Prior to the description of the flowchart of FIG. 13, a description will be given of when it is better to perform FS restoration. FIG. 14 is a diagram showing the relationship with the backup processing in each case when the FS restore is performed and when the FS restore is not performed based on the journal file of the FS 204. A thick line 1401 represents the recovery point of the backup file specified in the above step 1202, and a thick line 1402 represents an FS restore point (information indicating how far the file is restored when the FS restore is performed). First, when the FS restore is performed, the data of the FS 204 is restored to the content at the time when the FS backup was performed. It is necessary to execute again. On the other hand, if the FS restore is not performed, it is possible to achieve consistency with the DB 203 by returning the data contents from the current state to the recovery point 1401 state. In both cases, the result is the same, but the processing method is different. Therefore, the processing method that requires less processing cost is determined by the processing cost determination processing shown in the flowchart of FIG.

  In step 1301, the FS backup inquiry unit 506 of the BFS 205 estimates the processing cost of the FS restore itself. For example, if the FS 204 has an I / F that returns the estimated time required for the restore process, the FS 204 is inquired to acquire information on the estimated time. Alternatively, the required time estimated for each file number and file size may be stored in advance in a table or the like and acquired by referring to the table. In addition, if the file server is of a type in which the restore time is not significantly affected by the file size and the number of files, information may be held that takes n minutes uniformly. Furthermore, in the case of a file server of a type in which the restore time varies depending on the number of files, it may be obtained by calculating “file registration usage rate” × “unit processing time”.

  In step 1302, the FS backup inquiry unit 506 refers to the journal file and acquires update processing information (hereinafter, update information) from the recovery point of the backup file to the FS restore point. For example, in the case of the journal file shown in FIG. 14, nine records in the range from the recovery point 1401 to the FS restore point 1402 are acquired as update information.

  In step 1303, the FS backup inquiry unit 506 performs a process of thinning out unnecessary intermediate processes from the past to the present for the update information acquired in step 1302. For example, when the contents of the nine records described above are acquired as update information, there are three records (records 1411, 1412, and 1413) as update processing for the file “ddd.pptx”. These three records are all change (MOD) processing, and when these are updated in order from the past, the file of the processing updated in the record 1413 is finally obtained. That is, since it is not necessary to apply the processes of the records 1411 and 1412, the processes related to these two records are thinned out as an intermediate process.

In step 1304, the FS backup inquiry unit 506 estimates the total processing cost required for the FS restoration. Specifically, the processing cost for restoring one file is multiplied by the number of update processes after thinning out unnecessary intermediate processing, and the processing cost obtained in this way is the processing of the FS restoration itself estimated in step 1301. Add the costs to estimate the total processing cost. This is expressed as follows.
Total processing cost = (Restore processing time for one file × Number of update processes obtained in S1303)
+ FS Restoration Processing Time Here, the restoration processing time of one file is obtained by file size × coefficient. This coefficient is set in advance according to the size of the file, and it is set in advance how much processing time is required for each file size in consideration of the network environment and the like.

  In step 1305, the FS backup inquiry unit 506 acquires update information from the present to the recovery point of the backup file. The update information is as described in step 1302, and in the example of FIG. 14, three records in the range from the present to the recovery point 1401 are acquired as update information.

  In step 1306, the FS backup inquiry unit 506 performs a process of thinning out unnecessary intermediate processes from the present to the past with respect to the update information acquired in step 1305. The meaning of thinning out is the same as in step 1303 described above. In step 1303, unnecessary intermediate processing is thinned from the past to the present, whereas in this step, unnecessary intermediate processing is performed from the present to the past. It will be thinned out.

  In step 1307, the FS backup inquiry unit 506 estimates the total processing cost when the FS restoration is not performed. Here, the total processing cost is estimated by multiplying the processing cost required for restoring one file described above by the number of update processing after thinning out unnecessary intermediate processing. Since the FS restore is not performed, the processing cost of the FS restore itself is not added, which is different from step 1304.

  In step 1308, the FS backup inquiry unit 506 compares the total processing cost in the case of performing the FS restoration obtained in step 1304 with the total processing cost in the case of not performing the FS restoration obtained in step 1307, so that the processing cost is lower. Select the direction.

  The above is the content of the process for determining whether to perform FS restoration.

  Returning to the flowchart of FIG.

  In step 1207, the restore execution unit 507 of the FS 204 executes FS restore. The contents of the FS restoration are as described above.

  In step 1208, the restore execution unit 507 of the BFS 205 restores the file to the FS 204. FIG. 15 is a flowchart showing details of the file restore processing in this step.

  In step 1501, the restore execution unit 507 confirms whether or not FS restore is executed. If the FS restore has been executed (Yes in step 1206), the process proceeds to step 1502, and the processing in steps 1503 to 1506 is executed in units of files. On the other hand, if the FS restore has not been executed (No in step 1206), the process proceeds to step 1507, and the processes in steps 1508 to 1514 are executed in units of files.

  First, file restoration processing when FS restoration has been executed will be described.

  In step 1502, the restore execution unit 507 acquires the update information after the thinning process in step 1303 described above.

  In step 1503, the restore execution unit 507 refers to the journal file for the target file, and re-updates (overwrites) the corresponding file in the FS 204 with the content of the backup file having the request time specified by the acquired update information. To do.

  In step 1504, the restore execution unit 507 determines whether or not the history data (see FIG. 10 described above) of the BFS 205 is changed by the re-update process. If the history data changes, the process proceeds to step 1505. For example, the file “aaa.pptx” is in a state of 2013/03/20 14:58:01 by reprocessing after FS restoration, but in the BFS 205, it is in a state of 2013/03/21 15:52:06. In such a case, the process proceeds to step 1505. On the other hand, when the history data does not change, it is not necessary to change the contents of the backup file in the BFS 205. For example, regarding the file “ddd.pptx”, the reprocessed state (2013/03/20 14:35:25) after the FS restoration is the same state in the BFS 205 as well. In such a case, if there is an unprocessed file, the process proceeds to the next file process, and if there is no unprocessed file, the process is terminated.

  In step 1505, the restore execution unit 507 updates the backup file. FIG. 16 shows a history data storage structure after file restoration, and corresponds to FIG. 10 described above. Before the restoration, the latest backup file of the file “aaa.pptx” is the file 1003, and the latest backup file of the file “bbb.xlsx” is the deletion state identification file 1013. Here, when the file “aaa.pptx” in the FS 204 returns to the state of the file 1004 by restoration, the file 1004 is copied to generate the latest backup file 1602. Further, the current file 1601 is also updated with the contents of the file 1004. As a result, the files 1601, 1602, and 1004 have the same contents. Similarly, when the file “bbb.xlsx” in the FS 204 returns to the state of the file 1015 by the restoration, the file 1015 is copied and the latest backup file 1612 is generated. Further, a current file 1611 having the same contents as the file 1015 is generated. As a result, the files 1611, 1612, and 1015 are files having the same content. The latest backup files 1602 and 1612 are given identifiers indicating that they have been restored. Here, the identifier “RSTMOD” is given to the backup file 1602 because it has been updated by the restore, and the identifier “RSTADD” is given to the backup file 1612 because it has been added from the state deleted by the restore.

  In step 1506, the restore execution unit 507 updates the journal file. The journal file is also changed in accordance with the contents of the backup file described with reference to FIG. FIG. 17 shows a journal file of the BFS 205 after file restoration. In FIG. 17, records 1701 to 1703 are records added by file restoration. Information indicating that the records 1701 to 1703 have been updated by the restore is stored in the command string 703 of the records 1701 to 1703. Further, the same time stamp is stored in the request time column 701 and the backup time column 702 in these three records 1701 to 1703. At this time, the journal file of the FS 204 is also updated.

  Next, a file restore process when no FS restore is performed will be described.

  In step 1507, the restore execution unit 507 acquires update information after the thinning process in step 1306 described above.

  In step 1508, the restore execution unit 507 determines the command type of the record in the acquired update information for the target file. If it is determined that the command type is file change (MOD) or deletion (DEL), the process proceeds to step 1509. If it is determined that the command type is file addition (ADD), the process proceeds to step 1512.

  In step 1509, the restore execution unit 507 acquires the content of the update process before the recovery point (1401) for the target file. For example, in FIG. 17, when the file “bbb.xlsx” is the target file, the content indicated by the record 1704 is acquired.

  In step 1510, the restore execution unit 507 acquires a backup file corresponding to the acquired content of the previous update process from the BFS 205. For example, when the target file is “bbb.xlsx” and the content of the record 1704 is acquired as the content of the previous update process, the file 1014 in FIG. 16 is acquired.

  In step 1511, the restore execution unit 507 updates the contents of the corresponding file in the FS 204 with the contents of the backup file acquired in step 1510. As a result, the contents of the file are returned to the previous version.

  In step 1512, the restore execution unit 507 deletes, from the FS 204, the target file to which a command is added (ADD) in the update information record acquired in step 1507.

  The contents of subsequent steps 1513 and 1514 are the same as those of the aforementioned steps 1505 and 1506. That is, the restore execution unit 507 generates the latest backup file (step 1513) and updates the journal file (step 1514).

  The above is the content of the file restoration process.

  Note that when there are a plurality of journal files depending on the management form of the database, the above-described file backup and restoration may be executed for each journal file.

  In this embodiment, the journal file exists in both the FS 204 and the FS 205, but may be managed centrally in either one (or another location such as a database).

  According to the present embodiment, in a system using both a database and a file server, it is possible to maintain data consistency when restored.

  In the first embodiment, in order to maintain data consistency between the database and the file server, all history data updated by the file server is stored in the backup file server. However, since the amount of data stored increases with the passage of time, it is necessary to delete unnecessary history data. For example, when the above-mentioned FS backup is regularly performed by the file server, it is considered that the possibility of returning the data to the state before the latest FS backup is extremely low. Therefore, an embodiment of reducing the data capacity stored in the backup file server by deleting a history file older than a specific time point, such as before the most recent FS backup, will be described as a second embodiment. The description of the parts common to the first embodiment will be omitted or simplified, and the differences will be mainly described below.

  FIG. 18 is a diagram for explaining a state of deleting history data (backup file) before the most recent FS backup according to the present embodiment, and corresponds to the backup file storage structure of FIG. 10 described above. In FIG. 18, a file 1801 is a current file, and a folder 1802 is a history data storage folder for storing backup files. Backup files 1803 to 1809 are stored in the history data storage folder 1802. A dotted line 1810 indicates a point in time when the latest FS backup is performed. Therefore, in the example of FIG. 18, backup files 1806 to 1809 stored before the most recent FS backup time 1810 are deleted.

  This backup file deletion process is executed by the file management unit 503 in the BFS 205. Specifically, information on the date and time when the FS backup was performed is received from the FS server 204, and among the backup files managed in the BFS 205, backup files before the received date and time are moved to the deletion folder or the like. Deleted.

  In addition to deleting a backup file that is older than a specific point in time, for example, data at the present time or one point in the past may be backed up to a secondary medium (for example, a tape medium).

  According to the present embodiment, it is possible to reduce the data capacity of the backup file server by periodically deleting the history data based on the information of the date and time when the FS backup was executed.

  Next, a case where a standby environment exists in a physically separated place will be described as a third embodiment. The description of the parts common to the first embodiment will be omitted or simplified, and the differences will be mainly described below.

  FIG. 19 is a diagram showing an example of the configuration of the document management system according to the present embodiment, and shows a situation where a standby environment exists in a physically separated place. In FIG. 19, SDB 1901 is a database as a standby environment of DB 203, and SFS 1902 is a foul server as a standby environment of FS 204. The SDB 1901 and the SFS 1902 are connected to the DB 203 and the FS 204 through the network 117, and are arranged at locations physically separated from each other. In general, synchronization between the DB 203 and the SDB 1901 is performed using a database application or a dedicated application of a vendor that provides the database application. Therefore, the synchronization between the FS 204 and the SFS 1902 is performed separately from the database. Therefore, in the case of a system that uses both a database and a file server, the database and file server as a replicated standby environment do not always have data consistency at a certain point in time. Therefore, in this embodiment, the SFS 1902 is used as a backup file server. That is, in this embodiment, the SFS 1902 operates as a standby environment of the FS 204 while having the same function as the BFS 205 described above.

  When the SFS 1902 operates as a standby environment of the FS 204, data consistency is achieved by updating the data of the SFS 1902 based on the replication completion point of the SDB 1901, as in the above-described restoration. The process for ensuring data consistency when operating as this standby environment is basically the same as the restore process shown in the flowchart of FIG. At this time, in step 1201, a replication completion point in the SDB 1901 is acquired instead of the recovery point in the DB 203. Then, by starting the standby environment after consistency is achieved, it is possible to use both the DB server and the file server without any problem. Note that the FS 204 and the BFS 205 cooperate to execute processing during the restoration in the first embodiment. However, in the standby environment of the present embodiment, each function shown in the functional block diagram of FIG. 5 operates on the SFS 1902. Become.

(Other examples)
The present invention is also realized by executing the following processing. That is, software (program) for realizing the functions of the above-described embodiments is supplied to a system or apparatus via a network or various storage media, and a computer (or CPU, MPU, etc.) of the system or apparatus reads the program. It is a process to be executed.

Claims (10)

A document management system, a database server that stores first data of a document, a file server that stores second data of a document, and a backup that stores backup data of the second data stored in the file server Including a file server,
When the restoration of the first data occurs in the database server, the first data is obtained by using the data backed up in the backup file server with respect to the second data stored in the file server. A document management system comprising means for restoring according to the contents of restoration for Means for determining the content of a restore to be performed on the second data managed by the file server based on the content of the recovery by the restore performed on the first data in the database server;
The document management system according to claim 1. When the file server has an independent backup function not via the backup file server, the file server further includes a determination unit that determines whether to perform independent restoration on the data backed up by the backup function,
The content of the restore performed on the second data managed by the file server, determined by the means for determining the content of the restore, differs depending on the result of determination by the determination unit,
The document management system according to claim 2, wherein: The determination means includes
First estimating means for estimating a processing cost when the independent restoration is performed on the data backed up by the independent backup function;
Second estimating means for estimating a processing cost when the independent restoration for the data backed up by the independent backup function is not performed;
4. The document management system according to claim 3, further comprising means for comparing the result of the first estimation means and the result of the second estimation means and selecting the one with the lower processing cost. The file server has update information indicating an update history of the second data;
The backup file server has second update information indicating a history of update of backup data backed up with the update,
The means for performing restoration restores the second data in the file server in accordance with the contents of the restoration of the first data in accordance with the second update information from which unnecessary processing has been thinned out. The document management system according to claim 1, wherein:   6. The document management according to claim 1, wherein the backup file server further includes means for deleting backup data older than a specific point in time among backup data stored in time series. system.   7. The document management system according to claim 1, wherein the first data is bibliographic information of the document, and the second data is a document actual file.   8. The document management system according to claim 7, wherein a file name of backup data backed up in accordance with the update includes information indicating a time of the update request for the actual file of the document. Document management system including a database server that stores first data of a document, a file server that stores second data of a document, and a backup file server that stores backup data of the second data stored in the file server Document management method in
When the restoration of the first data occurs in the database server, the first data is obtained by using the data backed up in the backup file server with respect to the second data stored in the file server. A document management method comprising a step of performing restoration according to the content of restoration for   A program for causing a computer to function as the document management system according to any one of claims 1 to 8.

Images