Backup file recovery verification method and device, server and storage medium

Abstract

The application provides a backup file recovery verification method and device, a server and a storage medium, comprising: obtaining a mapping relationship list corresponding to a target backup server and a deployment file corresponding to the mapping relationship list through an auxiliary container; running the deployment file to control the initialization container to pull a backup file from the target backup server based on the mapping relationship list and control the MySQL container to perform an import operation on the backup file; and performing recovery verification on the backup file according to the current state of the MySQL container to obtain a recovery verification result. The application can significantly improve the automation degree of recovery verification on the backup file, thereby significantly improving operation and maintenance quality and efficiency, and effectively improving the utilization rate of the container cluster.

Description

Technical Field

[0001] This invention relates to the field of Internet technology, and in particular to a method, apparatus, server, and storage medium for restoring and verifying backup files. Background Technology

[0002] Currently, backing up and restoring MySQL databases is a routine task in operations and maintenance, especially restoration verification, which is a necessary and essential step. Generally, this involves transferring the backup file to the MySQL recovery host, then performing the database import operation, and manually verifying the restoration's completion and the backup's integrity after the import is finished. Existing technology requires manual intervention in MySQL database backup and restoration verification, resulting in poor operation and maintenance quality and low efficiency. Furthermore, the MySQL server needs to be retained for data restoration, leading to low utilization of the MySQL server when no restoration operation is performed, resulting in resource waste. Summary of the Invention

[0003] In view of this, the purpose of the present invention is to provide a method, apparatus, server and storage medium for the recovery and verification of backup files, which can significantly improve the automation level of backup file recovery and verification, thereby significantly improving operation and maintenance quality and efficiency, and can also effectively improve the utilization rate of container clusters.

[0004] In a first aspect, embodiments of the present invention provide a method for restoring and verifying backup files. The method is applied to a container cluster, wherein the container cluster deploys an auxiliary container, an initialization container, and a MySQL container. The method includes: obtaining a mapping relationship list corresponding to a target backup server and a deployment file corresponding to the mapping relationship list through the auxiliary container; running the deployment file to control the initialization container to pull backup files from the target backup server based on the mapping relationship list, and controlling the MySQL container to perform an import operation on the backup files; and performing a restoration verification on the backup files according to the current state of the MySQL container to obtain a restoration verification result.

[0005] In one implementation, the step of obtaining a mapping relationship list corresponding to the target backup server and a deployment file corresponding to the mapping relationship list through the auxiliary container includes: controlling the auxiliary container to pull backup files and database identifiers from the target backup server according to a preset period; constructing a mapping relationship list based on the remote absolute path corresponding to the backup file and the database identifier; wherein the mapping relationship list includes the mapping relationship between the remote absolute path and the database identifier; generating deployment files based on the mapping relationship list; wherein the number of deployment files is related to the number of backup files and the number of database identifiers in the mapping relationship list.

[0006] In one implementation, before running the deployment file, the method further includes: determining whether the number of database identifiers is greater than a preset threshold; if not, determining the number of database identifiers as the number of containers running in parallel; if yes, determining the number of containers running in parallel by multiplying the number of database identifiers by a preset container running coefficient; wherein the number of containers running in parallel is used to limit the number of parallel executions of the deployment file.

[0007] In one implementation, the step of running the deployment file includes: selecting a target deployment file from the deployment files according to the number of containers running in parallel, and running each target deployment file; after each target deployment file has been run, continuing to select target deployment files from the deployment files other than the target deployment files according to the number of containers running in parallel, until each deployment file has been run.

[0008] In one implementation, the step of pulling backup files from the target backup server based on the mapping list includes: pulling backup files from the target backup server according to the remote absolute path in the mapping list; converting the backup files into SQL format; and releasing the SQL format backup files to the recovery directory of the MySQL container.

[0009] In one embodiment, the step of performing an import operation on the backup file includes: performing an import operation on the backup file in the SQL format stored in the recovery directory according to the database identifier in the mapping relationship list.

[0010] In one implementation, the step of performing a recovery verification on the backup file based on the current state of the MySQL container to obtain a recovery verification result includes: when the current state of the MySQL container is detected as a completed running state, determining that the backup file imported by the MySQL container has passed the recovery verification; wherein, the recovery verification result includes successful recovery verification and unsuccessful recovery verification.

[0011] Secondly, embodiments of the present invention also provide a backup file recovery verification device, which is applied to a container cluster. The container cluster deploys an auxiliary container, an initialization container, and a MySQL container. The device includes: an acquisition module, used to acquire a mapping relationship list corresponding to a target backup server and a deployment file corresponding to the mapping relationship list through the auxiliary container; a running module, used to run the deployment file to control the initialization container to pull backup files from the target backup server based on the mapping relationship list, and to control the MySQL container to perform an import operation on the backup files; and a verification module, used to perform recovery verification on the backup files according to the current state of the MySQL container to obtain a recovery verification result.

[0012] Thirdly, embodiments of the present invention also provide a server, including a processor and a memory, the memory storing computer-executable instructions executable by the processor, the processor executing the computer-executable instructions to implement the method described in any of the first aspects.

[0013] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing computer-executable instructions, which, when invoked and executed by a processor, cause the processor to implement the method described in any of the first aspects.

[0014] This invention provides a method, apparatus, server, and storage medium for restoring and verifying backup files. Applied to a container cluster, the cluster deploys an auxiliary container, an initialization container, and a MySQL container. First, the auxiliary container obtains a mapping list corresponding to the target backup server and a deployment file corresponding to the mapping list. Then, the deployment file is run to control the initialization container to pull backup files from the target backup server based on the mapping list and to control the MySQL container to perform an import operation on the backup files. Finally, based on the current state of the MySQL container, the backup files are restored and verified to obtain the restoration verification result. This method automatically restores and verifies backup files through the container cluster, reducing manual intervention and significantly improving the automation level of backup file restoration and verification. This significantly improves operational quality and efficiency, and also effectively increases the utilization rate of the container cluster.

[0015] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained in accordance with the structures particularly pointed out in the description, claims and drawings.

[0016] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0017] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0018] Figure 1 A flowchart illustrating a method for restoring and verifying backup files provided in an embodiment of the present invention;

[0019] Figure 2 A flowchart illustrating another method for restoring and verifying backup files provided in an embodiment of the present invention;

[0020] Figure 3 This is a schematic diagram of the structure of a backup file recovery and verification device provided in an embodiment of the present invention;

[0021] Figure 4 This is a schematic diagram of the structure of a server provided in an embodiment of the present invention. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below in conjunction with the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0023] Currently, restoring and verifying backup files requires manual operation, and a MySQL server needs to be maintained for this purpose. When no restoration is being performed, the MySQL server utilization is low, resulting in wasted resources. Therefore, this invention provides a method, apparatus, server, and storage medium for restoring and verifying backup files. This significantly improves the automation level of backup file restoration and verification, thereby significantly improving operational quality and efficiency, and also effectively increasing the utilization rate of container clusters.

[0024] To facilitate understanding of this embodiment, a method for restoring and verifying backup files disclosed in this invention will first be described in detail. This method is applied to a container cluster, which deploys an auxiliary container, an initialization container, and a MySQL container. See [link to relevant documentation]. Figure 1The diagram shows a flowchart of a method for restoring and verifying backup files. This method mainly includes the following steps S102 to S106:

[0025] Step S102: Obtain the mapping relationship list corresponding to the target backup server and the deployment file corresponding to the mapping relationship list through the auxiliary container. The target backup server may store database backup files (referred to as backup files), the mapping relationship list includes the mapping relationship between the remote absolute path of the backup files and the database identifier, and the deployment file is a YAML file. In one implementation, the auxiliary container (also referred to as the auxiliary POD) pulls the latest backup files and database names from the target backup server according to a preset period, constructs the mapping relationship between the remote absolute path of the backup files and the database name to obtain the mapping relationship list, and then generates at least one deployment file based on the mapping relationship list.

[0026] Step S104: Run the deployment file to control the initialization container to pull backup files from the target backup server based on the mapping relationship list, and control the MySQL container to perform import operations on the backup files. In one implementation, the deployment file can be run as a job. The deployment file mainly includes using the initialization container to pull backup files from the target backup server according to the remote absolute path in the mapping relationship list, and sharing them with the recovery directory of the MySQL container. The MySQL container will then perform import operations on the backup files in the recovery directory according to the database identifier in the mapping relationship list.

[0027] Step S106: Based on the current state of the MySQL container, perform a recovery verification on the backup file to obtain the recovery verification result. The current state indicates whether the MySQL container has completed its operation, and the recovery verification result reflects whether the backup file has passed the recovery verification. In one implementation, when the current state of the MySQL container is "completed," the backup file is determined to have passed the recovery verification; conversely, when the current state of the MySQL container is "not yet complete," the backup file is determined to have failed the recovery verification.

[0028] The backup file recovery verification method provided in this embodiment of the invention automatically performs recovery verification on backup files through container clusters, reducing manual intervention and significantly improving the automation level of backup file recovery verification, thereby significantly improving operation and maintenance quality and efficiency. In addition, it can also effectively improve the utilization rate of container clusters.

[0029] In one embodiment, this invention provides an implementation of the aforementioned step S102. When performing the step of obtaining the mapping relationship list corresponding to the target backup server through the auxiliary container, and the deployment file corresponding to the mapping relationship list, the following steps a to c can be referred to:

[0030] Step a: The auxiliary container is controlled to pull backup files and database identifiers from the target backup server according to a preset cycle. The database identifier can be the database name, database ID (Identity Document), etc. In one implementation, running the auxiliary POD is a scheduled task. By additionally running the auxiliary POD in the container cluster, this auxiliary POD will obtain the latest database backup files and database identifiers from the target backup server. In a specific implementation, the auxiliary POD can pull the latest backup files from the target backup server based on parameters such as filename and timestamp; the database identifier will be included in the backup files.

[0031] Step b: Construct a mapping list based on the remote absolute path and database identifier corresponding to the backup file. This mapping list includes the mapping relationships between the remote absolute path and the database identifier.

[0032] Step c: Generate deployment files based on the mapping relationship list. The number of deployment files is related to the number of backup files and the number of database identifiers in the mapping relationship list. In one implementation, a YAML file can be generated based on the remote absolute path and database identifier in the mapping relationship list. The remote absolute path is used to provide the path required for the initialization container to pull backup files when running the YAML file, and the database identifier is used to provide the database name required for the MySQL container to import backup files when running the YAML file. Additionally, the number of pulled backup files can be counted. The number of YAML files is related to the number of backup files and the number of database identifiers; for example, the number of YAML files corresponds one-to-one with the number of backup files. For instance, assuming there are N backup files, N YAML files can be generated, each YAML file used to perform a recovery task on one backup file.

[0033] Considering that an excessive number of backup files will lead to significant pressure on the container cluster, this embodiment of the invention proposes limiting the number of concurrent executions of deployment files. Specifically: (1) Determine whether the number of database identifiers is greater than a preset threshold; (2) If not, determine the number of database identifiers as the number of containers running in parallel; (3) If yes, determine the number of containers running in parallel by multiplying the number of database identifiers by a preset container running coefficient; wherein, the number of containers running in parallel is used to limit the number of concurrent executions of deployment files. In one example, the preset threshold can be determined based on the number of nodes in the container cluster. The preset threshold should be less than or equal to the number of nodes. For example, when the number of database identifiers or the number of backup files is greater than the number of nodes, the containers will run at a preset container running coefficient (e.g., 0.4) to avoid putting pressure on the container cluster.

[0034] For example, suppose there are 10 load balancer nodes in the container cluster. If there are 8 database identifiers that need to be restored, theoretically, we could select 8 load balancer nodes out of the 10 and run a POD on each of them. However, in a real-world environment, this might put additional pressure on the container cluster's operation.

[0035] For example, if the preset threshold is 6, and since 8 database identifiers are greater than the preset threshold, the number of PODs running simultaneously can be reduced by setting a container running coefficient of 5. If the preset container running coefficient is 0.4, then 0.4 * 8 = 3.2, which determines that the number of containers running in parallel is 4, that is, the number of deployment files executed in parallel is 4.

[0036] If there are currently 5 database identifiers that need to be restored, since the number of database identifiers is less than the preset threshold, it can be directly determined that the number of containers running in parallel is 5, which means the number of deployment files executed in parallel is 5.

[0037] 0. Based on the foregoing embodiments, this embodiment of the invention also provides an implementation method for running deployment files. Target deployment files can be selected from the deployment files according to the number of containers running in parallel, and each target deployment file can be run. After each target deployment file has finished running, target deployment files can be selected from the deployment files other than the target deployment files according to the number of containers running in parallel.

[0038] The process continues until each deployment file has been executed. For example, when the number of containers running in parallel is 45, it can be determined that 4 nodes are selected from the container cluster to run 4 YAML files simultaneously. Once the 4 YAML files have finished running, another 4 YAML files will be selected from the remaining YAML files, and these 4 selected YAML files will continue to be run simultaneously by the 4 nodes until all YAML files have been executed.

[0039] When running each YAML file, the container cluster begins deployment based on the YAML file. The deployment content of the YAML0 file mainly includes: controlling the initialization container to pull backup files from the target backup server based on the mapping relationship list, and controlling the MySQL container to perform import operations on the backup files. For ease of understanding, this embodiment of the invention first provides an implementation method for pulling backup files from the target backup server based on the mapping relationship list, which can be based on remote...

[0040] The absolute path is used to pull the backup file from the target backup server, and then the backup file is converted to SQL5 (Structured Query Language) format. This SQL-formatted backup file is then released to the MySQL container's recovery directory. In practical applications, the container initializes by pulling the backup file from the backup server to the local POD based on the remote absolute path, decompressing the data into SQL format, and sharing this file with the subsequent MySQL container recovery directory.

[0041] To facilitate understanding, this embodiment of the invention also provides an implementation method for performing an import operation on backup files. This method can perform an import operation on SQL-formatted backup files stored in the recovery directory based on the database identifier in the mapping relationship list. In specific implementation, the MySQL container starts the import operation based on the database name and backup file upon creation. The core code is as follows: command: ["sh","-c","mysql-uroot-pPassword-hlocalhost] < / opt / back_uaa_20221009.sql"]。

[0042] In one embodiment, this invention also provides an implementation of step S106, where, during the step of performing recovery verification on the backup file based on the current state of the MySQL container to obtain the recovery verification result, when the current state of the MySQL container is detected as "running complete," it is determined that the backup file imported by the MySQL container has passed the recovery verification; wherein, the recovery verification result includes "passed recovery verification" and "failed recovery verification." In a specific implementation, when the final state of the MySQL container changes to "completed," it indicates that the running is complete and the data backup recovery verification has passed. The "Completed" state is a dedicated state maintained by the container cluster for the cronjob class, i.e., the scheduled task class. When a job completes its scheduled task normally, the container is marked to this state.

[0043] In one implementation, if the recovery process encounters an anomaly, the task scheduler will automatically restart until the maximum number of retries is reached. If the recovery still fails after reaching the maximum number of retries, it can be determined that the recovery has failed. As shown in the previous embodiments, the backup file has been correctly pulled to the local machine, thus ruling out problems with the original file and determining that the backup data is incorrect.

[0044] To facilitate understanding of the foregoing embodiments, this invention provides an application example of a backup file recovery verification method, see [link to example]. Figure 2 The diagram shows another process for restoring and verifying backup files. This method mainly includes the following steps S202 to S212:

[0045] Step S202: Run the scheduled task POD in the container cluster. The scheduled task POD is the auxiliary container mentioned above.

[0046] Step S204: Obtain the backup file and database name mapping relationship from the backup server.

[0047] Step S206: Calculate the total backup file data.

[0048] Step S208: Start the POD initialization container, pull the backup files, and release them to the shared directory of the MySQL container. In one implementation, multiple YAML files can be run in parallel.

[0049] Step S210: The MySQL container begins data import.

[0050] Step S212, resource reclamation. Resource reclamation can be understood as ensuring that no junk files are generated in the cluster during the entire recovery process. All data is retained in the PODs on the cluster worker nodes. Once the task is completed, the PODs are automatically deleted, along with the data files generated from the recovery. This recovery process also effectively improves the resource utilization of the container cluster, especially when container resource utilization is low. In contrast, traditional virtual machine backup and recovery methods retain the recovered data in the virtual machine, resulting in dirty data on the original recovery system and making subsequent data recovery difficult.

[0051] In summary, the backup file recovery verification method provided in this embodiment of the invention can automatically perform recovery verification on MySQL backup files through container clusters, improving operation and maintenance quality and efficiency, reducing manual intervention, increasing the utilization rate of container clusters, and the entire process will not generate any dirty data.

[0052] Regarding the backup file recovery and verification method provided in the foregoing embodiments, this embodiment of the invention provides a backup file recovery and verification device. This device is applied to a container cluster, which deploys an auxiliary container, an initialization container, and a MySQL container. See [link to documentation]. Figure 3 The diagram shows a structural schematic of a backup file recovery and verification device, which mainly includes the following parts:

[0053] The acquisition module 302 is used to acquire the mapping relationship list corresponding to the target backup server and the deployment file corresponding to the mapping relationship list through the auxiliary container;

[0054] The execution module 304 is used to run the deployment file to control the initialization container to pull backup files from the target backup server based on the mapping relationship list, and to control the MySQL container to perform import operations on the backup files;

[0055] The verification module 306 is used to perform recovery verification on the backup file based on the current state of the MySQL container to obtain the recovery verification result.

[0056] The backup file recovery and verification device provided in this embodiment of the invention automatically performs recovery and verification of backup files through container clusters, reducing manual intervention and significantly improving the automation level of backup file recovery and verification, thereby significantly improving operation and maintenance quality and efficiency. In addition, it can also effectively improve the utilization rate of container clusters.

[0057] In one embodiment, the acquisition module 302 is further configured to: control the auxiliary container to pull backup files and database identifiers from the target backup server according to a preset period; construct a mapping relationship list based on the remote absolute path and database identifier corresponding to the backup file; wherein the mapping relationship list includes the mapping relationship between the remote absolute path and the database identifier; generate deployment files based on the mapping relationship list; wherein the number of deployment files is related to the number of backup files and the number of database identifiers in the mapping relationship list.

[0058] In one embodiment, the above-mentioned device further includes a quantity determination module, used to: determine whether the number of database identifiers is greater than a preset threshold; if not, determine the number of database identifiers as the number of containers running in parallel; if so, determine the number of containers running in parallel by multiplying the number of database identifiers by a preset container running coefficient; wherein, the number of containers running in parallel is used to limit the number of deployment files executed in parallel.

[0059] In one implementation, the running module 304 is further configured to: select target deployment files from the deployment files according to the number of containers running in parallel, and run each target deployment file; after each target deployment file has been run, continue to select target deployment files from the deployment files other than the target deployment files according to the number of containers running in parallel, until each deployment file has been run.

[0060] In one implementation, the execution module 304 is further configured to: pull backup files from the target backup server according to the remote absolute path in the mapping relationship list; convert the backup files into SQL format; and release the SQL format backup files to the recovery directory of the MySQL container.

[0061] In one implementation, the running module 304 is further configured to: perform an import operation on the SQL-formatted backup files stored in the recovery directory based on the database identifier in the mapping relationship list.

[0062] In one implementation, the verification module 306: when the current status of the MySQL container is detected as "run completed", it determines that the backup file imported by the MySQL container has passed the recovery verification; wherein, the recovery verification result includes "passed recovery verification" and "failed recovery verification".

[0063] The device provided in this embodiment of the invention has the same implementation principle and technical effect as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the device embodiment can be referred to the corresponding content in the aforementioned method embodiment.

[0064] This invention provides a server, specifically, the server includes a processor and a storage device; the storage device stores a computer program, which, when run by the processor, executes the method described in any of the above embodiments.

[0065] Figure 4 This is a schematic diagram of the structure of a server provided in an embodiment of the present invention. The server 100 includes: a processor 40, a memory 41, a bus 42 and a communication interface 43. The processor 40, the communication interface 43 and the memory 41 are connected through the bus 42. The processor 40 is used to execute executable modules, such as computer programs, stored in the memory 41.

[0066] The memory 41 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 43 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc.

[0067] Bus 42 can be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 4 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0068] The memory 41 is used to store programs. After receiving an execution instruction, the processor 40 executes the program. The method executed by the device for defining the flow process disclosed in any of the foregoing embodiments of the present invention can be applied to the processor 40 or implemented by the processor 40.

[0069] Processor 40 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 40 or by instructions in software form. Processor 40 can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this invention can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 41. The processor 40 reads the information in memory 41 and, in conjunction with its hardware, completes the steps of the above method.

[0070] The computer program product of the readable storage medium provided in the embodiments of the present invention includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the foregoing method embodiments. For specific implementation, please refer to the foregoing method embodiments, which will not be repeated here.

[0071] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0072] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for restoring and verifying backup files, characterized in that, The method is applied to a container cluster, wherein the container cluster deploys auxiliary containers, an initialization container, and a MySQL container, and the method includes: The auxiliary container obtains a mapping list corresponding to the target backup server and a deployment file corresponding to the mapping list, including: controlling the auxiliary container to pull backup files and database identifiers from the target backup server according to a preset period; constructing a mapping list based on the remote absolute path corresponding to the backup file and the database identifier; wherein the mapping list includes the mapping relationship between the remote absolute path and the database identifier; generating deployment files based on the mapping list, the number of deployment files corresponding one-to-one with the number of backup files, the remote absolute path being used to provide the path required by the initialization container to pull the backup file when running the deployment file, the database identifier being used to provide the database name required by the MySQL container to import the backup file when running the deployment file, and each deployment file being used to perform a recovery task on one backup file; The method further includes: determining whether the number of database identifiers is greater than a preset threshold; if not, determining the number of database identifiers as the number of containers running in parallel; if yes, determining the number of containers running in parallel by multiplying the number of database identifiers by a preset container running coefficient; wherein, the number of containers running in parallel is used to limit the number of parallel executions of the deployment file; The deployment file is run based on the number of parallel executions of the deployment file, so as to control the initialization container to pull the backup file from the target backup server based on the mapping relationship list, and to control the MySQL container to perform an import operation on the backup file; Based on the current state of the MySQL container, the backup file is restored and verified to obtain the restoration verification result.

2. The method according to claim 1, characterized in that, The steps for running the deployment file include: Select a target deployment file from the deployment files according to the number of containers running in parallel, and run each of the target deployment files; After each target deployment file completes execution, target deployment files are selected from deployment files other than the target deployment file according to the number of containers running in parallel, until each deployment file has completed execution.

3. The method according to claim 1, characterized in that, The step of retrieving backup files from the target backup server based on the mapping list includes: Based on the remote absolute path in the mapping list, retrieve the backup file from the target backup server; The backup file is converted to SQL format, and the SQL format backup file is released to the recovery directory of the MySQL container.

4. The method according to claim 3, characterized in that, The steps for performing an import operation on the backup file include: Based on the database identifier in the mapping list, perform an import operation on the backup file in the SQL format stored in the recovery directory.

5. The method according to claim 1, characterized in that, The steps of performing recovery verification on the backup file based on the current state of the MySQL container to obtain the recovery verification result include: When the current status of the MySQL container is detected as "run completed", it is determined that the backup file imported by the MySQL container has passed the recovery verification; wherein, the recovery verification result includes "passed recovery verification" and "failed recovery verification".

6. A backup file recovery and verification device, characterized in that, The apparatus is used to implement the backup file recovery verification method according to claim 1, and is applied to a container cluster, wherein the container cluster deploys an auxiliary container, an initialization container, and a MySQL container, and the apparatus includes: The acquisition module is used to acquire a mapping relationship list corresponding to the target backup server and a deployment file corresponding to the mapping relationship list through the auxiliary container. This includes: controlling the auxiliary container to pull backup files and database identifiers from the target backup server according to a preset period; constructing a mapping relationship list based on the remote absolute path corresponding to the backup file and the database identifier; wherein the mapping relationship list includes the mapping relationship between the remote absolute path and the database identifier; generating deployment files based on the mapping relationship list, wherein the number of deployment files corresponds one-to-one with the number of backup files, the remote absolute path is used to provide the path required by the initialization container to pull the backup file when running the deployment file, the database identifier is used to provide the database name required by the MySQL container to import the backup file when running the deployment file, and each deployment file is used to perform a recovery task on one backup file. It also includes a quantity determination module, used to: determine whether the number of database identifiers is greater than a preset threshold; if not, determine the number of database identifiers as the number of containers running in parallel; if yes, determine the number of containers running in parallel by multiplying the number of database identifiers by a preset container running coefficient; wherein, the number of containers running in parallel is used to limit the number of parallel executions of the deployment file; The running module is used to run the deployment file based on the number of parallel executions of the deployment file, so as to control the initialization container to pull the backup file from the target backup server based on the mapping relationship list, and control the MySQL container to perform an import operation on the backup file; The verification module is used to perform recovery verification on the backup file based on the current state of the MySQL container to obtain the recovery verification result.

7. A server, characterized in that, The method includes a processor and a memory, the memory storing computer-executable instructions executable by the processor, the processor executing the computer-executable instructions to implement the method of any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions that, when invoked and executed by a processor, cause the processor to perform the method described in any one of claims 1 to 5.

Images