Data backup method, electronic equipment and storage medium

Abstract

The invention discloses a data backup method, electronic equipment and a storage medium, the method is applied to a target server running a target service, and the method comprises the following steps: receiving an operation request for target data, and executing an operation on the target data according to the operation request; main data is generated for the target data and stored in a main data disk, and the main data comprises at least one of a main data file representing the current state of the target data and a main operation record about the current operation of the target data; backup data corresponding to the main data is generated and stored in a first backup data disk, the backup data comprises at least one of a first backup file corresponding to the main data file and a backup operation record corresponding to the main operation record, and the main data disk and the first backup data disk are both connected to the target server. According to the scheme, data backup in a stand-alone scene can be realized.

Description

Technical Field

[0001] This application relates to the field of data processing, and in particular to a data backup method, electronic device, and storage medium. Background Technology

[0002] Data backup refers to the process of copying the original data one or more times and storing them on a secure medium in a different location than the original data, which can prevent data loss. When performing a backup, the original data stored on one device is typically backed up to another device.

[0003] In some business scenarios, to save costs, a single device is used to run business services, also known as a standalone scenario. In a standalone scenario, only one device is available, and there is no other device available for data backup. Therefore, how to achieve data backup in a standalone scenario becomes an urgent problem to be solved. Summary of the Invention

[0004] This application provides at least one data backup method, electronic device, and storage medium.

[0005] This application provides a data backup method applied to a target server running a target service. The method includes: receiving an operation request for target data and performing an operation on the target data according to the operation request; generating master data for the target data and storing it on a master data disk, wherein the master data includes at least one of a master data file representing the current state of the target data and a master operation record regarding the current operation on the target data; generating backup data corresponding to the master data and storing it on a first backup data disk, wherein the backup data includes at least one of a first backup file corresponding to the master data file and a backup operation record corresponding to the master operation record, and both the master data disk and the first backup data disk are connected to the target server.

[0006] The process of generating master data for the target data includes at least one of the following steps: generating a master operation record corresponding to the operation request; and generating a master data file in response to the fact that the number of times the operation request is counted meets a preset condition.

[0007] The process of generating master data for the target data and storing it on the master data disk, and generating backup data corresponding to the master data and storing it on the first backup data disk, includes: using a dual-write mechanism to synchronously generate master data and corresponding backup data for the target data; and storing the synchronously generated master data and backup data on the master data disk and the first backup data disk, respectively.

[0008] The method further includes: receiving a backup request sent by the target program; generating a second backup file of the target data in response to the backup request; sending the second backup file to the target program so that the target program stores the second backup file on a second backup data disk, and the second backup data disk is connected to the target server.

[0009] The first backup data disk and the second backup data disk are the same data disk. The backup data is stored in the first directory of the first backup data disk, and the second backup file is stored in the second directory of the second backup data disk.

[0010] The preset condition indicates that the number of operation requests for the target data has reached a preset number.

[0011] The backup request is sent by the target program at preset intervals.

[0012] The backup data includes backup operation records and a first backup file; the second backup file for generating the target data includes: integrating the backup operation records and the first backup file to obtain a snapshot of the current target data, which serves as the second backup file.

[0013] The method further includes: in response to master data corruption, determining the current startup data of the target service using at least backup data; and starting the target service using the current startup data.

[0014] Among them, determining the current startup data of the target service using backup data includes: using the backup data as the current startup data in response to the backup data not being corrupted; using the second backup file as the current startup data in response to the backup data being corrupted and the second backup file not being corrupted; and determining that the current startup data is empty in response to the backup data and the second backup file both being corrupted.

[0015] Before starting the target service using the current startup data, the method further includes: clearing all data other than the current startup data; and storing the current startup data to the main data disk in response to using backup data or a second backup file as the current startup data.

[0016] The target service is a single-replica Zookeeper, the target data is a Znode tree, and the main operation record and backup operation record are transaction logs.

[0017] The first backup data disk is a removable data disk.

[0018] This application provides an electronic device, including a memory and a processor, wherein the processor is configured to execute program instructions stored in the memory to implement any of the methods described above.

[0019] This application provides a computer-readable storage medium having program instructions stored thereon, which, when executed by a processor, implement any of the methods described above.

[0020] In the above solution, when only the target server is used to run the target service, the master data in the master data disk is backed up as the first backup data disk connected to the target server, thereby realizing data backup in a single-machine scenario and reducing the risk of complete data loss.

[0021] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this application. Attached Figure Description

[0022] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with this application and, together with the specification, serve to explain the technical solutions of this application.

[0023] Figure 1 This is a flowchart illustrating an embodiment of the data backup method of this application; Figure 2 This is a flowchart illustrating another embodiment of the data backup method of this application; Figure 3 This is a flowchart illustrating another embodiment of the data backup method of this application; Figure 4 This is a schematic diagram of the framework of an embodiment of the electronic device of this application; Figure 5 This is a schematic diagram of a framework of an embodiment of the computer-readable storage medium of this application. Detailed Implementation

[0024] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0025] In the following description, specific details such as particular subsystem structures, interfaces, and technologies are presented for illustrative purposes rather than for limiting purposes, in order to provide a thorough understanding of this application.

[0026] In this document, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " generally indicates that the preceding and following related objects have an "or" relationship. Furthermore, "many" in this document means two or more. Moreover, the term "at least one" in this document means any combination of at least two of any one or more of a plurality of objects. For example, including at least one of A, B, and C can mean including any one or more elements selected from the set consisting of A, B, and C.

[0027] In some scenarios, business traffic is low and cost considerations are paramount. To allocate more resources to business computation, a single device is used to run the service. In one specific application scenario, a single server can run a single replica of ZooKeeper. However, power outages or other unforeseen events may render the service unavailable, leading to data retrieval failures after restarting and ultimately, business recovery being impossible. Since this is a low-cost product, rapid business recovery is not a primary concern; the only requirement is that the service can be restarted on its original state.

[0028] See Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the data backup method of this application. This method can be applied to a target server running a target service. The target server can run the target service and implement the following steps: Step S110: Receive an operation request for the target data and perform the operation on the target data according to the operation request.

[0029] The target server can run the target service. The target service can maintain target data and receive operation requests for that data. These operation requests can be used to request specific operations on the target data. The target service can then execute the operations on the target data according to the operation requests. For example, the operation request could be at least one of the following: CRUD operations on the target data; the service will execute the corresponding data operation accordingly.

[0030] In some implementation scenarios, the target server can receive one or more operation requests and perform corresponding operations on the target data after receiving the operation request.

[0031] Step S120: Generate master data for the target data and store it on the master data disk.

[0032] Master data is generated during the execution of the target service. It records relevant information about the target data at the time of its generation.

[0033] In some implementation scenarios, when the target service is restarted after being shut down, the target data can be restored to its state before shutdown based on the master data.

[0034] In some embodiments, the master data includes at least one of a master data file representing the current state of the target data and a master operation record regarding the current operation on the target data.

[0035] In some implementation scenarios, master data files can be generated at one or more time points to serve as master data. Each newly generated master data file can be stored on the master data disk as master data. One or more master data files from different time points can be stored.

[0036] In some implementation scenarios, for each received operation request, a corresponding master operation record is generated and stored in the master data disk as master data. At least one master operation record corresponding to at least one historical operation can be stored.

[0037] It's important to note that a data file itself can represent the state of the target data at a specific moment, containing the data content at that moment. The data file can then be directly used to determine the content of the target data at a particular moment. Data files can be generated and stored separately at one or more moments, recording the content of the target data at the next or subsequent moments, which can be used for data backtracking.

[0038] It should be noted that an operation request can record what kind of operation was performed on the target data. The target service can receive one or more operation requests and generate a corresponding operation record for each request. Based on historical operation records, the data content of the target data at any given time can be determined, which can be used for data backtracking.

[0039] Step S130: Generate backup data corresponding to the master data and store it on the first backup data disk.

[0040] The backup data is a backup generated from the primary data and is identical in content to the primary data. Both the primary data disk and the first backup data disk are connected to the target server. The backup data includes at least one of the following: the first backup file corresponding to the primary data file, or the backup operation record corresponding to the primary operation record.

[0041] It should be noted that the steps in this application are executed in a logical order. For example, steps S120 and S130 can be executed simultaneously or sequentially.

[0042] In some implementation scenarios, the data disk connected to the target server includes a primary data disk and a first backup data disk. Primary data is stored on the primary data disk, and backup data is stored on the first backup data disk. In the above solution, when using a single device, such as the aforementioned target server, to run the target service, the first backup data disk connected to the target server is used to back up the primary data on the primary data disk. This achieves data backup in a single-machine scenario without the need for other devices, reducing the risk of complete data loss. Even if the primary data on the primary data disk is damaged or lost, the backup data on the first backup data disk can be used to replace the primary data.

[0043] In some embodiments, steps S120 and S130 may be executed simultaneously.

[0044] In some embodiments, the backup data is a backup of the master data. The master data and backup data can be generated synchronously, or the master data can be generated first, and then a copy of the master data can be made to obtain the backup data.

[0045] In some embodiments, the master data may include at least one of a master data file and a master operation record. Accordingly, the content of the backup data is consistent with the content of the master data.

[0046] In some implementation scenarios, master data includes master data files.

[0047] In some implementation scenarios, master data includes master operation records.

[0048] In some implementation scenarios, master data includes master data files and master operation records.

[0049] In some embodiments, generating master data for target data includes at least one of the following steps: generating a master operation record corresponding to the operation request; and generating a master data file in response to the statistical count of the operation request meeting a preset condition. The master operation record is generated for the operation request, while the master data file requires the preset condition to be met to trigger its generation. The steps for generating backup data are similar.

[0050] In some embodiments, the steps of generating master data for the target data and generating backup data corresponding to the master data can be performed simultaneously.

[0051] In some embodiments, generating master data for target data and storing it on the master data disk, and generating backup data corresponding to the master data and storing it on the first backup data disk may include: using a dual-write mechanism to synchronously generate master data and corresponding backup data for target data; and storing the synchronously generated master data and backup data on the master data disk and the first backup data disk, respectively.

[0052] In the above scheme, the dual-write mechanism can be used to conveniently achieve the synchronous generation of master data and backup data and their separate storage.

[0053] In some implementation scenarios, when an operation request is received, two operation records with identical content are generated for the same operation request and stored in the main data disk and the first backup data disk, respectively, as the main operation record and the backup operation record.

[0054] It should be noted that the target service can receive one or more operation requests for the target data. Each operation request can be processed separately, and a master operation record and a backup operation record can be generated for each operation request.

[0055] In some implementation scenarios, in response to the statistical results of the operation request meeting preset conditions, two identical data files are generated to represent the current state of the target data. These two data files are then stored on the primary data disk and the first backup data disk, respectively, serving as the primary data file and the first backup file. These two data files represent the target data at the same moment.

[0056] In some implementation scenarios, the number of operation requests or corresponding processing operations can be counted. When the number meets a preset condition, the generation of a data file is triggered. Furthermore, the preset condition can indicate that the number of operation requests or processing operations has reached a threshold; when the number of operation requests reaches the threshold, the generation of a data file is triggered.

[0057] In a specific application scenario, the number of operation requests can be counted starting from the last time a data file was generated. When the number exceeds a threshold, the generation of a new data file is triggered. After the data file is generated, the previous count is reset to zero, and the count of operation requests is restarted to periodically trigger the generation of the data file.

[0058] In some embodiments, the data file that records the target data can be a snapshot. Taking a snapshot of the target data records the state of the target data at this time, which makes it easier to trace back the state of the target data at this time later.

[0059] In a specific application scenario, generating a master data file may include: generating a first snapshot of the current target data as the master data file.

[0060] In a specific application scenario, generating the first backup file may include: generating a second snapshot of the current target data as the first backup file.

[0061] The first and second snapshots are generated synchronously, and their contents are identical.

[0062] In a specific application scenario, a first snapshot and a second snapshot of the current target data are generated synchronously and stored on the main data disk and the first backup data disk, respectively.

[0063] In a specific application scenario, the primary data disk can be a solid-state drive (SSD) of the target server. The first backup data disk can be a mechanical hard drive (HDD) connected to the target server, and the first backup data disk is removable.

[0064] See Figure 2 , Figure 2 This is a flowchart illustrating another embodiment of the data backup method of this application. The method can be applied to a target server running a target service, and the method may include: Step S210: Receive a backup request sent by the target program.

[0065] The target program can be another program running on the target server. The target program sends a backup request to the target service to trigger the target service to perform data backup.

[0066] In some implementation scenarios, the target program may periodically trigger backup requests. Specifically, backup requests may be triggered at preset time intervals.

[0067] Step S220: In response to the backup request, generate a second backup file of the target data.

[0068] The second backup file is a data file that represents the current state of the target data and can represent the current data content of the target data.

[0069] In some embodiments, the second backup file may be a snapshot.

[0070] In some implementation scenarios, backup data includes backup operation records and a first backup file. Generating a second backup file may involve integrating the backup operation records and the first backup file to obtain a third snapshot of the current target data, which serves as the second backup file. It should be noted that combining the backup data records and the first backup file reflects the state of the target data at the time of the last snapshot, as well as the operations performed after the last snapshot, accurately representing the current state. Integrating the two yields the second backup file for that current state. Alternatively, in some implementation scenarios, the master operation record and the master data file can also be integrated into a second backup file.

[0071] In some implementation scenarios, a snapshot of the current target data can be taken directly to obtain a second backup file.

[0072] Step S230: Send the second backup file to the target program.

[0073] The target service sends the second backup file to the target program, enabling the target program to store the second backup file on a second backup data disk. This second backup data disk can be a data disk connected to the target server.

[0074] In some embodiments, the second backup data disk may be a separate data disk that is distinct from both the primary data disk and the first backup data disk.

[0075] In the above scheme, the target program can trigger a second backup, further reducing the risk of data loss. Periodically performing the second backup allows the backup file to continuously track user operations on the target data.

[0076] In some implementation scenarios, the second backup data disk can be a removable data disk, which can be connected to the target server and also unmounted from the target server. Therefore, data stored on the removable data disk by the target server can be migrated to another device by unmounting and remounting the data disk.

[0077] In some implementation scenarios, the second backup data disk can be the same as the first backup data disk. Backup data records and the first backup file can be stored in the first directory of the first backup data disk, while the second backup file can be stored in a second directory on the second backup data disk, distinct from the first directory. Two backups can be performed using the same data disk, with the two backup data stored in different directories. This also allows for the use of a second backup stored in a different directory if the primary data and one backup are unavailable, preventing data loss.

[0078] It should be noted that steps S110 to S130 and steps S210 to S230 can be steps executed by the target server when running the target service.

[0079] In some embodiments, the target service can be a single-replica Zookeeper, the target data can be a Znode tree, and the operation records can be transaction logs.

[0080] In one implementation scenario, a containerized single-replica ZooKeeper starts, and the number of replicas is checked during mirroring. If the number of replicas is 1, a single-replica dual-write mode is initiated, creating snapshots and transaction log directories on both the primary data disk and the first backup data disk. ZooKeeper receives external Znode requests, which request operations on the Znode tree. Modifications to the in-memory Znode tree are written to the transaction logs on both the primary and first backup data disks simultaneously. When the number of operations reaches a specified threshold, snapshot logic is triggered on both disks, generating snapshots.

[0081] A scheduled script is enabled in the image and triggered periodically. The period is configurable, with a default value of 6 hours. The scheduled script sends a custom four-word command to ZooKeeper. ZooKeeper then combines the snapshot and transaction log stored in the first directory of the first backup data disk into a single snapshot file and sends it to the scheduled script. The scheduled script then moves this file to the second directory of the first backup data disk.

[0082] See Figure 3 , Figure 3 This is a flowchart illustrating another embodiment of the data backup method of this application. This method can be applied to a target server running a target service. If the target service needs to be restarted after being shut down, the current startup data to be used for startup needs to be determined before starting the target service. If the master data is not corrupted, the master data is used as the current startup data, and the target service starts normally. In some cases, the master data stored on the master data disk is corrupted and cannot be used; in such cases, it is necessary to use the backed-up data to determine the current startup data.

[0083] The method may also include: Step S310: In response to primary data corruption, at least use backup data to determine the current startup data of the target service.

[0084] The master data includes at least one of the master data file and the master operation record. If only the master data file is included, then a corrupted master data file indicates corrupted master data. If only the master operation record is included, then a corrupted master operation record indicates corrupted master data. If both the master data file and the master operation record are included, then a corrupted master data is considered corrupted if either one is corrupted.

[0085] In some embodiments, only one backup is performed, so the master data only contains the corresponding backup data, which can then be used to determine the current startup data of the target service.

[0086] In some embodiments, multiple backups are performed, and the master data corresponds to backup data and a second backup file. The available data includes the backup data and the second backup file, from which the current startup data can be selected.

[0087] Step S320: Start the target service using the current startup data.

[0088] The current startup data can be used to determine the current state of the target data. Based on this, the target service can be started to continue maintaining the current target data. If the current startup data is empty, a completely new Zookeeper can be started.

[0089] If the primary data of the target service is corrupted and there is no backup, the target service cannot be restored to its previous state upon restart. By backing up the data on disks other than the primary data disk on the target server, even if the primary data is corrupted, the backup data can be used when the target service is restarted, allowing the target service to be restored to its previous state, user data to be preserved, and service stability to be improved. Data disaster recovery can also be achieved in a single-machine scenario, with low cost and convenient implementation.

[0090] Understandably, the backup data is more comprehensive than the second backup file, so it is prioritized as the initial startup data. If the backup data is unavailable, the second backup file is used. This dual backup approach reduces the risk of data loss, and prioritizing the more complete backup data ensures that more target data can be recovered after the target service starts.

[0091] Specifically, if the backup data is not corrupted, the backup data is used as the current startup data; if the backup data is corrupted but the second backup file is not corrupted, the second backup file is used as the current startup data; if both the backup data and the second backup file are corrupted, the current startup data is determined to be empty.

[0092] In some embodiments, before starting the target service using the current startup data, all other data besides the current startup data can be cleared; in response to using backup data or a second backup file as the current startup data, the current startup data is stored on the main data disk. Since the current startup data has been determined, other data can be cleared to prevent interference. Because the main data disk is used to store master data, the current startup data is stored on the main data disk to serve as master data. If the current startup data is empty, all data can be cleared, and a completely new Zookeeper can be started.

[0093] In a specific application scenario, after restarting the Zookeeper container, the startup script checks and finds that files on the main data disk are corrupted. It then checks the backup data. If the backup data is intact, its directory is marked as the data startup directory. If the backup data is also corrupted, the second backup file is checked. If the second backup file is valid, its directory is marked as the data startup directory; otherwise, the data startup directory is empty. All data directories except the data startup directory are cleared, and the data in the data startup directory is copied to the main data disk. Zookeeper is then started. If the data startup directory is empty, all three directories are cleared, and a completely new Zookeeper instance is started.

[0094] After the target server is backed up, it can be used in conjunction with the backup server to switch the device running the target service, ensuring that the data of the target service remains unchanged after the device switch. The backup server is a separate device from the target server.

[0095] In some cases, the target server connects to both the primary data disk and the first backup data disk. The primary data disk stores the primary data. The first backup data disk stores backup data and the second backup file.

[0096] In some cases, the target server is connected to a primary data disk, a first backup data disk, and a second backup data disk. The primary data disk stores the primary data, the first backup data disk stores the backup data, and the second backup data disk stores the second backup files.

[0097] The first backup data disk and the second backup data disk are removable data disks.

[0098] When the target server fails to start, its backup data disk stores backup data for the target service. This backup data disk can be removed from the target server and reinstalled on the backup server to allow the target service to be started using the backup data. The backup data disk of the target server may include at least one of the aforementioned first and second backup data disks.

[0099] The primary data disk of the target server can be the primary data disk in the aforementioned embodiments, and the backup data disk can be the first backup data disk in the aforementioned embodiments, or the first backup data disk and the second backup data disk. The steps for writing data to the primary data disk and the backup data disk can refer to the relevant content in the aforementioned embodiments, and will not be repeated here.

[0100] Taking the example of a target server connected to a primary data disk and a first backup data disk, where the primary data disk stores the primary data and the first backup data disk stores backup data and a second backup file, the following explanation is provided. Specifically, the backup server can mount the target data disk, using another data disk connected to it (excluding the target data disk) as its primary data disk for running the target service, and using the target data disk as the backup data disk for the backup server to run the target service. Then, the target service can be run using both the primary and backup data disks. The steps for the backup server to run the target service can be found in the same steps for the target server to run the target service, and will not be repeated here.

[0101] The backup server has its own connected data disk that can serve as the primary data disk for running the target service, while the target data disk, once connected, can serve as its backup data disk. The backup server then possesses the primary data disk and at least one backup data disk required by the target service, enabling it to run the target service with both a primary data disk and at least one backup data disk.

[0102] When the target data disk is connected to the backup server as its backup data disk, the primary data disk of the backup server does not store data for the target service. Following the process for primary data corruption, the current startup data can be determined based on the backup data stored on the backup data disk. Specific steps can be found in the steps for determining the current startup data in the aforementioned embodiments, and will not be repeated here.

[0103] When the backup server is running the target service normally, its status is equivalent to that of the target server in the aforementioned embodiments. It can execute the steps performed by the target server in the aforementioned embodiments to achieve the data backup function.

[0104] In the above solution, even if the target server is unusable, the target service can be restored to standalone operation on another device through the removable hard drive, and user data can also be used on the new device, thus improving service stability.

[0105] In some embodiments, the target server can access a first backup data disk and a second backup data disk, both of which are removable disks, and at least one of them can be mounted on the backup server as the target data disk.

[0106] It's important to note that ZooKeeper, as a foundational service for big data products, provides distributed locking capabilities to numerous upper-layer services. Therefore, the primary requirement for ZooKeeper is high data reliability, enabling recovery from various anomalies. Meanwhile, many current cloud computing products are based on cloud-native principles, utilizing container technology to deploy each service independently and dynamically allocate hardware resources to improve resource utilization. With the deepening of cloud-native concepts and industry segmentation, small-scale private cloud scenarios have emerged. These scenarios typically involve low business traffic, prioritize cost considerations, and require disaster recovery capabilities. To ensure resources are primarily used for business computation, ZooKeeper is generally deployed as a single replica on single-machine private cloud servers. In such cases, power outages or other unforeseen events can corrupt ZooKeeper's data disk files, preventing ZooKeeper from reading data upon restart and causing business unavailability. Because these are low-cost products, rapid business recovery is not a primary concern; the only requirement is that the business can resume operation on its original state.

[0107] Based on the above scenario, this application proposes a high-reliability single-machine ZooKeeper (ZK) method based on hard disks. In a single-machine scenario, CPU and memory are scarce resources, but hard disks are inexpensive and have a large amount of idle space. This idle space can be utilized by allocating a dedicated backup disk for Znode backups. The ZooKeeper code is modified to implement dual-write logic during data writing. When external applications perform Znode operations on ZooKeeper, the single-machine ZooKeeper records the operation in the Znode tree. The disk writing process writes the Znode to the transaction log, which is a dual-write process, written to two data disks: the primary data disk and the first backup directory of the first backup data disk. When the transaction log reaches an internal threshold, the log files are merged into a snapshot file, also performed simultaneously in both directories. Simultaneously, a four-word command is added to ZooKeeper to trigger snapshots. An external timed script periodically uses this four-word command to dump backup data to the second backup directory of the first backup data disk. This action further protects against backup file corruption caused by power outages.

[0108] In a specific application scenario, under cloud-native mode, disaster recovery features of a single-machine ZooKeeper are implemented with limited resources. A compromise is made between cost and disaster recovery. In the event of a single-machine power outage or damage to the native disk, the server can be restarted to replace the backup disk and restore the task, or the backup disk can be inserted into another cloud resource pool to temporarily restore the task on other nodes. Once the original machine is restored, it can be switched back, using only one additional disk for business disaster recovery.

[0109] See Figure 4 , Figure 4 This is a schematic diagram of the framework of an embodiment of the electronic device of this application.

[0110] The electronic device 40 includes a memory 41 and a processor 42. The processor 42 is used to execute program instructions stored in the memory 41 to implement the steps in any of the above data backup method embodiments. In a specific implementation scenario, the electronic device 40 may include, but is not limited to, computer equipment, electrical equipment, microcomputers, desktop computers, and servers. In addition, the electronic device 40 may also include mobile devices such as laptops and tablets, which are not limited here.

[0111] Specifically, processor 42 controls itself and memory 41 to implement the steps in any of the above data backup method embodiments. Processor 42 can also be referred to as a CPU (Central Processing Unit). Processor 42 may be an integrated circuit chip with signal processing capabilities. Processor 42 can also be a general-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. A general-purpose processor can be a microprocessor or any conventional processor. Furthermore, processor 42 can be implemented using integrated circuit chips.

[0112] See Figure 5 , Figure 5 This is a schematic diagram of a framework of an embodiment of the computer-readable storage medium of this application.

[0113] The computer-readable storage medium 50 provided in this embodiment stores program instructions 51 that can be executed by a processor. When the program instructions 51 are executed by the processor, they are used to implement the steps in any of the above data backup method embodiments.

[0114] The description of the various embodiments above tends to emphasize the differences between the various embodiments. The similarities or similarities between them can be referred to, and for the sake of brevity, they will not be repeated here.

[0115] In the several embodiments provided in this application, it should be understood that the disclosed methods and apparatus can be implemented in other ways. For example, the apparatus implementations described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, units or components may be combined or integrated into another subsystem, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.

[0116] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part 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 server, network device, etc.) or processor to execute all or part of the steps of the methods in the various embodiments of this application. 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.

Claims

1. A data backup method, characterized in that, The method is applied to a target server running the target service, and the method includes: Receive an operation request for target data, and perform an operation on the target data according to the operation request; Generate master data for the target data and store it on the master data disk, wherein the master data includes at least one of the master data file representing the current state of the target data and the master operation record of the current operation on the target data; Backup data corresponding to the master data is generated and stored on the first backup data disk. The backup data includes at least one of the first backup file corresponding to the master data file and the backup operation record corresponding to the master operation record. Both the master data disk and the first backup data disk are connected to the target server.

2. The method according to claim 1, characterized in that, The process of generating master data for the target data includes at least one of the following steps: Generate the main operation record corresponding to the operation request; In response to the fact that the number of times the operation request is counted meets a preset condition, the master data file is generated.

3. The method according to claim 1, characterized in that, The steps of generating master data for the target data and storing it on the master data disk, and generating backup data corresponding to the master data and storing it on the first backup data disk, include: By using a dual-write mechanism, the master data and the corresponding backup data are generated synchronously for the target data. The synchronously generated master data and backup data are stored in the master data disk and the first backup data disk, respectively.

4. The method according to claim 1, characterized in that, The method further includes: Receive backup requests sent by the target program; In response to the backup request, a second backup file of the target data is generated; The second backup file is sent to the target program so that the target program stores the second backup file to the second backup data disk, which is connected to the target server.

5. The method according to claim 4, characterized in that, The first backup data disk and the second backup data disk are the same data disk. The backup data is stored in the first directory of the first backup data disk, and the second backup file is stored in the second directory of the second backup data disk. And / or, The backup request is sent by the target program at preset intervals; And / or, The backup data includes the backup operation record and the first backup file; The second backup file used to generate the target data includes: By integrating the backup operation record and the first backup file, a snapshot of the current target data is obtained, which serves as the second backup file.

6. The method according to claim 1, characterized in that, The method further includes: In response to the corruption of the master data, at least the backup data is used to determine the current startup data of the target service; Start the target service using the current startup data.

7. The method according to claim 6, characterized in that, Determining the current startup data of the target service using at least the backup data includes: In response to the fact that the backup data is not corrupted, the backup data is used as the current startup data; In response to the corruption of the backup data, and the fact that the second backup file is not corrupted, the second backup file is used as the current startup data; In response to the fact that both the backup data and the second backup file are corrupted, it is determined that the current startup data is empty; and / or, Before starting the target service using the current startup data, the method further includes: Clear all data except the currently started data; In response to using the backup data or the second backup file as the current startup data, the current startup data is stored in the main data disk.

8. The method according to claim 1, characterized in that, The target service is a single-replica Zookeeper, the target data is a Znode tree, and the master operation record and the backup operation record are transaction logs; And / or, the first backup data disk is a removable data disk.

9. An electronic device, characterized in that, The device includes a memory and a processor, wherein the memory stores program instructions that, when executed by the processor, implement the method of any one of claims 1 to 8.

10. A computer-readable storage medium having program instructions stored thereon, characterized in that, When the program instructions are executed by the processor, they implement the method of any one of claims 1 to 8.

Images