CN118585378A - A cloud host concurrent backup method and system based on snapshot - Google Patents

Abstract

The present invention discloses a cloud host concurrent backup method and system based on snapshot, including: obtaining metadata information and uploading it to a backup server, creating a cloud hard disk snapshot; creating a cloud hard disk through the cloud hard disk snapshot, mounting the cloud hard disk to a backup agent, and adding it to a mapping table; after reading the mapping table, the parsing module identifies whether there is an LVM volume group, if so, adds it to the device file and activates the logical volume, and then checks the file system and volume group metadata on the cloud hard disk; parses the valid data of the logical volume or partition, generates a bitmap file, cancels the activation of the logical volume, and removes it from the device file; the backup server creates a block device, copies the valid data to the corresponding block device, creates a block device snapshot, and uninstalls and cleans up the cloud hard disk and the cloud hard disk snapshot. The present invention effectively avoids backup failures caused by volume group conflicts, does not need to rename the volume group, optimizes the system backup process, shortens the backup time, reduces storage occupancy, and improves backup efficiency.

Description

A cloud host concurrent backup method and system based on snapshot

Technical Field

The present invention relates to the technical field of cloud host backup, and in particular to a snapshot-based cloud host concurrent backup method and system.

Background Art

Cloud host backup is generally based on the cloud platform's own snapshot mechanism. Snapshots are created regularly, and cloud hard disks are created from the snapshots and mounted on the backup agent. The backup agent then backs up the cloud hard disk data to the backup server. There are currently two common cloud host backup technology solutions based on snapshots: Solution 1 is to perform a full disk backup of the disk device corresponding to the cloud hard disk without parsing the valid file system data for the mounted cloud hard disk. This way, there is no need to worry about the file system and LVM volume group conflicts can be avoided. Solution 2 is to uniformly rename the LVM volume group on the mounted cloud hard disk, add a specific identifier such as backup, and then parse the valid file system data for backup.

In the above solution 1, since it is a full backup of the cloud hard disk, there is no need to deal with the LVM volume group conflict problem when handling concurrent backups. However, invalid data on the disk will be backed up, resulting in long backup time and large storage space usage. In addition, cloud snapshots guarantee crash consistency. Solution 1 cannot check whether the cloud hard disk file system is normal and whether the volume group metadata is consistent before backup. If there is a problem with the file system or volume group metadata, it needs to be discovered during recovery or disaster recovery. In the above solution 2, since the LVM volume group on the cloud hard disk is renamed uniformly and then the valid data is parsed for backup. In this way, the backed up data contains the metadata of the renamed volume group, rather than the original real data. Therefore, before using the backup data for recovery or disaster recovery, it is necessary to mount it on the preprocessing agent first and change the volume group name back to the original name, that is, remove the specific identifier. If this operation is not performed, the recovery machine or disaster recovery machine cannot start normally. In addition, Solution 2 does not check whether the cloud hard disk file system is normal and whether the volume group metadata is consistent before backup. If there is a problem with the file system or volume group metadata, the backup will fail.

To this end, we have designed a snapshot-based concurrent backup method and system for cloud hosts to solve the above problems.

Summary of the invention

The purpose of the present invention is to solve the problems in the prior art that invalid data on the backup disk leads to long backup time and large storage space occupation, and it is necessary to find out whether the cloud hard disk file system is normal during recovery or disaster recovery. Before using the backup data for recovery or disaster recovery, it is necessary to remove the specific identification. If this operation is not performed, the recovery machine or the disaster recovery machine will not be able to start normally, resulting in low backup efficiency and easy errors. A cloud host concurrent backup method and system based on snapshots is proposed, and its purpose is to parse valid data based on the file system, not to back up invalid data, shorten the backup time, and reduce storage occupancy; through key steps such as volume group activation and file system parsing, and through device files to control which devices the LVM volume group uses, backup failures caused by volume group conflicts under concurrent backup are avoided.

In order to achieve the above object, the present invention adopts the following technical solutions:

A cloud host concurrent backup method based on snapshots includes the following steps:

Step 1: Get metadata information for the selected cloud host and upload it to the backup server, then create cloud disk snapshots for all cloud disks of the cloud host;

Step 2: Create a cloud disk from the cloud disk snapshot, mount the cloud disk to the backup proxy, and add it to the mapping table;

Step 3: Read the mapping table to obtain the disk device corresponding to the cloud hard disk corresponding to a cloud host on the backup proxy. The parsing module identifies whether there is an LVM volume group. If so, add it to the device file and activate the logical volume. Then check the file system on the cloud hard disk. If the file system has an LVM volume group, check the volume group metadata.

Step 4: parse the valid data of the logical volume or partition on the cloud hard disk based on the file system and generate a bitmap file. After the valid data is parsed successfully, if there is an LVM volume group, deactivate the logical volume and remove it from the device file;

Step 5: Notify the backup server to create a block device. The backup agent copies the valid data to the corresponding block device through the bitmap file corresponding to the cloud hard disk. After the copy is completed, notify the backup server to update the block device status and create a block device snapshot, unmount the cloud hard disk, and clean up the cloud hard disk and cloud hard disk snapshot.

As a further preferred embodiment of the present invention, in step 1, obtaining metadata information and creating a cloud hard disk snapshot are implemented by the cloud platform operation module of the backup agent by calling a cloud platform API.

As a further preferred embodiment of the present invention, in step 2, a backup proxy backs up multiple cloud hosts, and when the cloud hard disk corresponding to the current cloud host is mounted, the cloud hard disk is added to the mapping table, and then the cloud hard disk corresponding to the next cloud host is mounted; the mapping table is a mapping table file that records the cloud host, the cloud hard disk, and the disk device information corresponding to the cloud hard disk on the backup proxy.

As a further preferred embodiment of the present invention, in step 3, the parsing module determines whether there is an LVM volume group by reading the volume group metadata on the disk device or partition, or by whether the partition type is 8e; when the disk device or partition is a physical volume, the device path of the disk device or partition is added to the device file, the logical volume under the newly discovered volume group is activated, and then all the partitions and logical volumes of the disk device corresponding to the cloud hard disk, as well as the file system types on the partitions and logical volumes are obtained through the blkid or lsblk command, and the corresponding file system check command is executed, and the file system is checked through the check module. If there is a file system error, the file system is repaired and an alarm is issued. If the file system error cannot be repaired, an alarm is issued and the system exits, and step 4 is no longer executed; the volume group metadata is checked, and the check module checks whether the volume group metadata is consistent by calling the LVM management command. If the volume group metadata is inconsistent, repair is attempted. If the repair is successful, step 4 is continued; if the repair fails, the backup is exited, and an alarm is issued that the volume group metadata is abnormal and cannot be repaired.

As a further preferred embodiment of the present invention, in step 4, when parsing valid data of the logical volume or partition on the cloud hard disk based on the file system, the parsing module queries the file system type on the logical volume or partition on the cloud hard disk, calls different interfaces to parse the corresponding file system valid data, and generates a bitmap file. After successfully parsing the valid data, the logical volume is deactivated and removed from the device file, and the same process is performed on the next cloud hard disk.

As a further preferred embodiment of the present invention, steps 3 and 4 are processed by concurrent locking to ensure that only one newly added volume group is activated at a time during concurrent execution. When the newly added volume group has completed parsing of valid data and removed, the next newly added volume group is activated.

As a further preferred embodiment of the present invention, in step 5, the block device is created by a virtual block device management module in the backup server, the block device adopts a virtual block device or an rbd block device of Ceph, and the volume replication module in the backup agent copies the valid data to the corresponding block device based on the bitmap file through the TCP protocol or the iSCSI protocol. The backup agent starts multiple processes for concurrent backup of the cloud hard disk that has parsed the valid data.

A system for a concurrent backup method of a cloud host based on snapshots, comprising a backup agent and a backup server.

For the cloud platform that needs to be backed up, upload the image, and then create the backup agent through the image. The backup agent includes:

A cloud platform operation module for creating cloud disk snapshots;

A parsing module used to parse whether a device has an LVM volume group;

A checking module for checking file system and volume group metadata, wherein the checking module repairs file system errors and volume group metadata inconsistencies;

A volume replication module for copying valid data in a cloud hard disk to a corresponding block device;

The backup server provides two deployment modes: mirroring and all-in-one. The backup server includes:

A virtual block device management module for creating a block device, wherein the virtual block device management module marks the backed-up block device with a snapshot to create a block device snapshot;

A management program that provides a web interface for users.

As a further preferred embodiment of the present invention, the parsing module is responsible for activating and deactivating the LVM volume group, adding and removing device files, and parsing valid data of the file system on the partition or logical volume.

Compared with the prior art, the beneficial effects of the present invention are as follows: the present invention parses valid data based on the file system, does not back up invalid data, shortens the backup time, and reduces storage occupancy; by mounting the cloud hard disk backup data, reading the volume group metadata on the disk device or partition, to determine whether there is an LVM volume group, adding the device path of the disk device or partition to the device file, activating the logical volume under the volume group, and controlling which devices to use by the LVM through the device file, avoiding backup failures caused by volume group conflicts under concurrent backups, and does not need to rename the volume group, thereby optimizing the system backup process; the present invention checks the cloud hard disk file system and volume group metadata to ensure the reliability and availability of the backup data, and does not use the backup data for recovery or disaster recovery, only to find that the backup data is unavailable. The present invention parses valid data based on the file system, does not back up invalid data, shortens the backup time, and improves backup efficiency.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a schematic diagram of a common cloud host LVM volume group structure;

FIG2 is a schematic diagram of the structure of a common cloud host LVM volume group after expansion;

FIG3 is a flow chart of a snapshot-based concurrent backup method for cloud hosts proposed by the present invention;

FIG4 is a schematic diagram of the system composition of the snapshot-based concurrent backup method for cloud hosts proposed by the present invention;

FIG5 is a schematic diagram of the system execution logic of the snapshot-based concurrent backup method for cloud hosts proposed by the present invention.

DETAILED DESCRIPTION

The technical solutions in the embodiments of the present invention will be described clearly and completely below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than all the embodiments.

With the rapid rise of cloud computing, more and more companies are deploying their businesses on cloud platforms. For the data on the cloud hosts running the business, there is a need for backup, recovery and disaster recovery. At present, snapshot-based cloud host backup is a common solution, but there are still some problems in the specific implementation. Most cloud platforms run cloud hosts on Linux systems, and LVM is a logical volume management function provided by the Linux kernel. It is a logical layer above block devices such as disks or partitions and below the file system. This logical layer consists of physical volumes, volume groups and logical volumes, as shown in Figure 1. For the file system, it shields the underlying disk partition layout, so the volume group capacity can be dynamically adjusted while keeping the existing data unchanged, and then the logical volume on the volume group can be expanded. This expansion method is the most common in Linux systems, see Figure 2.

When backing up cloud hosts concurrently based on snapshots, the cloud hard disks corresponding to multiple cloud hosts will be mounted on the backup proxy. Since cloud hosts are generally the same Linux and most of them are created uniformly through images or templates, their volume group names are often the same. When mounted on the same backup proxy, volume groups conflict, resulting in the volume groups on the subsequently mounted cloud hard disks not being activated, making it impossible to perform effective data parsing based on the file system, and then unable to perform effective data backup. The volume groups in some cloud hosts on the cloud platform have been expanded, that is, the volume groups are on two disks. Since snapshots on the cloud platform are generally based on the disk level, snapshots are also taken of the disks under them for the volume groups that span disks in the cloud host. Because there is a time difference between snapshots of disks, the snapshot data is not at the same time point, and the data may be inconsistent. Therefore, there is a probability that the volume group metadata is inconsistent, resulting in backup failure or problems with the backup data. The backup proxy did not check the data availability of the mounted cloud hard disk, but backed it up directly. If there is a problem with the file system or volume group metadata on the cloud hard disk, the data problem is not discovered immediately during backup. It is not discovered until the cloud host fails and needs to be restored. As a result, no available data can be recovered.

For the defects and drawbacks of the above technical solutions, there are the following feasible alternative solutions: Before backup, it is necessary to modify the boot configuration file such as /boot/grub2/grub.cfg and the file system mount file /etc/fstab of the cloud host to be backed up, and change the device path in the file to the corresponding file system UUID; this is because the UUID of the file system will not be modified with the renaming of the volume group. Then take a snapshot of the cloud host to be backed up, and use the snapshot to generate a cloud hard disk and mount it to the backup agent. The cloud hard disk volume group is activated by default. If there is a volume group conflict, the volume group name is renamed. Then back up valid data based on file system parsing. This solution also modifies the volume group name. Since the original machine is processed, the volume group name does not need to be changed back during disaster recovery or recovery. However, there are certain risks in directly operating the original machine, and general users will not let the backup vendor directly operate the original machine.

As shown in FIG3 , in this embodiment, a better solution is proposed: a cloud host concurrent backup method based on snapshots, the method comprising the following steps:

Step 1: Select the cloud host to be backed up, obtain metadata information for the selected cloud host and upload it to the backup server, and then create cloud disk snapshots for all cloud disks of the cloud host. The above-mentioned acquisition of metadata information and creation of cloud disk snapshots are implemented by the cloud platform operation module of the backup agent by calling the cloud platform API.

Step 2: Create a cloud hard disk from the cloud hard disk snapshot, and then mount the cloud hard disk to the backup proxy. Since a backup proxy can back up multiple cloud hosts, this step needs to be locked. After the cloud hard disk corresponding to the current cloud host is mounted, add the cloud hard disk to the mapping table, and then mount the cloud hard disk corresponding to the next cloud host.

The above creation of cloud hard disks through cloud hard disk snapshots and mounting cloud hard disks to backup agents are also implemented by the cloud platform operation module of the backup agent by calling the cloud platform API. The purpose of locking the cloud hard disk mounted to the backup agent is to ensure that the disk device corresponding to the mounted cloud hard disk obtained by the query on the backup agent is unique and error-free. The backup agent then records the cloud host, cloud hard disk, and the disk device corresponding to the cloud hard disk in the mapping table. The mapping table is a mapping table file that records the cloud host, cloud hard disk, and the disk device information corresponding to the cloud hard disk on the backup agent.

Step 3: Read the mapping table to obtain the disk device corresponding to the cloud hard disk corresponding to a cloud host on the backup proxy. The parsing module identifies whether there is an LVM volume group. If there is an LVM volume group, add it to the device file and activate the logical volume. Then check the file system on the cloud hard disk. If there is an LVM volume group, check the volume group metadata.

The parsing module determines whether there is an LVM volume group by reading the volume group metadata on the disk or partition or by checking whether the partition type is 8e (LVM partition type). If there is an LVM volume group, the physical volume corresponding to the volume group is added to the device file. It should be noted here that the backup agent system is processed, that is, the LVM management program only scans the physical volume in the device file, so the cloud hard disk mounted on the backup agent will not automatically activate the logical volume, which is also to avoid volume group conflicts. When a new physical volume is added to the device file, the parsing module will rescan the volume group and activate the logical volume under the newly discovered volume group. The check module can obtain all the partitions and logical volumes of the disk device corresponding to the cloud hard disk, as well as the above file system types such as ext4 through the blkid command or lsblk command. The check module checks the file system on the partition or logical volume by calling the file system check command corresponding to different file systems, such as fsck.ext4. If there is a file system error, the file system is repaired and an alarm is issued. If the file system error cannot be repaired, an alarm is issued and exited, and step 4 is not executed.

The cloud host has been expanded, and its volume group is on two disks. Since the cloud platform snapshot is at the disk level, there is a probability that the volume group metadata is inconsistent. The inspection module can check whether the volume group metadata is consistent by calling the LVM management command. If the volume group metadata is inconsistent, try to repair it. If the repair is successful, continue to step 4; if the repair fails, exit the backup and warn that the volume group metadata is abnormal and cannot be repaired.

Step 4: For the logical volume or partition on the cloud hard disk, the valid data is parsed based on the file system and a bitmap file is generated. After the valid data is parsed successfully, if there is an LVM volume group, the logical volume is deactivated and removed from the device file.

The volume parsing module queries the file system type on the logical volume or partition on the cloud hard disk, calls different interfaces to parse the corresponding file system valid data, and generates a bitmap file. After successfully parsing the valid data, the logical volume can be deactivated and removed from the device file. The same process is then performed on the next cloud hard disk.

Step 5: Notify the backup server to create a block device. The backup agent copies the valid data to the corresponding block device through the bitmap file corresponding to the cloud hard disk. After the copy is completed, notify the backup server to update the block device status and create a block device snapshot. At the same time, unmount the cloud hard disk and clean up the cloud hard disk and cloud hard disk snapshot.

The above backup server creates a block device through the virtual block device management module, which can be a self-developed virtual block device or a ceph rbd block device. The block device size needs to be the same as or larger than the cloud hard disk to be backed up. The volume replication module in the backup agent writes valid data to the corresponding block device based on the bitmap file through the TCP protocol or iSCSI protocol. For the cloud hard disk that has parsed the valid data, the backup agent can start multiple processes at the same time to perform concurrent backup.

As shown in FIG4 , this embodiment proposes a system for a snapshot-based concurrent backup method for cloud hosts based on the above content. The system mainly includes a backup agent and a backup server, wherein the backup agent includes a cloud platform operation module, a parsing module, a checking module, and a volume replication module; and the backup server includes a virtual block device management module and a management program.

The backup proxy is provided through the image. For the cloud platform that needs to be backed up, upload the image and then create a backup proxy through the image.

The cloud platform operation module is used to create cloud host snapshots and cloud hard disks; the volume parsing module is used to parse whether the device has an LVM volume group. The volume parsing module is also responsible for activating and deactivating the volume group, adding and removing device files, and parsing the valid data of the file system on the partition or logical volume. The inspection module is used to check the file system and volume group metadata. At the same time, the inspection module repairs common file system errors and inconsistent volume group metadata.

The volume replication module is used to copy the valid data in the cloud hard disk to the corresponding block device, and can back up the valid data of the cloud hard disk through a bitmap.

The backup server in this embodiment provides two deployment modes: mirroring and all-in-one. The backup server includes: a virtual block device management module for creating block devices, and a volume replication module in the backup agent writes the backup data to the backup server block device through the TCP protocol or the iSCSI protocol; at the same time, the virtual block device management module marks the block device after the backup is completed with a snapshot to complete the creation of the block device snapshot. The role of the hypervisor in the backup server is to provide a Web interface for users to use.

When the above system is used to execute the snapshot-based concurrent backup method for cloud hosts, the logic of its concurrent backup is shown in FIG5 . Three cloud hosts are selected as instances of concurrent backup. Cloud hard disk snapshots A, B and C are created for the selected cloud hosts A, B and C. Cloud hard disk snapshots A, B and C are used to create and generate cloud hard disks A, B and C as well as cloud hard disk D. After mounting them on the backup agent, they are added to the mapping table. The mapping table is read to obtain the disk devices corresponding to the cloud hard disks corresponding to each cloud host in the mapping table on the backup agent, which are identified and checked by the parsing module and the checking module. The volume replication module in the backup agent is used to write the backup data to the backup server block device through the TCP protocol to complete the snapshot-based concurrent backup task for cloud hosts.

The present invention avoids the problem of backup failure caused by volume group name conflict in concurrent backup by locking key steps such as cloud hard disk backup data mounting, volume group activation and file system parsing, and controlling which devices LVM uses through device files. At the same time, there is no need to rename the volume group, avoiding the need to change the volume group name of the backup data before recovery or disaster recovery.

The present invention can check the cloud hard disk data before backing up, and repair it if any problem is found to ensure that the backed up data is available. Of course, if a serious error occurs in the file system and cannot be repaired, an error report and an alarm are provided to avoid the unavailability of the backed up data, thereby ensuring the reliability and availability of the backup data, and preventing the backup data from being used for recovery or disaster recovery, only to find that the backup data is unavailable. The present invention parses valid data based on the file system, does not back up invalid data, shortens the backup time, and reduces storage usage.

The above description is only a preferred specific implementation manner of the present invention, but the protection scope of the present invention is not limited thereto. Any technician familiar with the technical field can make equivalent replacements or changes according to the technical scheme and inventive concept of the present invention within the technical scope disclosed by the present invention, which should be covered by the protection scope of the present invention.

Claims (9)

1. A cloud host concurrent backup method based on snapshot is characterized by comprising the following steps:

Step 1, acquiring metadata information from a selected cloud host, uploading the metadata information to a backup server, and creating a cloud hard disk snapshot for all cloud hard disks of the cloud host;

step 2, creating a cloud hard disk through a cloud hard disk snapshot, mounting the cloud hard disk to a backup agent, and adding the cloud hard disk to a mapping table;

Step 3, reading a mapping table, obtaining disk equipment corresponding to a cloud hard disk corresponding to a cloud host on a backup agent, identifying whether an LVM volume group exists by an analysis module, adding to equipment files and activating a logic volume if the LVM volume group exists, checking a file system on the cloud hard disk, and checking volume group metadata if the file system exists in the LVM volume group;

Step 4, analyzing the effective data of the logical volumes or the partitions on the cloud hard disk based on the file system, generating a bitmap file, and after the effective data is successfully analyzed, deactivating the logical volumes and removing the logical volumes from the equipment file if the LVM volume group exists;

And 5, notifying a backup server to create block equipment, copying the effective data to the corresponding block equipment by the backup agent through the bitmap file corresponding to the cloud hard disk, notifying the backup server to update the state of the block equipment after copying is completed, creating a block equipment snapshot, unloading the cloud hard disk, and cleaning the cloud hard disk and the cloud hard disk snapshot.

2. The snapshot-based cloud host concurrent backup method according to claim 1, wherein in step 1, metadata information is acquired and a cloud hard snapshot is created, and the cloud platform operation module of the backup agent is implemented by calling a cloud platform API.

3. The method for concurrent backup of cloud hosts based on snapshots as defined in claim 1, wherein in step 2, a backup agent backs up a plurality of cloud hosts, and mounts a cloud hard disk corresponding to a previous cloud host after completing the mounting of the cloud hard disk corresponding to the previous cloud host, and mounts a cloud hard disk corresponding to a next cloud host after adding the cloud hard disk to the mapping table; the mapping table is a mapping table file for recording disk equipment information corresponding to the cloud host, the cloud hard disk and the cloud hard disk on the backup agent.

4. The snapshot-based cloud host concurrent backup method according to claim 1, wherein in step 3, the parsing module determines whether there is an LVM volume group by reading volume group metadata on a disk device or a partition, or by whether a partition type is 8 e; when the disk device or the partition is a physical volume, adding a device path of the disk device or the partition to a device file, activating a logic volume under a newly found volume group, acquiring all partitions and logic volumes of the disk device corresponding to the cloud hard disk and file system types on the partitions and the logic volumes through blkid or lsblk commands, executing a corresponding file system checking command, checking the file system through a checking module, repairing the file system if a file system error exists, alarming, and if the file system error cannot be repaired, alarming and exiting, and not executing the step 4; checking the volume component data, wherein the checking module checks whether the volume component data is consistent by calling an LVM management command, if the volume component data is inconsistent, the repairing is tried, and if the repairing is successful, the step 4 is continuously executed; if the restoration fails, the backup is exited, and the abnormal volume component data cannot be restored.

5. The method for concurrent backup of a cloud host based on snapshot as claimed in claim 1, wherein in step 4, when the valid data is analyzed on a logical volume or a partition on a cloud hard disk based on a file system, the analysis module queries a file system type on the logical volume or the partition on the cloud hard disk, calls different interfaces to analyze the corresponding valid data of the file system, produces bitmap files, and after the valid data is successfully analyzed, deactivates the logical volume, removes the valid data from the device files, and performs the same process on the next cloud hard disk.

6. The method for concurrent backup of a snapshot-based cloud host of claim 1, wherein step 3 and step 4 are used to ensure that only one newly added volume group is activated at a time under concurrent execution through concurrent locking processing, and when the analysis of valid data by the newly added volume group is completed and removed, the next newly added volume group is deactivated.

7. The snapshot-based cloud host concurrent backup method according to claim 1, wherein in step 5, the block device is created through a virtual block device management module in a backup server, the block device adopts a virtual block device or ceph rbd block device, a volume copy module in a backup agent copies valid data to a corresponding block device based on bitmap files through TCP protocol or iSCSI protocol, and the backup agent simultaneously starts a plurality of processes for a cloud hard disk with resolved valid data to perform concurrent backup.

8. A system for concurrent backup method based on snapshot cloud host as in any one of claims 1-7, comprising a backup agent and a backup server,

And uploading the mirror image to the cloud platform needing to be backed up, and creating the backup agent through the mirror image, wherein the backup agent comprises:

the cloud platform operation module is used for creating a cloud hard disk snapshot;

the analyzing module is used for analyzing whether the LVM volume group exists in the equipment or not;

a checking module for checking file system and volume component metadata, the checking module repairing file system errors and volume component metadata inconsistencies;

The volume copying module is used for copying the valid data in the cloud hard disk to the corresponding block equipment;

The backup server provides two deployment modes of a mirror image and an all-in-one machine, and comprises:

the virtual block device management module is used for creating block devices, marking the snapshot of the block devices with which the backup is completed, and creating the snapshot of the block devices;

And a hypervisor for providing a Web interface for use by a user.

9. The system of snapshot-based cloud-host concurrent backup method of claim 8, wherein the parsing module is responsible for activation, deactivation of volume groups, addition and removal of device files, and parsing valid data of a file system on a partition or logical volume.