KR102427418B1 - Apparatus and method for synthetic of backup data - Google Patents

Abstract

Synthesis of backup data that can minimize the storage space for data restoration and shorten the data restoration time by creating synthetic metadata that implements virtual backup data in the metadata area and restoring the data at the point of recovery based on the synthetic metadata. An apparatus and method, and a recording medium are disclosed. The backup data synthesizing apparatus according to an embodiment of the present invention includes full backup data generated by performing a full backup of backup target data, and data at a recovery point from backup data including incremental backup data generated by incrementally backing up from the full backup data. A backup data synthesizing apparatus for synthesizing and restoring a virtual backup data synthesizing apparatus for generating synthetic metadata for realizing virtual backup data by synthesizing incremental backup metadata related to the incremental backup data with full backup metadata related to the full backup data backup data generation unit; and a data restoration unit that extracts and restores data at the recovery point in time from the full backup data and the incremental backup data based on the virtual backup data implemented by the synthetic metadata.

Description

Apparatus and method for synthesizing backup data

The present invention relates to an apparatus and method for synthesizing backup data, and more particularly, by creating synthetic metadata that implements virtual backup data in a metadata area and restoring data at a recovery point based on the synthetic metadata, data restoration is performed. It relates to an apparatus and method for synthesizing backup data that can minimize the storage space and shorten the data backup and restoration time.

All application programs stored in the computer's memory and executed by the processor operate to process data. At this time, the result data processed through the data operation of the application program is stored in the storage medium again by an input/output-related system call. Data stored in the storage medium may be lost or lost due to various factors such as system failure, which not only cannot guarantee business continuity, but also may incur huge costs for data recovery.

In order to minimize the work gap caused by data loss, the data management part introduces and operates a data backup system. The data backup system backs up data using methods such as full backup and incremental backup according to the importance and nature of data. Full backup is a method of backing up all data to be currently backed up, and incremental backup is a method of backing up only data that has changed since the full backup. Incremental backup can save time for backing up because the target to back up data can be given more than the full backup time for backing up the entire data.

1 is a conceptual diagram illustrating a process of fully backing up data to be backed up. Referring to FIG. 1 , a full backup is a backup method of backing up the entire backup target data 10 . During the full backup, the data of the files of the backup target data 10 is transmitted to the backup server, and the full backup metadata 12 and the full backup data 14 are stored in the storage 20 of the backup server. The full backup metadata 12 is metadata indicating a hierarchical structure (directory), a file name, a file ID, a size, a storage location, and the like of the files (files A to D) of the full backup data 14 . The full backup data 14 may include data of files A to D of the backup target data 10 .

FIG. 2 is a conceptual diagram illustrating a process of incrementally backing up changed data from the backup target data that has been fully backed up in FIG. 1 . 1 and 2, incremental backup (Incremental Backup) does not transmit the entire backup target data 10' to the backup server, and only data changed from the previously backed up data is transmitted to the backup server to shorten the backup time. backup method. The backup target data 10' illustrated in FIG. 2 is data changed from the backup target data 10 after the backup target data 10 illustrated in FIG. 1 is fully backed up. For example, when file B is deleted from the backup target data 10 of FIG. 1, file D is changed, and file E incrementally backs up the newly created backup target data 10', changes (deletion, modification) Or, the incremental backup metadata 12' for the created files (file B, D, E) and the data 14' of the modified or created files (file D, E) are transmitted to the backup server. stored in the storage 20 .

When it is necessary to restore the data backed up in the storage 20, the full backed up data only needs to restore the file state at the time it was backed up. Through the process of synthesizing data, the state of the file at the time of the backup can be restored. 3 is a conceptual diagram illustrating a process of restoring data that has been previously incrementally backed up. In general, in order to restore data at a specific point in time, the full backup data 14 is first restored, and then the data at a specific point in time is restored by reflecting the incremental backup data 14'. If incremental backups are performed several times after the full backup, data at a specific point in time can be restored through synthesis that sequentially reflects the incremental backup data 14' in the order of the incremental backup after the restoration of the full backup data 14. .

For example, in order to restore the data backed up by the 5th incremental backup after the full backup, it is necessary to restore the data backed up by the full backup and then reflect the data from the first incremental backup to the 5th incremental backup in order. In this case, It takes a lot of time to restore. In addition, the data at the time of the incremental backup must be synthesized by copying the full-backed data and then overwriting the incrementally-backed data to the copied data in turn. For example, if the backed up data size is 10.3 GB, the full backup data size is 10 GB, and the incremental backup data size is 0.3 GB, an additional 10 GB storage space is required for copying the full backup data and , additional storage space is also required to sequentially overwrite the incremental backup data to the full backup data. Therefore, there is a problem that a large amount of storage space must be allocated for data restoration, and data restoration takes a long time.

An object of the present invention is to provide an apparatus and method for synthesizing backup data, and a recording medium for generating synthetic meta data that implements virtual backup data (virtual backup image) in a meta data area and restoring data at a recovery point based thereon.

Another object of the present invention is to provide an apparatus and method for synthesizing backup data and a recording medium capable of minimizing a storage space for data restoration and shortening a data restoration time.

Another object of the present invention is to provide an apparatus and method for synthesizing backup data, and a recording medium capable of restoring data at a desired backup point without repeatedly overwriting the incremental backup data on the full backup data after copying the full backup data. .

The backup data synthesizing apparatus according to an embodiment of the present invention includes full backup data generated by performing a full backup of backup target data, and data at a recovery point from backup data including incremental backup data generated by incrementally backing up from the full backup data. A backup data synthesizing apparatus for synthesizing and restoring a virtual backup data synthesizing apparatus for generating synthetic metadata for realizing virtual backup data by synthesizing incremental backup metadata related to the incremental backup data with full backup metadata related to the full backup data backup data generation unit; and a data restoration unit that extracts and restores data at the recovery point in time from the full backup data and the incremental backup data based on the virtual backup data implemented by the synthetic metadata.

The data restoration unit may restore the data by extracting the chunk corresponding to the recovery point from the data file based on the synthetic metadata generated in the metadata area without copying the full backup data to restore the data. have.

The composite metadata may include a revision field for recording a valid backup operation range for each file. The virtual backup data generator may be configured to change a field value of the revision field according to a change type of the file.

The revision field may include a file generation version field indicating in which backup job the file was created; and a file deletion version field indicating the number of backup jobs the file is valid for.

The virtual backup data generation unit may be configured to: determine which change type of the file corresponds to among a plurality of change types including file creation, file deletion, and file modification; when the change type corresponds to the deletion of the file, setting the file deletion version field to a value corresponding to a previous backup job that is the most recent backup job among previous backup jobs; when the change type corresponds to the file creation, set the file creation version field to a value corresponding to a current backup job, and set the file deletion version field to a maximum value; And when the change type corresponds to the file modification, the file deletion version field of the file before modification may be configured to set from the maximum value to a value corresponding to the previous backup job.

The virtual backup data generation unit, when the change type corresponds to the file modification, adds a record for the modified file and sets the file generation version field for the modified file to a value corresponding to the current backup job, , set the file deletion version field for the modified file to the maximum value.

The composite metadata may include a chunk group ID field for allocating a chunk group ID to a group of chunks constituting the file, and a header number field for recording a header number corresponding to each chunk. The virtual backup data generation unit adds a new record to the composite metadata by writing a new field value in the chunk group ID field when the file change type corresponds to the file creation or the file modification; And when some of the chunk data of the file is changed, the unaltered data among the chunk data does not update the header number field, but a new chunk is created for the changed data among the chunk data, and a new header is added to the header number field. may be configured to generate a number.

the data restoration unit extracts records corresponding to the restoration time point from the composite metadata based on the revision field; And it may be configured to read data corresponding to the extracted records from the data file to restore the data.

The data restoration unit may be configured to extract records satisfying a condition in which a backup job sequence number corresponding to the recovery point is greater than or equal to a field value of the file creation version field and less than or equal to a field value of the file deletion version field, from the synthetic metadata. can

The data restoration unit refers to a header number corresponding to a chunk group ID of records corresponding to the recovery time in the composite metadata, selects a header of a chunk according to the header number, and restores the data from the data file. can be configured.

In the backup data synthesis method according to an embodiment of the present invention, data at a recovery point from backup data including full backup data generated by performing a full backup of backup target data and incremental backup data generated by incrementally backing up from the full backup data A backup data synthesis method for synthesizing and restoring, by a virtual backup data generator, by synthesizing the incremental backup metadata related to the incremental backup data with the full backup metadata related to the full backup data to implement virtual backup data generating synthetic metadata for; and extracting, by a data restoration unit, data at the recovery point in time from the full backup data and the incremental backup data based on the virtual backup data implemented by the synthetic metadata, and restoring the data.

The restoring step does not copy the full backup data to restore the data, but extracts the chunk corresponding to the recovery point from the data file based on the synthesized metadata generated in the metadata area to restore the data. may include steps.

The composite metadata may include a revision field for recording a valid backup operation range for each file. The generating of the composite metadata may include changing a field value of the revision field according to a change type of the file.

The revision field may include a file generation version field indicating in which backup job the file was created; and a file deletion version field indicating the number of backup jobs the file is valid for. The generating of the composite metadata may include: determining which change type of the file corresponds to among a plurality of change types including file creation, file deletion, and file modification; when the change type corresponds to the deletion of the file, setting the file deletion version field to a value corresponding to a previous backup job that is the most recent backup job among previous backup jobs; when the change type corresponds to the file creation, setting the file creation version field to a value corresponding to a current backup job and setting the file deletion version field to a maximum value; and when the change type corresponds to the file modification, setting a file deletion version field of the file before modification from the maximum value to a value corresponding to the immediately preceding backup job.

In the generating of the composite metadata, when the change type corresponds to the file modification, a record for the modified file is added and the file creation version field for the modified file is set to a value corresponding to the current backup job. and setting the file deletion version field for the modified file to the maximum value.

The composite metadata may include a chunk group ID field for allocating a chunk group ID to a group of chunks constituting the file, and a header number field for recording a header number corresponding to each chunk. The generating of the composite metadata includes adding a new record to the composite metadata by writing a new field value in the chunk group ID field when the change type of the file corresponds to the file creation or the file modification. step; and when some of the chunk data of the file is changed, the unaltered data among the chunk data does not update the header number field, but a new chunk is created for the changed data among the chunk data, and a new header is added to the header number field. It may include generating a number.

The restoring may include: extracting records corresponding to the recovery point from the composite metadata based on the revision field; and reading data corresponding to the extracted records from a data file to restore the data.

The extracting of the records may include extracting records that satisfy a condition that a backup job sequence number corresponding to the recovery time is greater than or equal to a field value of the file creation version field and less than or equal to a field value of the file deletion version field.

According to an embodiment of the present invention, there is provided a computer-readable recording medium in which a program for executing the backup data synthesis method is recorded.

According to an embodiment of the present invention, there is provided an apparatus and method for synthesizing backup data, and a recording medium for generating synthetic meta data implementing virtual backup data in a meta data area and restoring data at a recovery point based on the synthetic meta data. .

In addition, according to an embodiment of the present invention, a backup data synthesis apparatus and method, and a recording medium capable of minimizing a storage space for data restoration and shortening a data restoration time are provided.

In addition, according to an embodiment of the present invention, after copying the full backup data, the backup data synthesis apparatus and method, and the recording medium capable of restoring data at a desired backup point without the process of repeatedly overwriting the incremental backup data on the full backup data is provided

1 is a conceptual diagram illustrating a process of fully backing up data to be backed up.
FIG. 2 is a conceptual diagram illustrating a process of incrementally backing up changed data from the backup target data that has been fully backed up in FIG. 1 .
3 is a conceptual diagram illustrating a process of restoring data that has been previously incrementally backed up.
4 is a conceptual diagram of a backup data synthesis method according to an embodiment of the present invention.
5 is a block diagram of an apparatus for synthesizing backup data according to an embodiment of the present invention.
6 is a conceptual diagram for explaining a function of a virtual backup data generating unit constituting a backup data synthesis apparatus according to an embodiment of the present invention.
7 is an exemplary diagram of full backup metadata and full backup data generated by the virtual backup data generating unit constituting the backup data synthesis apparatus according to an embodiment of the present invention.
8 is an exemplary diagram of incremental backup metadata and data files generated by the virtual backup data generator constituting the backup data synthesis apparatus according to an embodiment of the present invention.
9 is a conceptual diagram for explaining a function of a virtual backup data generating unit constituting a backup data synthesis apparatus according to an embodiment of the present invention.
10 is an exemplary diagram of virtual backup data generated by the virtual backup data generating unit constituting the backup data synthesis apparatus according to an embodiment of the present invention.
11 is a flowchart of a backup data synthesis method according to an embodiment of the present invention.
12 is an exemplary diagram for explaining a process of restoring data based on synthetic metadata generated according to an embodiment of the present invention.
FIG. 13 is an exemplary diagram for explaining a process of restoring data at a recovery point that has been fully backed up based on the composite metadata shown in FIG. 12 .
FIG. 14 is an exemplary diagram for explaining a process of restoring data in which incrementally backed up data is reflected in full backed up data based on the composite metadata shown in FIG. 12 .

Advantages and features of the present invention and methods of achieving them will become apparent with reference to the embodiments described below in detail in conjunction with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below, but may be implemented in various different forms, and only these embodiments allow the disclosure of the present invention to be complete, and common knowledge in the technical field to which the present invention pertains It is provided to fully inform those who have the scope of the invention, and the present invention is only defined by the scope of the claims. Like reference numerals refer to like elements throughout.

In the present specification, when a part "includes" a certain component, this means that other components may be further included rather than excluding other components unless otherwise stated. As used herein, '~ unit' is a unit for processing at least one function or operation, and may refer to, for example, software, FPGA, or hardware component. A function provided by '~ unit' may be performed separately by a plurality of components, or may be integrated with other additional components. The term '~' in the present specification is not necessarily limited to software or hardware, and may be configured to reside in an addressable storage medium, or may be configured to reproduce one or more processors. Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings.

4 is a conceptual diagram of a backup data synthesis method according to an embodiment of the present invention. In the backup data synthesis method according to an embodiment of the present invention, before synthesizing the full backup data and the incremental backup data in the data area, first, the incremental backup metadata is synthesized with the previous metadata in the metadata area to synthesize metadata. (30) is generated. That is, before synthesizing the incremental backup data 14 ′ with the previous data (eg, the full backup data 14 ), the incremental backup metadata 12 ′ is synthesized with the full backup metadata 12 to the metadata level. is to synthesize the synthetic metadata 30, which is virtual backup data.

Since the metadata is information for managing the storage location and size of the data of the actual file, the size is much smaller than the data of the actual file. Therefore, according to the embodiment of the present invention, the composite metadata 30 (virtual backup image) is generated in the metadata area without the need to copy the data of the actual file for data synthesis, and then the composite metadata 30 Based on this, it is possible to reduce the waste of storage space for data recovery and shorten the time required for data recovery, because only the data in the storage location needs to be extracted and transmitted by checking the storage location of the data corresponding to the recovery point based on the can

5 is a block diagram of an apparatus for synthesizing backup data according to an embodiment of the present invention. Referring to FIG. 5 , the backup data synthesis apparatus 100 according to an embodiment of the present invention may be provided to a backup server for data recovery. Backup data synthesis apparatus 100 according to an embodiment of the present invention includes a virtual backup data generation unit 120, a data restoration unit 140 and a data storage ( 160) may be included.

The virtual backup data generation unit 120 synthesizes the full backup metadata (FMD) and one or more incremental backup metadata (IMD1, IMD2, ..., IMDN) in the metadata area to generate synthetic metadata to create a full backup. You can create virtual backup data for the synthesis of data and incremental backup data. The full backup metadata FMD may be metadata related to the full backup data. The incremental backup metadata (IMD1, IMD2, ..., IMDN) may be metadata related to incremental backup data generated whenever incremental backup is sequentially performed from full backup data.

When synthetic metadata that is virtual backup data is generated by the virtual backup data generation unit 120 , the data restoration unit 140 checks a storage location of data to be extracted from the synthetic metadata, and the pool stored in the data storage 160 . Data may be recovered by sequentially extracting files (each chunk of the files) of data corresponding to the restoration time point among the backup data and the incremental backup data.

6 is a conceptual diagram for explaining a function of a virtual backup data generating unit constituting a backup data synthesis apparatus according to an embodiment of the present invention. Referring to FIGS. 5 and 6 , the virtual backup data generation unit 120 may restore data corresponding to a specific recovery point in the past after multiple backup operations are performed, in a revision field of the synthetic metadata. field) (RF, RT), for each file of data, the file valid backup operation range can be recorded. In the example of FIG. 6 , the revision fields RF and RT are fields indicating the version of the file, and may indicate at which backup job the file is created and is valid until the backup job.

In an embodiment, the virtual backup data generation unit 120 generates the file in the second backup operation through two revision fields (RF, RT) of the file creation version field (rev_from) and the file deletion version field (rev_to). It can be used to express how many backup jobs are valid. The file creation version field (rev_from) may be a field indicating from which backup operation the file was created, and the file deletion version field (rev_to) may be a field indicating up to what backup operation the file is valid.

The right part of the revision fields (RF, RT) in FIG. 6 shows the range of valid backup job IDs for each file in order to help the understanding of the present invention. For example, in the case of file c, it is a file that was added in the 3rd backup operation. At the time it was added, the revision field (RF, RT) had a value of (3, max), but it was deleted in the 7th backup operation and the revision field ( RF, RT) is changed to (3, 6) value. The revision field may be recorded according to the following rules 1 to 4, for example.

Rule 1) If a file newly created in each backup job exists, the file creation version field (rev_from) value of the file has the current backup job ID, and the file deletion version field (rev_to) value has a 'max' value. .

Rule 2) If a deleted file exists in each backup job, the value of the file deletion version field (rev_to) of the file is changed from 'max' to the ID of the most recent backup job (previous backup job) among previous backup jobs. .

Rule 3) If a changed (modified) file exists in each backup job, the file deletion version field (rev_to) value of the file before the change (file b) is changed from 'max' to the previous backup job ID, and the changed file ( A new record is created for file b'), the value of the file creation version field (rev_from) of the changed file (file b') has the current backup job ID, and the file deletion version field (rev_to) of the changed file (file b') ) value has 'max'.

Rule 4) It indicates that each file is a valid file in the interval with the backup job ID [rev_from, rev_to].

In the example shown in FIG. 6 , file a is a file that does not change after being created in backup job 1 (valid from backup job 1 to the present), and file b is backed up 5 times after being created in backup job 1 Files modified by file b' in job (valid from backup job 1 to 4), file c is a file created in backup job 3 and then deleted in backup job 7 (from backup job 3 to 6) is valid until backup job No. 5), file b' is a file created in backup job 5 and then deleted in backup job 8 (valid from backup job 5 to 7), and file d is backup job 5 It is a file that has not changed since it was created (valid from the 5th backup job to the present).

In the example shown in FIG. 6 , 'max' recorded in the file deletion version field rev_to may be defined as the largest value that can be expressed in the corresponding field to indicate that the file is in a valid state so far. Of course, values recorded in the file creation version field rev_from and the file deletion version field rev_to of the revision fields RF and RT are not limited to those shown in FIG. 6 and may be changed into various types.

The first backup operation may be performed by a full backup, and subsequent backup operations may be performed by an incremental backup. For example, when the data backed up in backup job 5 is restored, the virtual backup data generation unit 120 generates full backup metadata generated during backup job 1 and backup jobs 2 to 5, respectively. Composite metadata can be created by synthesizing the incremental backup metadata. Accordingly, valid files (files a, c, b', d) in the 5th backup operation can be recovered.

7 is an exemplary diagram of full backup metadata (syn_dir, syn_file, syn_chunk) and full backup data generated by the virtual backup data generator constituting the backup data synthesis apparatus according to an embodiment of the present invention. In an embodiment, the full backup metadata may include directory metadata (syn_dir), file metadata (syn_file), chunk metadata (syn_chunk), and header metadata (hdr-0 to 6) in a table format.

Directory metadata (syn_dir) includes a directory creation version field (rev_from) corresponding to a revision field indicating creation/deletion information of directories (test, dir1, dir2), a directory deletion version field (rev_to), and a directory ID field (dir_uuid). , the parent directory ID field to which the directory belongs (parent_dir_uuid), and a directory name field (dir_name) may be included.

File metadata (syn_file) includes a file creation version field (rev_from) corresponding to a revision field indicating creation/deletion information of files (file A-D), a file deletion version field (rev_to), a file ID field (file_uuid), and a file The ID field of the directory to which it belongs (in the case of a directory that is not a file, the ID field of the directory) (dir_uuid), the ID field of the parent directory to which the directory belongs (parent_dir_uuid), the ID field of the chunk group that makes up the file (chunk_group_id), It may include a file name field (filename). One file may consist of a single chunk or multiple chunks. The chunk group ID is the ID of a chunk composing one file or an ID common to chunks composing one file. can be

The chunk metadata syn_chunk may include information such as a storage location and size for each chunk. Chunk metadata (syn_chunk) includes a chunk group ID field (chunk_group_id), a repository file ID field (cr_id) where the chunk of a file is stored, a header number field (h_num) that points to one chunk in the repository file, and the corresponding The location field where the chunk exists in the original file (offset), the size field of the chunk (size), the location field (frag_offset) in the header indicating the effective area of the chunk data stored in the repository file, and the chunk data in the header It may include a size field (frag_size). The chunk metadata syn_chunk may be connected to the file metadata syn_file via the chunk group ID field chunk_group_id.

The data file (repository file) includes a header (hdr-0~6) indicating the location where the file data is stored, and the data of the files actually stored (file A data, file B data, file C data-1, file C). data-2, file D data-1, file D data-2, and file D data-3). The header may be composed of an offset field indicating the location of actual data and a size field indicating the size of chunk data to be actually stored.

In the example of the data file shown in FIG. 7 , it can be seen that file C consists of two chunks and file D consists of three chunks. The area in which the two chunk data of file C is stored can be identified by the second header (hdr-2) and the third header (hdr-3), and the area where the three chunk data of file D is stored is the fourth header (hdr). -4), header 5 (hdr-5), and header 6 (hdr-6). Although not shown in FIG. 7 , an additional field for recording stat information of each file may be included in the full backup metadata.

8 is an exemplary diagram of incremental backup metadata (inc_file, inc_chunk) and data files generated by the virtual backup data generator constituting the backup data synthesis apparatus according to an embodiment of the present invention. In an embodiment, the incremental backup metadata may include file metadata (inc_file) and chunk metadata (inc_chunk) in a table format.

The file metadata (inc_file) of the incremental backup metadata includes the backup file ID field (f_uuid) of the changed files (file B, D, E), the chunk group ID field of the files to be backed up (chunk_group_id), and the type of file change (create , delete, update, truncate, rename, stat, etc.) may include an operation ID field (operation), a changed file name field (file_name), and the like.

The chunk metadata (inc_chunk) of the incremental backup metadata may include information such as a change location and a change size for each chunk of the changed files, and only the chunk for the changed content may be recorded. The chunk metadata (inc_chunk) of the incremental backup metadata includes a chunk group ID field (chunk_group_id) indicating a group of chunks to which the changed file belongs, a repository file ID field (cr_id) in which the chunk of the changed file is stored, and one in the repository file. The header number field (h_num) indicating the chunk of It may include a field (fragoffset) and a size field (fragsize) of chunk data in the header. The chunk metadata (inc_chunk) of the incremental backup metadata may be connected to the file metadata (inc_file) via the chunk group ID field (chunk_group_id).

When file B is deleted, file D is modified, and file E is created from previous data (for example, the full backup data shown in Fig. 7), the metadata for the changed file is changed by the incremental backup to the file meta The data is recorded in the data inc_file, and the changed data is stored in the data file and then reflected in the chunk metadata inc_chunk. Change types such as file create, file delete, file update, file truncate, file rename, and stat are recorded in the file change type field (operation). can

In the file metadata (inc_file) and chunk metadata (inc_chunk) illustrated in FIG. 8, only information about changed files is recorded, file B is deleted, file E is created, and file D is modified. . At this time, the generated file E and the modified file D are additionally stored together with the previously stored files in the data file (repository file), and a header (hdr-7) that stores the storage location and size of chunks of the created/modified files. , hdr-8) can be added to the metadata. Even if a file is deleted or modified, the deleted file and the file before modification (file B, D) may not be deleted from the data file (repository file) in case the file is recovered from the recovery point before the deletion or modification of the file. .

9 is a conceptual diagram for explaining a function of a virtual backup data generating unit constituting a backup data synthesis apparatus according to an embodiment of the present invention. 5 and 9, when the incremental backup is performed because some of the chunks constituting the file are changed, the virtual backup data generation unit 120 combines the unchanged chunk and the changed chunk to create a changed file. You can synthesize chunk groups for .

In the example shown in FIG. 9, file A is divided into three chunks and fully backed up and stored in data file number 1 (repository file) (cr_id = 1), respectively, and headers (hdr 1, 2, 3) for each chunk is recorded, and the chunk group ID field (chunk_group_id) value of the chunks is recorded as '1'. Each header contains information for accessing each corresponding chunk.

After file A is fully backed up, if an incremental backup is performed while some of the data of the second chunk among the three chunks of file A is changed, a record for the changed file (file A') will be added to the full backup metadata. can In this case, the changed file A' may be recorded with a chunk group ID field value different from that of the file A before the change, and in the example of FIG. 9 , the chunk group ID field value of the changed file A' is recorded as '2'. In addition, it is recorded in the header 4 (hdr 4) so that the changed chunk of file A' (the second chunk among the three chunks) can be accessed, and the value of the header number field (h_num) of the corresponding chunk is recorded as '4' .

The virtual backup data generating unit 120 may create synthetic metadata for synthetic virtual backup data based on information on chunks recorded in the metadata. The virtual backup data generation unit 120 uses the unaltered chunks 1 and 3 among file A' as it is, and among the second chunks, the unaltered data corresponding to the front of the change area (from 0 to 25 MB data) and the unaltered data (75 to 100 MB data in chunk 2) at the end of the changed area are used as they are, and the changed area (25 to 75 MB data in chunk 2) is 4 Composite metadata can be generated so that data can be synthesized by referring to burn chunks (0 to 50 MB of data in chunk 4).

At this time, the virtual backup data generation unit 120 records the field values in the location field (frag_offset) where the chunk is stored in each header in the composite metadata and the size field (frag_size) of the chunk data in the header, and then restores the data. The unit 140 reads data from a position corresponding to the position field (frag_offset) value of the corresponding chunk to a size corresponding to the size field (frag_size) value, so that the data at the time of restoration can be restored.

10 is an exemplary diagram of virtual backup data generated by the virtual backup data generating unit constituting the backup data synthesis apparatus according to an embodiment of the present invention. 5 and 10 , the virtual backup data generation unit 120 generates virtual backup data (IBD) by meta-synthetic synthesizing incremental backup metadata (inc_file, inc_chuck) with previous metadata. can create

In the example shown in FIG. 10 , file B is a file deleted before the first incremental backup operation after the previous backup (full backup), file E is a file created before the first incremental backup operation after the full backup, and file D is after the full backup It is a file in which some data in chunk 2 of 3 chunks was modified before the first incremental backup operation. The virtual backup data generation unit 120 reads the record of the file metadata (inc_file) of the incremental backup metadata to confirm that file B has been deleted, and since the file is deleted before the second backup (incremental backup) after the first full backup, the previous The value of the file deletion version field (rev_to) corresponding to file B in the file metadata (syn_file) of the metadata is changed from 'max' to '1'. In the case of a deleted file, it is not necessary to add a chunk to the data file, and it is necessary to retain the chunk data corresponding to file B in case the full backup data needs to be recovered later, so the chunk metadata (syn_chunk ) is not reflected in

The virtual backup data generation unit 120 reads the next record of the incremental backup metadata (inc_file, inc_chunk) to confirm that file E is created, and then adds a record corresponding to file E to the file metadata (syn_file) of the previous metadata. is added, and a new field value ('8' in the example of FIG. 10) is recorded in the chunk group ID field of the added record. In addition, since file E is a newly added file in the second backup (incremental backup) after the first full backup, the virtual backup data generation unit 120 records the file creation version field (rev_from) value as '2', Record the deleted version field (rev_to) value as 'max'.

In addition, the virtual backup data generation unit 120 adds a record to the chunk metadata (syn_chunk), and a chunk group ID field (chunk_group_id) value of file E, a data file field (cr_id) value, a newly added record in the added record Stores the header number field (h_num) value corresponding to the chunk (header 7 in the example of FIG. 10 ), the location and size of the file E data stored in the chunk (offset, size, frag_offset, frag_size), and the like.

Again, the virtual backup data generation unit 120 reads the next record of the incremental backup metadata (inc_file, inc_chunk) to check the modification and modification position of file D, and then adds the file D before the change to the file metadata (syn_file) of the previous metadata. Changes the value of the file deletion version field (rev_to) corresponding to the chunk group ID (No. 7 in the example of FIG. 10 ) from 'max' to '1'. In case the full backup data including file D before the change needs to be restored later, chunks corresponding to headers 4 to 6 corresponding to the chunk group ID (chunk group 7) corresponding to file D before the change are not deleted from the chunk metadata (syn_chunk).

The virtual backup data generation unit 120 adds a record corresponding to the changed filed D to the file metadata (syn_file) of the previous metadata, and a new field value (in the example of FIG. 10 ' 9') is recorded. In addition, since the changed file D is a modified file during the second backup (incremental backup) after the first full backup, the virtual backup data generation unit 120 records the file creation version field (rev_from) value as '2', Record the deleted version field (rev_to) value as 'max'.

In addition, the virtual backup data generation unit 120 adds a record corresponding to the modified file D to the chunk metadata (syn_chunk), and a chunk group ID field (chunk_group_id) value of the modified file D to the added record, a data file The field (cr_id) value, the header number field (h_num) value corresponding to the modified chunk (header 8 in the example of FIG. 10), the location and size of the modified file D data stored in the chunk (offset, size, frag_offset, frag_size) and so on.

At this time, the virtual backup data generation unit 120 adds a new chunk corresponding to the header No. 8 only to the modified portion of the modified chunk among the three chunks of file D to the chunk metadata (syn_chunk), and modifies the three chunks. A new chunk is added to the unmodified data of the first chunk corresponding to the unmodified header 4, the third chunk corresponding to the unmodified header 6 among the 3 chunks, and the second chunk corresponding to the header 5. It updates the chunk group ID and the data location and size of the unmodified part of the second chunk while maintaining the state stored in the existing data file.

The virtual backup data generation unit 120 synthesizes incremental backup metadata with previous metadata (full backup metadata) at the metadata level to synthesize composite metadata including composite file metadata (IBD1) and composite chunk metadata (IBD2). data (IBD) can be generated. Later, the data restoration unit 140 utilizes the composite metadata (IBD) as a virtual backup image for data recovery, and checks the valid section of the file through the revision field of the composite metadata (IBD) corresponding to the recovery point. Data (files) can be extracted from the data file to restore the data.

11 is a flowchart of a backup data synthesis method according to an embodiment of the present invention. 5, 10 and 11, after the file is changed after the full backup is completed and the incremental backup is performed, the contents recorded in the incremental backup metadata (inc_file, inc_chunk) are the full backup metadata (syn_file, The process of generating synthetic metadata through synthesis in the metadata area reflected in syn_chunk) will be described.

First, the virtual backup data generation unit 120 reads records from the incremental backup file metadata (inc_file) table one by one to determine the file change type (S10, S20). The type of file change can be defined in the operation field of the incremental backup file metadata (inc_file), for example, create a file, delete a file (delete), modify/truncate a file (update/truncate) , can be defined as any of the values of other types (rename, stat).

If the change type of the incrementally backed up file corresponds to file creation, the virtual backup data generator 120 inserts a new record into the previous file meta data (syn_file) (S30), and the incremental backup chunk meta With reference to the data (inc_chunk), records for a new chunk group are created in the previous chunk metadata (syn_chunk) (S40).

If the change type of the incrementally backed up file corresponds to file deletion, the virtual backup data generation unit 120 returns the file deletion version field (rev_to) value of the corresponding record in the previous file metadata (syn_file). Change to the ID of the previous backup job (S50).

If the change type of the incrementally backed up file corresponds to file update/truncate, the virtual backup data generation unit 120 performs the file deletion version field ( rev_to) value is changed to the ID of the previous backup job, a new record is inserted (S60), and a new record is added to the previous chunk metadata (syn_chunk) by referring to the incremental backup chunk metadata (inc_chunk) and the previous chunk metadata (syn_chunk). Records for the chunk group are created (S70).

If the change type of the incrementally backed up file corresponds to other change types (rename/stat, etc.), the virtual backup data generation unit 120 deletes the file of the record with the name before the change in the previous file metadata (syn_file). The version field (rev_to) value is changed to the ID of the previous backup job, and a record with the changed stat is inserted (S80).

12 is an exemplary diagram for explaining a process of restoring data based on synthetic metadata generated according to an embodiment of the present invention. 12 shows composite metadata and data files generated according to FIG. 10 . FIG. 13 is an exemplary diagram for explaining a process of restoring data at a recovery point that has been fully backed up based on the composite metadata shown in FIG. 12 . FIG. 14 is an exemplary diagram for explaining a process of restoring data in which incrementally backed up data is reflected in full backed up data based on the composite metadata shown in FIG. 12 .

In FIG. 12 , records with a background color in the table mean records inserted or modified during incremental backup. A total of 8 chunks are created in the data file, and each chunk can be accessed through the header number (the value of the h_num field of syn_chunk). Based on the data of the chunk accessed through the header number, data at a later recovery point can be restored.

First, a process of restoring all data backed up (full backup) once will be described with reference to FIGS. 5, 12 and 13 . The data restoration unit 140 may select the records RD1 corresponding to the recovery point based on the order number and revision fields rev_from and rev_to of the backup job corresponding to the recovery point. In the embodiment, the data restoration unit 140 is a backup job sequence number (in the example of FIG. 13 ) corresponding to the desired (input) recovery point of the file creation version field (rev_from) value (the sequence number of the backup job in which the file was initially created) '1') or less and the file deletion version field (rev_to) value (the sequence number of the backup job in which the file is deleted) is greater than or equal to the sequence number of the backup job corresponding to the recovery point may be selected.

In FIG. 13 , records RD1 having a background color in the table mean records selected as objects to be restored at a recovery point (full backup point) by the data restorer 140 . Since the modified file D and file E are files created after the full backup, you can see that they are excluded from the restoration target. The data restoration unit 140 records the recovery point in the composite chunk metadata syn_chunk based on the chunk group ID chunk_group_id of the records RD1 corresponding to the recovery point selected in the composite file metadata syn_file. After finding the data file field (cr_id) and header number field (h_num) of RD1, the repository file is accessed based on the data file number, header number, and the storage location and storage size in the chunk, and the actual After sequentially reading the chunk data stored in the repository file, the data can be restored by transmitting the chunk data.

A process of restoring data at the second backup operation time point (the point of time of incremental backup after full backup) will be described with reference to FIGS. 5, 12 and 14 . The data restoration unit 140 sets the file generation version field (rev_from) value (the backup job sequence number in which the file was initially created) corresponds to the desired (input) recovery point in the backup job sequence number ('2' in the example of FIG. 14 ). It is possible to select records that satisfy the condition that the following and the file deletion version field (rev_to) value (the sequence number of the backup job in which the file is deleted) is equal to or greater than the sequence number of the backup job corresponding to the recovery point.

In FIG. 14 , records RD2 having a background color in the table mean records selected as objects to be restored at the recovery point (the second backup operation point) by the data restorer 140 . It can be seen that file B deleted before the incremental backup operation and file D before the modification modified before the incremental backup operation are excluded from the recovery target data.

The data restoration unit 140 records the recovery point in the composite chunk metadata syn_chunk based on the chunk group ID chunk_group_id of the records RD2 corresponding to the recovery point selected in the composite file metadata syn_file. After finding the data file field (cr_id) and header number field (h_num) of RD2, the repository file is accessed based on the data file number, header number, and the storage location and storage size in the chunk, and the actual After sequentially reading the chunk data stored in the repository file, the data can be restored by transmitting the chunk data.

File D is a backed up file with some data changed when incremental backup is performed. When incremental backup is performed, only the changed data is transferred. When describing the process of referencing data in the turn to restore file D, first, the chunk group ID (No. 9 in the example of FIG. 14) constituting file D through the chunk group ID field (chunk_group_id) of the composite metadata. After checking, the chunks corresponding to the chunk group ID are restored one by one.

The modified file D consists of a total of 5 chunks. Except for the third chunk corresponding to the 8th header, the remaining 4 chunks are all chunks created in the full backup operation. Among the 5 chunks of file D, the first chunk corresponding to header number 4 (shown in blue) is restored as it is because there is no change since it was created in the full backup operation.

The second chunk corresponding to header number 5 of file D (data in the front part of the changed chunk data) (shown in green) has no changes since it was created in the full backup job, so the previous part of the changed data is of synthetic metadata. The data corresponding to the chunk data location and size (frag_offset, frag_size) is read as it is, and the data size (size) is restored to the position (offset) in the file.

The third chunk (indicated in red) corresponding to header number 8 of file D is the chunk that has been changed and backed up in the incremental backup, and the data size at the location (frag_offset) of the changed data stored in the repository file by referring to the 8 header information It reads as much as (frag_size) and restores the data size (size) to the position (offset) in the file.

The fourth chunk (displayed in turquoise) corresponding to header number 5 of file D is a chunk created from the full backup, referring to header information 5, as much as the data size (frag_size) at the data location (frag_offset) stored in the repository file. It is read and restored as much as the data size (size) to the position (offset) of the part after the change. Finally, the fifth chunk (marked in pink) corresponding to header number 6 of file D is restored as it is because there is no change since it was created in the full backup operation.

The backup data restoration method according to the embodiment of the present invention does not copy the full backup data, but virtual data at the metadata level, unlike the conventional method in which the data is restored by repeatedly overwriting the incremental backup data after copying the full backup data. By creating synthetic metadata to implement backup data (virtual backup image), data can be restored based on the synthetic metadata.

Therefore, according to the embodiment of the present invention, storage capacity for copying the full backup data is not required for data recovery, and when data is restored when the data is incrementally backed up several times after the full backup, the incremental backup data is stored several times. Since it is not necessary to sequentially overwrite the full backup data, the storage capacity and data recovery time for data recovery can be drastically reduced.

The embodiments described above may be implemented by a hardware component, a software component, and/or a combination of a hardware component and a software component. For example, the apparatus, methods and components described in the embodiments may include, for example, a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate (FPGA). Array), a Programmable Logic Unit (PLU), a microprocessor, or any other device capable of executing and responding to instructions, may be implemented using one or more general purpose or special purpose computers.

The processing device may run an operating system and one or more software applications running on the operating system. The processing device may also access, store, manipulate, process, and generate data in response to execution of the software. For convenience of understanding, the processing device is sometimes described as being used, but one of ordinary skill in the art will recognize that the processing device includes a plurality of processing elements and/or a plurality of types of processing elements. It will be understood that this may include

For example, the processing device may include a plurality of processors or one processor and one controller. Other processing configurations are also possible, such as a Parallel Processor. The software may include a computer program, code, instructions, or a combination of one or more thereof, which configures the processing device to operate as desired or is independently or collectively processed You can command the device.

The software and/or data may be any kind of machine, component, physical device, virtual equipment, computer storage medium or device, to be interpreted by or to provide instructions or data to the processing device. , or may be permanently or temporarily embody in a transmitted signal wave. The software may be distributed over networked computer systems and stored or executed in a distributed manner. Software and data may be stored in one or more computer-readable recording media.

The method according to the embodiment may be implemented in the form of program instructions that can be executed through various computer means and recorded in a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, and the like, alone or in combination. The program instructions recorded on the medium may be specially designed and configured for the embodiment, or may be known and available to those skilled in the art of computer software.

Examples of the computer-readable recording medium include magnetic media such as hard disks, floppy disks and magnetic tapes, optical media such as CDROMs and DVDs, and ROM, RAM, and flash memory. Hardware devices specially configured to store and execute program instructions, such as, etc. are included. Examples of program instructions include not only machine language codes such as those generated by a compiler, but also high-level language codes that can be executed by a computer using an interpreter or the like. The hardware devices described above may be configured to operate as one or more software modules to perform the operations of the embodiments, and vice versa.

As described above, although the embodiments have been described with reference to the limited embodiments and drawings, various modifications and variations are possible from the above description by those skilled in the art. For example, the described techniques are performed in an order different from the described method, and/or the described components of the system, structure, apparatus, circuit, etc. are combined or combined in a different form than the described method, or other components Or substituted or substituted by equivalents may achieve an appropriate result. Therefore, other implementations, other embodiments, and equivalents to the claims are also within the scope of the following claims.

100: backup data synthesis device
120: virtual backup data generation unit
140: data restoration unit
160: data store

Claims (20)

Based on incremental backup, full backup data generated by performing a full backup of the backup target data and data at the recovery point are synthesized from the backup data including the incremental backup data generated by incremental backup from the full backup data. A backup data synthesis device for restoring, comprising:
a virtual backup data generation unit for synthesizing the incremental backup metadata related to the incremental backup data with the full backup metadata related to the full backup data to generate synthetic metadata for realizing virtual backup data; and
a data restoration unit that extracts and restores data at the recovery point from the full backup data and the incremental backup data based on the virtual backup data implemented by the synthetic metadata;
When a plurality of incremental backup metadata is sequentially generated by incremental backup, the virtual backup data generation unit generates the composite metadata by synthesizing the plurality of incremental backup metadata with the full backup metadata in a metadata area, Backup data synthesis device. According to claim 1,
The data restoration unit,
A backup data synthesis apparatus for restoring data by extracting a chunk corresponding to the recovery point from a data file based on the synthesized metadata generated in a metadata area without copying the full backup data for data restoration. According to claim 1,
The synthetic metadata includes a revision field for recording a valid backup operation range for each file,
The virtual backup data generating unit is configured to change a field value of the revision field according to a change type of the file. 4. The method of claim 3,
The revision field is
a file creation version field indicating in which backup job the file was created; and
Backup data synthesizing device comprising a file deletion version field indicating how many times the file is valid until a backup operation. A backup data synthesizing device for synthesizing and restoring data at a recovery point from backup data including full backup data generated by performing a full backup of the backup target data and incremental backup data generated by incrementally backing up from the full backup data,
a virtual backup data generation unit for synthesizing the incremental backup metadata related to the incremental backup data with the full backup metadata related to the full backup data to generate synthetic metadata for realizing virtual backup data; and
a data restoration unit that extracts and restores data at the recovery point from the full backup data and the incremental backup data based on the virtual backup data implemented by the synthetic metadata;
The data restoration unit,
Instead of copying the full backup data to restore the data, the chunk corresponding to the recovery point is extracted from the data file based on the synthetic metadata generated in the metadata area to restore the data,
The synthetic metadata includes a revision field for recording a valid backup operation range for each file,
The virtual backup data generation unit is configured to change a field value of the revision field according to a change type of the file,
The revision field is
a file creation version field indicating in which backup job the file was created; and
a file deletion version field indicating how many backup jobs the file is valid for;
The virtual backup data generation unit,
determining which change type of the file corresponds to among a plurality of change types including file creation, file deletion, and file modification;
when the change type corresponds to the deletion of the file, setting the file deletion version field to a value corresponding to a previous backup job that is the most recent backup job among previous backup jobs;
when the change type corresponds to the file creation, set the file creation version field to a value corresponding to a current backup job, and set the file deletion version field to a maximum value; and
and, when the change type corresponds to the file modification, set a file deletion version field of the file before modification from the maximum value to a value corresponding to the previous backup job. 6. The method of claim 5,
The virtual backup data generation unit,
When the change type corresponds to the file modification, a record for the modified file is added to set the file creation version field for the modified file to a value corresponding to the current backup job, and and set the file deletion version field to the maximum value. 6. The method of claim 5,
The composite metadata includes a chunk group ID field for allocating a chunk group ID to a group of chunks constituting the file, and a header number field for recording a header number corresponding to each chunk,
The virtual backup data generation unit,
adding a new record to the composite metadata by writing a new field value in the chunk group ID field when the change type of the file corresponds to the file creation or the file modification; and
When some of the chunk data of the file is changed, the unmodified data among the chunk data does not update the header number field, but a new chunk is created for the changed data among the chunk data, and a new header number is entered in the header number field. A backup data synthesizing device configured to create 8. The method of claim 7,
The data restoration unit,
extracting records corresponding to the recovery point from the composite metadata based on the revision field; and
A backup data synthesizing apparatus configured to read data corresponding to the extracted records from a data file and restore the data. 9. The method of claim 8,
The data restoration unit,
and extracting records satisfying a condition in which a backup job sequence number corresponding to the recovery time point is greater than or equal to a field value of the file creation version field and less than or equal to a field value of the file deletion version field from the synthesized metadata. 9. The method of claim 8,
The data restoration unit,
Backup data synthesis, configured to refer to a header number corresponding to a chunk group ID of records corresponding to the recovery point in the synthesis metadata, select a header of a chunk according to the header number, and restore the data from the data file Device. Based on incremental backup, full backup data generated by performing a full backup of the backup target data and data at the recovery point are synthesized from the backup data including the incremental backup data generated by incremental backup from the full backup data. A method of synthesizing backup data to restore, comprising:
generating synthetic metadata for realizing virtual backup data by synthesizing, by a virtual backup data generator, the incremental backup metadata related to the incremental backup data with the full backup metadata related to the full backup data; and
Extracting and restoring, by a data restoration unit, data at the recovery point in the full backup data and the incremental backup data based on the virtual backup data implemented by the synthetic metadata,
The step of generating the synthetic metadata includes:
When a plurality of incremental backup metadata is sequentially generated by incremental backup, the virtual backup data generation unit synthesizes the plurality of incremental backup metadata into the full backup metadata in the metadata area to generate the synthesized metadata. A method of synthesizing backup data, comprising the step of generating. 12. The method of claim 11,
The restoration step is
Backup data comprising the step of extracting the chunk corresponding to the recovery point from a data file based on the synthetic metadata generated in the metadata area without copying the full backup data for data restoration, and restoring the data; synthesis method. 12. The method of claim 11,
The synthetic metadata includes a revision field for recording a valid backup operation range for each file,
The generating of the composite metadata includes changing a field value of the revision field according to a change type of the file. 14. The method of claim 13,
The revision field is
a file creation version field indicating in which backup job the file was created; and
A method for synthesizing backup data, comprising a file deletion version field indicating how many times the file is valid for a backup operation. A backup data synthesis method for synthesizing and restoring data at a recovery point from backup data including full backup data generated by performing a full backup of the backup target data and incremental backup data generated by incrementally backing up from the full backup data,
generating synthetic metadata for realizing virtual backup data by synthesizing, by a virtual backup data generator, the incremental backup metadata related to the incremental backup data with the full backup metadata related to the full backup data; and
Extracting and restoring, by a data restoration unit, data at the recovery point in the full backup data and the incremental backup data based on the virtual backup data implemented by the synthetic metadata,
The restoration step is
To restore the data, extracting the chunk corresponding to the recovery point from the data file based on the synthesized metadata generated in the metadata area without copying the full backup data to restore the data,
The synthetic metadata includes a revision field for recording a valid backup operation range for each file,
The generating of the composite metadata includes changing a field value of the revision field according to a change type of the file,
The revision field is
a file creation version field indicating in which backup job the file was created; and
a file deletion version field indicating how many backup jobs the file is valid for;
The step of generating the synthetic metadata includes:
determining which change type of the file corresponds to among a plurality of change types including file creation, file deletion, and file modification;
setting the file deletion version field to a value corresponding to a previous backup job that is the most recent backup job among previous backup jobs when the change type corresponds to the file deletion;
when the change type corresponds to the file creation, setting the file creation version field to a value corresponding to a current backup job and setting the file deletion version field to a maximum value; and
and setting a file deletion version field of a file before modification from the maximum value to a value corresponding to the previous backup job when the change type corresponds to the file modification. 16. The method of claim 15,
The step of generating the synthetic metadata includes:
When the change type corresponds to the file modification, a record for the modified file is added to set the file creation version field for the modified file to a value corresponding to the current backup job, and and setting the file deletion version field to the maximum value. 16. The method of claim 15,
The composite metadata includes a chunk group ID field for allocating a chunk group ID to a group of chunks constituting the file, and a header number field for recording a header number corresponding to each chunk,
The step of generating the synthetic metadata includes:
adding a new record to the composite metadata by writing a new field value in the chunk group ID field when the change type of the file corresponds to the file creation or the file modification; and
When some of the chunk data of the file is changed, the unmodified data among the chunk data does not update the header number field, but a new chunk is created for the changed data among the chunk data, and a new header number is entered in the header number field. A backup data synthesis method comprising the step of creating a. 18. The method of claim 17,
The restoration step is
extracting records corresponding to the recovery point from the composite metadata based on the revision field; and
A backup data synthesis method comprising the step of reading data corresponding to the extracted records from a data file and restoring the data. 19. The method of claim 18,
Extracting the records comprises:
A backup data synthesis method for extracting records satisfying a condition in which a backup job sequence number corresponding to the recovery point is greater than or equal to a field value of the file creation version field and less than or equal to a field value of the file deletion version field. A computer-readable recording medium in which a program for executing the backup data synthesis method according to any one of claims 11 to 19 is recorded.

Images