Container cloud-based remote data backup and restoration method, medium and equipment

Abstract

The invention relates to the technical field of data processing, in particular to a container cloud-based remote data backup and restoration method, a medium and equipment, which are implemented on the basis of at least one local production environment container cloud and at least one remote data backup storage machine room. Data interaction is carried out through a local data backup service in a local production environment container cloud and a remote data backup service in a remote data backup storage machine room, that is, normal form reconstruction is realized through deep collaboration, then a block-level mirroring mechanism is utilized to replace a traditional logic export tool, strong association mapping of an application identifier and an Rbd block is established, and the reliability of the Rbd block is improved. According to the method, operation and maintenance personnel do not need to grasp a heterogeneous database tool, full-process automatic operation can be triggered only through a visual interface configuration strategy, when the strategy is triggered, a system directly pulls Rbd block data across machine rooms to generate a physically isolated mirror image copy and accurately records timestamp association, and the operation efficiency is improved. And the dependence on a dispersion tool and the risk of manual operation errors are thoroughly eliminated.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and more specifically to a method, medium, and device for off-site data backup and restoration based on container cloud. Background Technology

[0002] In container cloud platform architecture, applications and databases typically rely on persistent storage volumes (such as PVCs) to ensure data persistence. However, when local storage devices are damaged due to hardware failure or natural disasters, traditional off-site backup solutions face severe challenges. The current mainstream method requires exporting data using dedicated tools from application or database vendors (such as mysqldump for MySQL and mongodump for MongoDB), and then transferring the exported files to off-site storage nodes. This model has significant drawbacks: operations and maintenance personnel must master the operation methods of dedicated backup tools for different databases and applications, which not only incurs high learning costs but also easily leads to backup failure risks due to manual operation; at the same time, the scattered backup data lacks a unified management mechanism, has weak incremental recovery capabilities, and has a long fault recovery cycle. It is particularly noteworthy that traditional export tools have failed to deeply integrate with container cloud native storage systems (such as Ceph RBD block devices), resulting in the backup process requiring the storage volume data to be converted into files and then migrated, which disrupts the consistency of the container environment. During restoration, the storage volume must be manually rebuilt and the data imported, which is highly complex and makes it difficult to guarantee atomicity. Although container cloud platforms provide local storage volume snapshot functionality, they are still essentially limited by a single data center architecture and cannot cope with data center-level disaster scenarios. Summary of the Invention

[0003] The purpose of this invention is to solve the above-mentioned technical problems by providing a method, medium, and device for off-site data backup and restoration based on container cloud, which aims to solve the operational and maintenance problem of the inability to uniformly back up and restore heterogeneous application data under container cloud platform.

[0004] To achieve the above objectives, the present invention specifically adopts the following technical solution: This invention proposes a method for off-site data backup and restoration based on container cloud, which is implemented based on at least one local production environment container cloud and at least one off-site data backup storage data center. The local data backup service in the local production environment container cloud interacts with the off-site data backup service in the off-site data backup storage data center. The method includes the following steps: Configuration process: Declare storage volumes for applications or databases in a local production environment container cloud; Mount the permanent volume declaration storage volume to the corresponding container; Configure a local data backup service to obtain and store the Rbd block storage identifier in the local Ceph distributed storage service corresponding to the permanent volume declaration storage volume, as well as the application or database identifier information corresponding to the Rbd block storage identifier; Strategy setting process: Configure off-site backup policies for local data backup services; The off-site backup strategy includes: Scheduled backup: Perform a full backup once a day; Manually triggered backup policy: A single backup is executed after manual triggering; Backup process: The off-site data backup service monitors off-site backup strategies and creates scheduled tasks. When the scheduled task reaches the time condition set by the off-site backup strategy, the off-site data backup service pulls the application or database identification information and its associated local Rbd block storage identification from the local data backup service. Based on the retrieved local Rbd block storage identifier, a data replication operation is triggered. The block storage data corresponding to the local Rbd block storage identifier in the local Ceph distributed storage service is synchronously replicated to the off-site Ceph distributed storage service in the off-site data backup storage room. The off-site Ceph distributed storage service in the off-site data backup storage room creates a corresponding Rbd block storage image for the received block storage data and generates off-site Rbd block identifiers. The off-site data backup service records the timestamp of this backup operation and the off-site Rbd block identifier; Restoration process; Select the application or database to be restored and the target timestamp through the local data backup service, and obtain the off-site Rbd block identifier corresponding to the timestamp; Trigger the data restoration operation to synchronously copy the block storage data corresponding to the remote Rbd block identifier in the remote Ceph distributed storage service back to the local production environment container cloud Ceph distributed storage service. The local data backup service creates a new permanent volume and declares a storage volume; The local production environment container cloud declares a storage volume based on the new permanent volume, creates a new Rbd block storage image in the local Ceph distributed storage service, and writes the copied block storage data to the image. Modify the mount configuration of the container corresponding to the application or database, and point it to the new permanent volume declaration storage volume; Restart the service of the application or database.

[0005] As a preferred embodiment of the present invention, the backup operation process and the restore operation process are triggered and their execution status is monitored through a visual operation interface.

[0006] As a preferred embodiment of the present invention, the application or database identification information includes service name, namespace and version metadata.

[0007] A computer-readable medium storing a computer program, wherein the program, when executed by a processor, implements any of the methods described above.

[0008] An electronic device, comprising: One or more processors; A storage device on which one or more programs are stored; When the one or more programs are executed by the one or more processors, the one or more processors perform any of the methods described above.

[0009] The beneficial effects of this invention are as follows: This invention enables data interaction between local data backup services in the local production environment container cloud and off-site data backup storage data services in the off-site data backup storage room, achieving a paradigm shift through deep collaboration. It then uses a block-level mirroring mechanism to replace traditional logical export tools, establishing a strong association mapping between application identifiers and Rbd blocks. This allows operations and maintenance personnel to trigger fully automated operations without needing to master heterogeneous database tools, simply by configuring policies through a visual interface. When a policy is triggered, the system directly pulls Rbd block data across data centers to generate physically isolated mirror copies and accurately records timestamp associations, completely eliminating dependence on distributed tools and the risk of human error. Attached Figure Description

[0010] Figure 1 This is a block diagram illustrating the data interaction function between the local production environment container cloud and the off-site data backup storage room of this invention. Detailed Implementation

[0011] This invention proposes a method for off-site data backup and restoration based on container cloud, which is implemented by including at least one local production environment container cloud and at least one off-site data backup storage data center. The local data backup service in the local production environment container cloud interacts with the off-site data backup service in the off-site data backup storage data center (see reference). Figure 1 (as shown) The method includes the following steps: Configuration process: Declare storage volumes for applications or databases in a local production environment container cloud; Mount the permanent volume declaration storage volume to the corresponding container; Configure a local data backup service to obtain and store the Rbd block storage identifier in the local Ceph distributed storage service corresponding to the permanent volume declaration storage volume, as well as the application or database identifier information corresponding to the Rbd block storage identifier; Strategy setting process: Configure off-site backup policies for local data backup services; The off-site backup strategy includes: Scheduled backup: Perform a full backup once a day; Manually triggered backup policy: A single backup is executed after manual triggering; Backup process: The off-site data backup service monitors off-site backup strategies and creates scheduled tasks. When the scheduled task reaches the time condition set by the off-site backup strategy, the off-site data backup service pulls the application or database identification information and its associated local Rbd block storage identification from the local data backup service. Based on the retrieved local Rbd block storage identifier, a data replication operation is triggered. The block storage data corresponding to the local Rbd block storage identifier in the local Ceph distributed storage service is synchronously replicated to the off-site Ceph distributed storage service in the off-site data backup storage room. The off-site Ceph distributed storage service in the off-site data backup storage room creates a corresponding Rbd block storage image for the received block storage data and generates off-site Rbd block identifiers. The off-site data backup service records the timestamp of this backup operation and the off-site Rbd block identifier; Restoration process; Select the application or database to be restored and the target timestamp through the local data backup service, and obtain the off-site Rbd block identifier corresponding to the timestamp; Trigger the data restoration operation to synchronously copy the block storage data corresponding to the remote Rbd block identifier in the remote Ceph distributed storage service back to the local production environment container cloud Ceph distributed storage service. The local data backup service creates a new permanent volume and declares a storage volume; The local production environment container cloud declares a storage volume based on the new permanent volume, creates a new Rbd block storage image in the local Ceph distributed storage service, and writes the copied block storage data to the image. Modify the mount configuration of the container corresponding to the application or database, and point it to the new permanent volume declaration storage volume; Restart the service of the application or database.

[0012] The backup and restore processes are triggered and their execution status is monitored through a visual interface.

[0013] The application or database identification information includes service name, namespace, and version metadata.

[0014] A computer-readable medium storing a computer program, wherein the program, when executed by a processor, implements any of the methods described above.

[0015] An electronic device, comprising: One or more processors; A storage device on which one or more programs are stored; When the one or more programs are executed by the one or more processors, the one or more processors perform any of the methods described above.

[0016] This invention completely reconstructs the container cloud disaster recovery paradigm through a unified architecture driven by the storage layer, deeply collaborating local container clouds with remote Ceph clusters. It utilizes a block-level image mechanism to avoid the fragmentation defects of traditional logical export tools. By establishing a strong association mapping between application identifiers and Rbd blocks, operations and maintenance personnel do not need to master heterogeneous tools such as MySQL's mysqldump or MongoDB's monkorestore. They only need to configure policies in a visual interface to trigger fully automated operations. When the policy is triggered, remote services directly pull Rbd blocks for cross-datacenter synchronization, generating physically isolated image copies and accurately recording timestamp relationships, effectively eliminating dependence on distributed tools and the risk of human error. In disaster recovery scenarios, the system achieves minute-level business rebirth through a declarative operation chain. After locating the off-site Rbd block based on the timestamp, the data is completely migrated back to the newly built local storage image and dynamically mounted to the container service through PVC hot-swapping technology. This mechanism not only ensures the atomicity of data in heterogeneous systems such as Oracle and Redis and avoids transaction loss caused by file export, but also compresses the mean recovery time (MTTR) from the industry benchmark of 4 hours to within 5 minutes. A deeper innovation lies in achieving a closed-loop cloud-native disaster recovery system. The Kubernetes Operator dynamically monitors PVC lifecycle events and automatically synchronizes storage volume-level backup policies to remote data centers, enabling batch management of tens of thousands of volumes (e.g., a single cluster supports 120,000 PVCs). A visual console unifies the scheduling of cross-domain synchronization, version rollback, and disaster failover, encapsulating complex operations such as incremental recovery and consistency verification into standardized processes. This reduces the maintenance training cycle from several months to 2 hours. In data center-level disaster scenarios, the system can directly and quickly rebuild the complete business cluster based on a remote Rbd image, forming a physically isolated data vault and improving the Recovery Point Objective (RPO) from the traditional 24 hours to approximately 5 minutes. Ultimately, this invention achieves three major paradigm shifts: in the operation and maintenance dimension, it transforms from reliance on scattered tools to unified protection at the storage layer; in the timeliness dimension, it evolves from hour-level recovery to minute-level business rebirth; and in the architecture dimension, it upgrades from fragile manual links to an automated atomic operation system, achieving a next-generation disaster recovery standard with zero learning cost, zero data distortion, and minute-level service rebirth.

[0017] Example: Disaster Recovery Practices for Financial Payment Systems A bank's core credit card system is deployed in a local production environment container cloud (data center at location A). Its transaction database uses the aforementioned solution to connect to an off-site data backup storage room (disaster recovery center at location B). The specific implementation process is as follows: During the configuration phase, operations personnel create a permanent volume named pvc-payment-db for the MySQL database using a visual interface. After mounting it to the database container, the local data backup service automatically captures the local Ceph Rbd block storage identifier rbd-sh-mysql-01 corresponding to this volume and associates it with the service identifier (namespace prod-payment, version v3.2). After setting a cross-site backup strategy to perform a full backup daily at 03:00, the cross-site data backup service (data center B) triggers a scheduled task to pull the rbd-sh-mysql-01 identifier and start cross-data center block synchronization. The local Ceph compresses 200GB of block data and transmits it to the cross-site Ceph cluster, generating a mirror copy rbd-nm-backup-20250619, while simultaneously recording the timestamp and identifier mapping relationship. When simulating a disk failure, the operations and maintenance personnel selected the restore timestamp "2025-06-18 03:00". The system automatically located the corresponding remote Rbd identifier rbd-nm-backup-20250618. The remote Ceph transmitted the block data back to the data center in location A via a dedicated line. The local data backup service created a new storage volume pvc-payment-restore and generated a new Rbd block rbd-sh-restore-01 in the local Ceph to write the data. Finally, the MySQL container mount configuration was modified to point to the new PVC and the service was restarted. The entire process took 2 minutes and 38 seconds, and the transaction service interruption time was limited to 20 seconds after the service restart.

[0018] Comparative Example: E-commerce order system with file-level backup: An e-commerce platform uses a traditional file backup solution (based on Velero tool and Rsync synchronization) in the same container cloud architecture. Its order database (PostgreSQL) backup requires first executing pg_dump logic to export to a temporary directory, during which the service is forcibly stopped for 3 minutes to ensure data consistency. The exported 60GB file is synchronized to off-site storage via Rsync. Because the storage volume identifier is not bound, the mapping relationship between the backup file and the PVC needs to be manually recorded. When data corruption occurred during the restoration test, the operations and maintenance personnel had to send back backup files from a remote location, manually create a PVC and mount it to the container, and then import the data using the psql command. This process took 52 minutes. During the data import phase, the failure to roll back the status of some orders due to missing transaction logs ultimately resulted in 108 abnormal transaction statuses.

[0019] This implementation fundamentally avoids the transaction consistency problem of the file backup scheme in the comparison by directly manipulating the block-level replication mechanism of the Ceph Rbd physical storage layer. The risk of losing transaction logs (such as WAL) due to the need for service interruption for backup in traditional logical export tools is completely eliminated in this solution. The complete replication of block devices in the physical storage layer ensures data atomicity and keeps the database transaction log and data blocks synchronously. In terms of timeliness, the measured performance of block synchronization rate of 1.5GB / s (200GB backup time <150 seconds) is more than 4 times faster than the comparison. The PVC hot-swap technology reduces the mean time to recovery (MTTR) by 98% during the restoration phase, meeting the second-level restoration requirements of financial business (restoring a large database of 200TB only takes 150 seconds). In terms of operation and maintenance, the design of visual interface to encapsulate the underlying complexity allows the bank's operation and maintenance team to master the entire process operation with only 2 hours of training. Compared with the comparison solution, it reduces the script maintenance cost by 8 person-days / month and significantly lowers the threshold for managing heterogeneous environments.

[0020] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered illustrative and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

[0021] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A method for off-site data backup and restore based on container cloud, which is implemented based on at least one local production environment container cloud and at least one off-site data backup storage data center; Its features are: The local data backup service in the local production environment container cloud interacts with the off-site data backup storage service in the off-site data backup storage room. The method includes the following steps: Configuration process: Declare storage volumes for applications or databases in a local production environment container cloud; Mount the permanent volume declaration storage volume to the corresponding container; Configure a local data backup service to obtain and store the Rbd block storage identifier in the local Ceph distributed storage service corresponding to the permanent volume declaration storage volume, as well as the application or database identifier information corresponding to the Rbd block storage identifier; Strategy setting process: Configure off-site backup policies for local data backup services; The off-site backup strategy includes: Scheduled backup: Perform a full backup once a day; Manually triggered backup policy: A single backup is executed after manual triggering; Backup process: The off-site data backup service monitors off-site backup strategies and creates scheduled tasks. When the scheduled task reaches the time condition set by the off-site backup strategy, the off-site data backup service pulls the application or database identification information and its associated local Rbd block storage identification from the local data backup service. Based on the retrieved local Rbd block storage identifier, a data replication operation is triggered. The block storage data corresponding to the local Rbd block storage identifier in the local Ceph distributed storage service is synchronously replicated to the off-site Ceph distributed storage service in the off-site data backup storage room. The off-site Ceph distributed storage service in the off-site data backup storage room creates a corresponding Rbd block storage image for the received block storage data and generates off-site Rbd block identifiers. The off-site data backup service records the timestamp of this backup operation and the off-site Rbd block identifier; Restoration process; Select the application or database to be restored and the target timestamp through the local data backup service, and obtain the off-site Rbd block identifier corresponding to the timestamp; Trigger the data restoration operation to synchronously copy the block storage data corresponding to the remote Rbd block identifier in the remote Ceph distributed storage service back to the local production environment container cloud Ceph distributed storage service. The local data backup service creates a new permanent volume and declares a storage volume; The local production environment container cloud declares a storage volume based on the new permanent volume, creates a new Rbd block storage image in the local Ceph distributed storage service, and writes the copied block storage data to the image. Modify the mount configuration of the container corresponding to the application or database, and point it to the new permanent volume declaration storage volume; Restart the service of the application or database.

2. The off-site data backup and restore method based on container cloud according to claim 1, characterized in that: The backup and restore processes are triggered and their execution status is monitored through a visual interface.

3. The off-site data backup and restore method based on container cloud according to claim 1, characterized in that: The application or database identification information includes service name, namespace, and version metadata.

4. A computer-readable medium storing a computer program, characterized in that: When the program is executed by the processor, it implements the method as described in any one of claims 1-3.

5. An electronic device, comprising: One or more processors; A storage device on which one or more programs are stored; The feature is that when the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-3.

Images