Patent Document

FIELD OF THE INVENTION 
     The present invention relates to systems and methods for data storage, and more particularly, to a system and method for accessing data files. 
     DESCRIPTION OF RELATED ART 
     An application programming interface (API) is a series of functions that programs calls to allow data to be exchanged without directly accessing the application that provides the APIs. For instance, a computer program can (and often must) use its operating system&#39;s API to allocate memory and access files. 
     A cyclic redundancy checksum (CRC) is a type of hash function used to produce a checksum value from a large block of data, such as a computer program or a computer file, in order to detect errors during transmission or storage of the data. An original CRC checksum value is computed before transmission or storage of the data, and a current CRC checksum is computed and compared to the original CRC checksum when the data is accessed afterwards, in order to confirm that no changes occur. 
     Presently, information transmission and storage often depends on computer systems, a familiar and most common means for storing data information is: storing a data file in a storage such as a hard disk of a computer. In order to protect the integrity of the data file, many kinds of methods are adopted, such as password settings to allow only authorized users to access the data file, or a writing protection mechanism to prohibit writing operation to the data file from users, or keeping a whole backup of the data file. However, because all the data are stored in the same storage space, if an outside force attacks the data file, such as a virus attacks the data file, or an authorized user deletes the data file cursorily, password settings and writing protection are of no use, and the same risk can also happen to the whole backup of the data file. As a result, a recovery of the data file is very difficult, especially when the data file is very big. 
     What is needed, therefore, is a system and method for storing a data file backup at multiple locations, therefore if a data file in a node is destroyed, data pieces in the different child nodes of the node can be obtained to rebuild the data file, so as to overcome the risk of storing a whole data file in one node. 
     SUMMARY OF THE INVENTION 
     A system for storing a data file backup in accordance with a preferred embodiment is provided. The system includes at least one server. The server includes a data file accessing module, for dividing a duplicate of a data file stored in a mother node into a plurality of data pieces, storing the data pieces into a plurality of child nodes of the mother node, and merging the data pieces in the child nodes to rebuild the data file in the mother node when the data file is destroyed. 
     Another preferred embodiment provides a method for storing a data file backup. The method includes the steps of: (a) dividing a duplicate of a data file stored in a mother node into a plurality of data pieces and storing each data piece in a corresponding child node of the mother node; (b) determining whether the data file in the mother node is destroyed when accessed by a user; and (c) merging all the data pieces stored in the child nodes to rebuild the data file, if the data file is destroyed. 
     Other advantages and novel features of the embodiments will be drawn from the following detailed description with reference to the attached drawings. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a schematic diagram illustrating a system for storing a data file backup according to a preferred embodiment; 
         FIG. 2  is a flowchart of a preferred method for storing a data file backup by utilizing the system of  FIG. 1 ; 
         FIG. 3  is a detailed description of one step in  FIG. 2 , namely dividing a duplicate of the data file into several data pieces and storing each data piece in a corresponding child node; and 
         FIG. 4  is a detailed description of another step in  FIG. 2 , namely merging all the data pieces stored in the child nodes to rebuild the data file in the root node. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       FIG. 1  is a schematic diagram illustrating a system for storing a data file backup according to a preferred embodiment. The system may include: a client computer  10 , a network  30 , and a plurality of servers. In this preferred embodiment, the servers form a tree data structure, in which each server is regarded as a node at different levels. For example, the server  20  can be a root node at level  1  which has three child nodes at level  2 , server  21 , server  22 , and server  23 . The server  21  further has two child nodes at level  3 , server  211  and server  212 . Furthermore, the server  20  is also said to be a parent node of server  21 , server  22 , and server  23 ; server  21  is also said to be the parent node of server  211  and server  212 . The client computer  10  accesses data files from the server  20  through the network  30 . In other embodiments, the nodes may be located at different storage spaces within a single server instead. 
     Each server has a data file accessing module  200  and each node has a configuration file. The configuration file specifies identification and an address of each child node. 
     The data file accessing module  200  is used for storing a data file sent from the client computer  10  or the parent node, creates a data file copy of the data file, divides the data file copy into a plurality of data pieces, and transmit each data piece as a data file to the child node based on the configuration file correspondingly. In general, the data file copy is divided into the number of the child nodes, which means in the preferred embodiment, the data file copy in the server  20  (the root node) is divided into three data pieces, and each data piece is transmitted to the servers  21 ,  22 , and  23  as data files correspondingly. 
     The data file accessing module  200  corresponding to each child node continues the procedure until a data piece reaches a leaf node (i.e., a node without any child nodes). For example, in the preferred embodiment, the data file accessing module  200  in each child node (e.g. server  21 ) further divides a data file copy (corresponding a data piece of the parent node) stored therein into data pieces according to its child nodes (e.g. servers  211  and  212 ), and stores each data piece in each of its child nodes correspondingly. 
     The data file accessing module  200  is further used for recovering a corrupted or deleted data file in a node by merging the data pieces from each child node of the node, and replacing the corrupted or the deleted data file in the node with the data piece merged. If the data file in the root node (e.g. server  20 ) is destroyed, the data file accessing module  200  merges all the data pieces in the child nodes (e.g. servers  21 ,  22  and  23 ) to rebuild the data file. Similarly, if the data file in the server  21  is destroyed, the data file accessing module  200  thereof merges all the data pieces in its child nodes (e.g. servers  211  and  212 ) to rebuild the data file in the server  21 . 
       FIG. 2  is a flowchart of a preferred method for storing a data file backup. In step S 11 , the data file accessing module  200  receives a new file to be stored and stores the new file in the server  20 . In step S 13 , the data file accessing module  200  creates a new file copy on the server  20 , divides the new file copy into a plurality of data pieces, and transmit each data piece to a child node (detailed description is given in  FIG. 3 ). 
     In step S 15 , the client computer  10  sends a request of accessing the new file stored on the server  20 . In step S 17 , the data file accessing module  200  detects whether the new file in the server  20  is destroyed or corrupted by comparing a current initial CRC32 checksum of the new file with an initial CR32 checksum of the new file. If the two checksum does not equal, this indicates that the new file in the server  20  is destroyed or corrupted, in step S 19 , the data file accessing module  200  merges all data pieces in the child nodes of the server  20  to rebuild the new file (detailed description is given in  FIG. 4 ), and sends the new file rebuilt to the client computer  10  through the network  30 . 
     In step S 17 , if the data file accessing module  200  detects that the new file in the server  20  is intact, the data file accessing module  20  sends the new file to the client computer  10  through the network  30 , the procedure ends. 
       FIG. 3  is a detailed description of step S 13  in  FIG. 2 . In step S 22 , the data file accessing module  200  stores the new file in the server  20 . In step S 24 , the data file accessing module  200  obtains the initial CRC32 checksum of the new file through an application programming interface (API), and stores the initial CRC32 checksum in a storage of the server  20 . In step S 26 , the data file accessing module  200  analyzes whether the node (server  20 ) has child nodes based on the node&#39;s configuration file that specifies identification and an address of each child node. If the server  20  has child nodes, i.e., servers  21 ,  22 , and  23 , then in step S 28 , the data file accessing module  200  divides the new file copy into three data pieces A 1 , A 2  and A 3 , and transmits the data pieces A 1 , A 2 , and A 3  into the servers  21 ,  22 , and  23  respectively. For each data piece sent to each child node of the server  20 , the data file accessing module  200  corresponding to each child node receives the data piece as a new file and performs step S 22  to step S 28 . For example, the data file accessing module  200  in the server  21  divides the data piece A 1  into data pieces A 11  and A 12 , and transmits the data pieces A 11  and A 12  into the servers  211  and  212  respectively. 
     In step S 26 , if the data accessing module  200  determines the server  20  has no child nodes, the procedure ends. 
       FIG. 4  is a detailed description of step S 19  in  FIG. 2 . If the new file stored in server  20  is destroyed or corrupted, in step S 32 , the data file accessing module  200  analyzes whether the corrupted node (server  20 ) has child nodes based on the configuration file of the corrupted node (server  20 ). If the server  20  has child nodes, such as the servers  21 ,  22 , and  23 , in step S 34 , the data file accessing module  200  corresponding to the corrupted node obtains a current CRC32 checksum of each data piece in each child node through the API, for example, the current CRC32 checksum of the data piece A 1  in the server  21 , the current CRC32 checksum of the data piece A 2  in the server  22 , and the current CRC32 checksum of the data piece A 3  in the server  23 . In step S 36 , the data file accessing module  200  compares the current CRC32 checksum of each data piece with a corresponding initial CRC32 checksum of the data piece, and determines whether the current CRC32 checksum is identical with the initial CRC32 checksum. If the two CRC32 checksums of each data piece are identical, indicating that the data pieces are intact, in step S 38 , the data file accessing module  200  merges the data pieces of the child nodes to rebuild the destroyed/corrupted new file in the server  20 . In this preferred embodiment, the data file accessing module  200  obtains and merges the data pieces A 1 , A 2 , and A 3  to rebuild the destroyed new file in the server  20 . If the current CRC32 checksum of any data piece in a child node is different from the initial CRC32 checksum of the data piece in the child node, in step S 40 , the data file accessing module  200  obtains the data piece whose two CRC32 checksums are not identical, such as the data piece A 1 , and repeats from step S 32  to the data piece A 1  in order to rebuild the data piece A 1 . 
     In step S 32 , if the data file accessing module  200  corresponding to the corrupted node determines that the corrupted node is a leaf node (i.e., does not have any child nodes), in step S 42 , the data file accessing module  200  displays an exception through the API to remind the client computer  10  of processing the data file or the data piece by other means. 
     Although the present invention has been specifically described on the basis of a preferred embodiment and preferred method, the invention is not to be construed as being limited thereto. Various changes or modifications may be made to the embodiment and method without departing from the scope and spirit of the invention.

Technology Category: g