WO2024078211A1 - 业务集群实例的备份和恢复方法以及相关设备 - Google Patents

业务集群实例的备份和恢复方法以及相关设备 Download PDF

Info

Publication number
WO2024078211A1
WO2024078211A1 PCT/CN2023/117413 CN2023117413W WO2024078211A1 WO 2024078211 A1 WO2024078211 A1 WO 2024078211A1 CN 2023117413 W CN2023117413 W CN 2023117413W WO 2024078211 A1 WO2024078211 A1 WO 2024078211A1
Authority
WO
WIPO (PCT)
Prior art keywords
persistent volume
container group
backup
declaration
target
Prior art date
Application number
PCT/CN2023/117413
Other languages
English (en)
French (fr)
Inventor
王成
彭磊
孙勇福
杜川
王珏
Original Assignee
腾讯科技（深圳）有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 腾讯科技（深圳）有限公司 filed Critical 腾讯科技（深圳）有限公司
Priority to US18/588,833 priority Critical patent/US20240202077A1/en
Publication of WO2024078211A1 publication Critical patent/WO2024078211A1/zh

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1448—Management of the data involved in backup or backup restore
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines

Definitions

  • the present application relates to the field of computer technology, and in particular to backup and recovery technology for business cluster instances.
  • Kubernetes is an open source container orchestration engine that supports automated deployment, large-scale scalability, and containerized application management.
  • a Kubernetes cluster can include at least one container group, in which application instances can run. In order to ensure the continuity, recoverability, and high availability of data storage, the data in the Kubernetes cluster needs to be backed up for disaster recovery to a certain extent.
  • An embodiment of the present application provides a backup and recovery method for a business cluster instance and related equipment.
  • the related equipment may include a backup and recovery device for the business cluster instance, an electronic device, a computer-readable storage medium and a computer program product.
  • the business cluster instance can be backed up as a whole, thereby improving the backup efficiency of the business cluster instance and facilitating the rapid backup of the business cluster instance.
  • the embodiment of the present application provides a method for backing up a service cluster instance, which is executed by an electronic device and includes:
  • the to-be-backed-up data of the container group is backed up to the storage area pointed to by the backup persistent volume object corresponding to the container group.
  • the embodiment of the present application provides a method for recovering a service cluster instance, which is executed by an electronic device and includes:
  • For each container group create a target backup corresponding to the container group based on the backup data of the container group A persistent volume declaration and a target backup persistent volume object, wherein the target backup persistent volume declaration is used to declare storage attribute information required by the container group, and the target backup persistent volume object points to a storage area for backup data of the container group;
  • an embodiment of the present application provides a backup device for a service cluster instance, including:
  • a determination unit configured to determine a service cluster instance to be backed up, wherein the service cluster instance includes at least one container group;
  • a storage unit configured to set, for each container group, a source persistent volume declaration and a source persistent volume object corresponding to the container group, and store the container group based on the source persistent volume object, wherein the source persistent volume declaration is used to declare storage attribute information required by the container group, and the source persistent volume object points to a data storage area of the container group;
  • a first creation unit is used to create, for each container group, a backup persistent volume declaration and a backup persistent volume object corresponding to the container group according to the source persistent volume declaration and the source persistent volume object corresponding to the container group when the business cluster instance meets the backup trigger condition;
  • a first acquisition unit configured to acquire, for each container group, the data to be backed up of the container group based on a source persistent volume object corresponding to the container group;
  • the backup unit is used to back up the to-be-backed-up data of the container group to the storage area pointed to by the backup persistent volume object corresponding to the container group for each of the container groups according to the backup persistent volume declaration corresponding to the container group.
  • an embodiment of the present application provides a device for recovering a service cluster instance, including:
  • a second acquisition unit configured to acquire backup data of each container group in the business cluster instance when receiving an instance recovery request for the business cluster instance
  • a second creation unit is used to create, for each of the container groups, a target backup persistent volume declaration and a target backup persistent volume object corresponding to the container group according to the backup data of the container group, wherein the target backup persistent volume declaration is used to declare the storage attribute information required by the container group, and the target backup persistent volume object points to the storage area of the backup data of the container group;
  • a third creation unit is used to create, for each container group, a target persistent volume declaration and a target persistent volume object corresponding to the container group according to the target backup persistent volume declaration and the target backup persistent volume object corresponding to the container group;
  • the running unit is used to run the container group according to the target persistent volume declaration and the target persistent volume object corresponding to the container group.
  • An embodiment of the present application provides an electronic device, including a processor and a memory, wherein the memory stores a plurality of instructions, and the processor loads the instructions to execute the steps in the method for backing up and restoring a service cluster instance provided in the embodiment of the present application.
  • the embodiment of the present application further provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the steps in the method for backing up and restoring a service cluster instance provided in the embodiment of the present application are implemented.
  • the embodiment of the present application also provides a computer program product, including a computer program or instructions, which, when executed by a processor, implements the steps in the method for backing up and restoring a service cluster instance provided in the embodiment of the present application.
  • the embodiment of the present application provides a method for backing up and restoring a service cluster instance and related equipment, which can determine the A backed-up business cluster instance
  • the business cluster instance includes at least one container group; for each container group, a source persistent volume declaration and a source persistent volume object corresponding to the container group are set, and the container group is stored based on the source persistent volume object, the source persistent volume declaration is used to declare the storage attribute information required by the container group, and the source persistent volume object points to the data storage area of the container group; when the business cluster instance meets the backup trigger condition, for each container group, according to the source persistent volume declaration and the source persistent volume object corresponding to the container group, a backup persistent volume declaration and a backup persistent volume object corresponding to the container group are created; for each container group, based on the source persistent volume object corresponding to the container group, the data to be backed up of the container group is obtained; for each container group, according to the backup persistent volume declaration corresponding to the container group, the data to be backed up of the container group is backed up
  • the present application when backing up a business cluster instance, creates a corresponding backup persistent volume declaration and a backup persistent volume object for each container group therein, obtains the data to be backed up of the container group from the source persistent volume object corresponding to the container group, and then backs up the data to be backed up of the container group to the storage area pointed to by the backup persistent volume object according to the backup persistent volume declaration; in this way, the data backup of each container group in the business cluster instance is realized, thereby realizing the backup processing of the business cluster instance as a whole, improving the backup efficiency of the business cluster instance, and facilitating the rapid backup of the business cluster instance.
  • FIG. 1a is a schematic diagram of a scenario of a method for backing up and restoring a service cluster instance provided in an embodiment of the present application;
  • FIG1b is a flowchart of a method for backing up and restoring a service cluster instance provided in an embodiment of the present application
  • FIG. 1c is an illustration of a method for backing up and restoring a service cluster instance provided in an embodiment of the present application
  • FIG. 1d is another illustration of the backup and recovery method of the service cluster instance provided in an embodiment of the present application.
  • FIG. 1e is another illustration of the backup and recovery method of the service cluster instance provided in an embodiment of the present application.
  • FIG. 1f is another illustration of the backup and recovery method of the service cluster instance provided in an embodiment of the present application.
  • FIG2a is another flow chart of a method for backing up and restoring a service cluster instance provided in an embodiment of the present application
  • FIG2b is another illustration of the backup and recovery method of the service cluster instance provided in an embodiment of the present application.
  • FIG2c is another illustration of the backup and recovery method of the service cluster instance provided in an embodiment of the present application.
  • FIG2d is another illustration of the backup and recovery method of the service cluster instance provided in an embodiment of the present application.
  • FIG3a is a schematic diagram of the structure of a backup device of a service cluster instance provided in an embodiment of the present application
  • FIG3b is a schematic diagram of the structure of a recovery device for a service cluster instance provided in an embodiment of the present application.
  • FIG. 4 is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application.
  • An embodiment of the present application provides a method for backing up and restoring a service cluster instance and related equipment.
  • the related equipment may include a device for backing up and restoring a service cluster instance, an electronic device, a computer-readable storage medium, and a computer program product.
  • the embodiment of the present application provides a backup device for a service cluster instance of a first electronic device, the first The electronic device may be a server or other device; the embodiment of the present application also provides a recovery device for a service cluster instance applicable to a second electronic device, and the second electronic device may be a server or other device.
  • the backup and recovery system for a service cluster instance provided in an embodiment of the present application includes a terminal 10 and a server 11, etc.
  • the terminal 10 and the server 11 are connected via a network, such as a wired or wireless network connection, etc., wherein the backup and recovery device for the service cluster instance can be integrated in the server.
  • the server 11 can be used to: determine a business cluster instance to be backed up, the business cluster instance includes at least one container group; for each container group, set a source persistent volume declaration and a source persistent volume object corresponding to the container group, and store the container group based on the source persistent volume object, where the source persistent volume declaration is used to declare the storage attribute information required by the container group, and the source persistent volume object here points to the data storage area of the container group; when the business cluster instance meets the backup trigger condition, for each container group, according to the source persistent volume declaration and the source persistent volume object corresponding to the container group, create a backup persistent volume declaration and a backup persistent volume object corresponding to the container group; for each container group, based on the source persistent volume object corresponding to the container group, obtain the data to be backed up of the container group; for each container group, according to the backup persistent volume declaration corresponding to the container group, back up the data to be backed up of the container group to the storage area pointed to by the backup persistent volume object corresponding to the container group,
  • the server 11 may be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content distribution networks (CDN, Content Delivery Network), and big data and artificial intelligence platforms.
  • the backup and recovery method or device of the business cluster instance disclosed in this application can be applied to multiple servers, and multiple servers can form a blockchain, and the server is a node on the blockchain.
  • the terminal 10 can be used to send a data backup instruction for a business cluster instance to the server 11, so that the server 11 can implement data backup for each container group in the business cluster instance based on the data backup instruction.
  • the terminal 10 can include a mobile phone, an intelligent voice interaction device, a smart home appliance, a vehicle terminal, an aircraft, a tablet computer, a laptop computer, or a personal computer (PC).
  • a client can also be set on the terminal 10, and the client can be an application client or a browser client, etc.
  • the server 11 can be used to: when receiving an instance recovery request for a business cluster instance, obtain the backup data of each container group in the business cluster instance; for each container group, create a target backup persistent volume declaration and a target backup persistent volume object corresponding to the container group based on the backup data of the container group, the target backup persistent volume declaration is used to declare the storage attribute information required by the container group, and the target backup persistent volume object points to the storage area of the backup data of the container group; for each container group, create a target persistent volume declaration and a target persistent volume object corresponding to the container group based on the target backup persistent volume declaration and the target backup persistent volume object corresponding to the container group; run the container group based on the target persistent volume declaration and the target persistent volume object corresponding to the container group to restore the operation of each container group in the business cluster instance.
  • the terminal 10 can be used to send an instance recovery request for a business cluster instance to the server 11 according to business requirements, so that the server 11 can recover the operation of each container group in the business cluster instance based on the instance recovery request.
  • the backup and recovery method of the service cluster instance provided in the embodiment of the present application relates to cloud storage and database in the field of cloud technology. This embodiment can be applied to various scenarios such as cloud technology, artificial intelligence, smart transportation, and assisted driving.
  • the specific process of the backup method of the service cluster instance may be as follows:
  • the business cluster instance can be a cluster instance delivered from a stateful service (database), which can be recorded as Cluster. It can be a cluster composed of multiple containers, which can be a cluster managed by containers based on a container orchestration engine (Kubernetes, K8s for short), which can be used to manage containerized applications on multiple hosts in a cloud platform.
  • database stateful service
  • K8s container orchestration engine
  • Kubernetes is an open source system for automatically deploying, scaling and managing containerized applications. It can combine several containers into a service and dynamically allocate hosts that support container operation.
  • a business cluster instance may include at least one business component, and each business component may include at least one container group.
  • a business cluster instance can be abstracted into a three-layer resource management model, which is cluster, set, and pod from top to bottom.
  • Cluster corresponds to business instances, set corresponds to business components, and pod corresponds to container groups.
  • the cluster instance is tdach-xxx, set includes zookeeper and clickhouse, and pod includes zookeeper pods and clickhouse-pods, respectively, which meets the resource management requirements of database products.
  • this resource management model it can also support the access of various business products, and support the startup order of business components, custom configuration of parameters of each business component, multi-shards of business pods, and multiple copies (replicas).
  • LibraDB is a distributed HTAP (Hybrid Transaction and Analytical Process) database that provides users with an integrated product experience based on pluggable engine design, powerful data fusion capabilities, and cloud-native system architecture.
  • ZooKeeper is a distributed, open source distributed application coordination service, and clickhouse is a columnar database management system for online analysis.
  • the container group can be a container group responsible for the deployment of a certain business component in the business cluster instance.
  • Each container group can include at least one container.
  • the container group (pod) can be the basic scheduling unit of Kubernetes, and a container group pod can have multiple business processes.
  • a container is an executable unit of software in which application code is packaged together with libraries and dependencies in a common way.
  • Containers use a form of operating system virtualization to allow multiple applications to share an operating system by isolating processes and controlling the amount of CPU (central processing unit), memory, and disk those processes can access.
  • CPU central processing unit
  • the source persistent volume claim can be a specific application for storage resources, which represents the underlying storage object abstracted for Pod use, and declares the required storage capacity (such as 100G), Node exclusive or shared, file system or block device, etc., which can be recorded as PVC (PersistentVolume Claim).
  • PVC PersistentVolume Claim
  • PVC is a resource demand application issued by the user to the kubernetes system.
  • the storage attribute information required by the container group declared by the source persistent volume declaration may include storage capacity, file system type, etc., which is not limited in this embodiment.
  • the source persistent volume object is an abstraction of storage resources. It represents the storage abstraction of the underlying hard disk and is associated with the real hard disk.
  • the source persistent volume object can be recorded as PV (Persistent Volume), which is the persistent volume content.
  • the persistent volume here is a cluster resource, which can be an abstraction of the actual physical storage system in K8s.
  • a persistent volume can be understood as a file system or block device that can be mounted inside a container, which corresponds to two working modes: Filesystem and Block.
  • a container group pod needs to use storage resources, it is necessary to reference a PVC type volume in the definition of Volume and mount the PVC to a path in the container for use. After mounting the PVC, the pod can use the storage resources.
  • the same PVC can be mounted and used by multiple pods at the same time. In this case, the application should handle the problem of multiple processes accessing the same storage.
  • the PVC corresponding to the container group can be set first, and then the PV set (that is, the persistent volume object set) that is currently in an available state can be determined, and then the PV that matches the configuration information of the PVC can be selected from the PV set that is currently in an available state. That is, multiple PVs are preliminarily screened according to the configuration information of the PVC, and PVs that do not meet the PVC conditions can be filtered out, thereby avoiding the situation where the binding of PV and PVC fails, thereby providing an accurate PV binding object for the PVC, and then establishing a binding relationship between the PVC and the selected PV.
  • the configuration information of the PVC may include but is not limited to name, binding status, storage volume name, storage space, access mode, storage type, etc.
  • the step of “for each container group, setting a source persistent volume declaration and a source persistent volume object corresponding to the container group, and storing the container group based on the source persistent volume object” may include:
  • For each container group set a source persistent volume declaration corresponding to the container group, where the source persistent volume declaration includes the storage capacity and file system type required by the container group;
  • the data of the container group is stored in the data storage area pointed to by the source persistent volume object.
  • the available state may specifically refer to a state that has not been bound to a PVC.
  • the persistent volume object set includes at least one persistent volume object that is currently in the available state.
  • the binding relationship between the source persistent volume object and the source persistent volume declaration is established, specifically, the object attribute identifier of the source persistent volume object is written into the configuration information of the source persistent volume declaration. According to the binding relationship and the source persistent volume declaration, the source persistent volume object corresponding to the source persistent volume declaration can be determined, so that the data of the container group is stored in the data storage area pointed to by the source persistent volume object.
  • K8s provides two resource types, Persistent Volume Object (PV) and Persistent Volume Claim (PVC), to meet the needs of container data persistence.
  • PV Persistent Volume Object
  • PVC Persistent Volume Claim
  • Each PV can correspond to a storage space, such as a storage volume on a server.
  • Containers are a type of resource in K8s.
  • the container resource specifies the PVC to be used in its own configuration.
  • the specified PVC specifies the storage size, storage mode and other storage resource configuration information to be used in its own configuration.
  • K8s The storage resource configuration information is paired in the current kubernetes system. If there is a PV that meets the requirements declared in the storage resource configuration information of the PVC, the PV can be bound to the PVC.
  • the database is a typical application of cloud-native stateful services, which has high requirements for efficient data access and persistent storage. Persistent data storage is generally implemented through PV.
  • PV Persistent data storage
  • the container in the pod can use the corresponding mounted disk directory.
  • CSI is the interface standard defined by K8s for container storage configuration. This standard defines interfaces for creating persistent volumes, deleting persistent volumes, and snapshots. Any storage that implements the CSI specification can be used as the backend storage of K8s. In K8s, the storage snapshot function can be implemented through the CSI Snapshotter controller.
  • each container group pod will set a PVC to declare the required storage attribute information, such as storage capacity and volume mode.
  • the required storage capacity can be declared as 20Gi and the volume mode can be file system.
  • the underlying CSI plug-in can implement the specific PV persistent storage.
  • the attribute information of the PV can include storage capacity (such as 20Gi), storage type (such as cbs-ssd), and recycling strategy.
  • the underlying layer of PV is associated with a real hard disk Disk (specifically, a cloud hard disk) system.
  • the attribute information of the Disk may include region, zone, disk capacity (such as 20Gi), type (such as a solid-state drive SSD), etc.
  • the use of the hard disk will be billed according to the cloud service standard, for example, it can be charged on an annual or monthly basis, or by volume.
  • the recycling strategy can be a retention strategy (Retain), which means that the corresponding PV will be retained when the PVC is deleted.
  • Storage class (SC, StorageClass) can be used to classify different specifications and hard disk performance into specific types, allowing businesses to choose according to needs and flexibly control costs.
  • storage resources are independently managed resources relative to container groups (pods) and can be deleted separately.
  • the system will detect whether the storage resources are currently in use. If they are still in use, the deletion of the relevant resources will be postponed until they are no longer in use. This ensures that resources will not be directly deleted if they are in use, resulting in data loss.
  • the PV bound to the PVC will be marked as "released", but it cannot be immediately bound to other PVCs because the data written by the previous PVC may still be left on the storage device. Only after clearing this data can the PV be used again.
  • the administrator can set a resource recovery policy (ReclaimPolicy) for the PV.
  • the resource recovery policy of PV can be set to Retain policy.
  • Retain policy means that after deleting PVC, the PV bound to it will not be deleted, but only marked as released. Therefore, the data in the PV still exists and cannot be used by new PVC before it is cleared. It needs to be cleaned up by the administrator before it can be used again.
  • the cleaning steps can be as follows:
  • the container group pod accesses the PV by using PVC.
  • the pod needs to be in the same namespace as the PVC.
  • the PVC will be bound to the appropriate PV in the cluster and the PV will be mounted on the Pod.
  • the backup trigger condition is also the condition for triggering the snapshot of the business cluster instance, which can be set according to the actual situation, and this embodiment does not limit this.
  • the backup trigger condition can be that the business cluster instance is deleted, or that the current time meets the backup trigger time condition of the business cluster instance.
  • Snapshot also known as Snapshot, is a common service for storage data volumes. It can be used to record the data content status of the storage data volume at a certain point in the past. It can restore the data content status to the specified point in time after the storage data volume is damaged or data is written incorrectly, which is of great significance for the protection of data content.
  • the user's database stateful service can take full snapshots regularly according to business needs, or automatically take full snapshots in the event of accidental deletion, so that the data and business cluster instance can be quickly restored to normal operation later.
  • the backup persistent volume declaration is also a persistent volume snapshot declaration, which represents an abstract resource object of a persistent volume snapshot. It can be recorded as VSS, which stands for Volume Snapshot.
  • the backup persistent volume object is also the persistent volume snapshot content, which represents the abstract resource object of the persistent volume snapshot content and is associated with the real backend snapshot storage resources, such as COS/NFS, etc.
  • the backup persistent volume object can be recorded as VSC, the full name of which is Volume Snapshot Content.
  • COS Cloud Object Storage
  • NFS Network File System
  • the step of “when the business cluster instance meets the backup trigger condition, for each container group, according to the source persistent volume declaration and source persistent volume object corresponding to the container group, create a backup persistent volume declaration and a backup persistent volume object corresponding to the container group” may include:
  • a backup persistent volume declaration and a backup persistent volume object corresponding to the container group are created according to the source persistent volume declaration and the source persistent volume object corresponding to the container group.
  • the backup trigger condition may be set as the business cluster instance being deleted and in a backup start state.
  • the backup start state may specifically refer to the snapshot switch of the business cluster instance being in an on state.
  • the backup device of the business cluster instance provided by this application will automatically create a snapshot for backup, specifically including the backup of disk persistent volume data and sub-resource metadata.
  • Cluster Preset is a business cluster instance template, which specifically refers to a pre-configured specification template of a business cluster instance.
  • the pre-configured specification template may include the image, cpu/memory, parameter configuration, etc. of the corresponding component.
  • the present application can also propose another technical solution for automatic snapshot generation, that is, the application administrator automatically manages the snapshot generation process of the specified storage data volume by pre-setting the snapshot time.
  • the step of “when the business cluster instance meets the backup trigger condition, for each container group, according to the source persistent volume declaration and source persistent volume object corresponding to the container group, create a backup persistent volume declaration and a backup persistent volume object corresponding to the container group” may include:
  • a backup persistent volume declaration and a backup persistent volume object corresponding to the container group are created according to the source persistent volume declaration and the source persistent volume object corresponding to the container group.
  • the backup trigger time condition can be set according to actual conditions, and this embodiment does not limit this.
  • the backup trigger time condition can be set to take a snapshot at 02:00 am every day.
  • the user can set a scheduled snapshot strategy, such as a scheduled snapshot strategy that can perform a backup every hour or every day at 02:00 am.
  • a scheduled snapshot strategy such as a scheduled snapshot strategy that can perform a backup every hour or every day at 02:00 am.
  • the backup device of the business cluster instance will perform regular snapshot backups according to the time strategy specified by the user.
  • For each container group based on the source persistent volume object corresponding to the container group, obtain the data to be backed up of the container group.
  • the source persistent volume object points to the data storage area of its corresponding container group. Therefore, the data storage address of its corresponding container group can be determined according to the source persistent volume object, and then the data to be backed up of the container group can be obtained according to the data storage address.
  • the service cluster instance includes at least one service component, and the service component includes at least one container group;
  • the step of “obtaining the to-be-backed data of the container group based on the source persistent volume object corresponding to the container group” may include:
  • the to-be-backed up data of the container group is obtained from the data storage area.
  • this embodiment can first determine the instance data storage area of the business cluster instance to which the container group belongs, and then further determine the component data storage area of the business component to which the container group belongs, and then determine the data storage area of the container group. In this way, the data storage area of the container group can be quickly determined through layer-by-layer progressive query.
  • the step of "for each container group, according to the backup persistence corresponding to the container group Volume declaration, backing up the to-be-backed-up data of the container group to the storage area pointed to by the backup persistent volume object corresponding to the container group”, may include:
  • the to-be-backed-up data of the container group is backed up to the storage area pointed to by the backup persistent volume object corresponding to the container group.
  • the backup persistent volume object corresponding to the backup persistent volume declaration can be determined according to the backup persistent volume declaration and binding relationship corresponding to the container group, so that the backup data of the container group stored in the source persistent volume object can be written to the storage area pointed to by the backup persistent volume object.
  • the step of “for each container group, establishing a binding relationship between a backup persistent volume declaration and a backup persistent volume object corresponding to the container group” may include:
  • the object attribute identifier is written into the configuration information of the backup persistent volume declaration corresponding to the container group to establish a binding relationship between the backup persistent volume declaration corresponding to the container group and the backup persistent volume object.
  • the object attribute identifier is specifically a unique identifier assigned by the backup system of the business cluster instance to the backup persistent volume object, and the object attribute identifier is used to uniquely identify the backup persistent volume object.
  • the object attribute identifier of the backup persistent volume object is written into the configuration information of the backup persistent volume declaration. Specifically, the binding object information in the configuration information of the backup persistent volume declaration is updated to the object attribute identifier of the backup persistent volume object.
  • VSS/VSC can be created from PVC/PV for each container group by calling relevant interfaces, so that the underlying storage creates a Snapshot from the Disk cloud hard disk, wherein PVC and PV, as well as VSS and VSC, have an ID (Identity document, identification information) binding relationship with each other, see Figure 1e.
  • multiple snapshot requests may be initiated for the same business cluster instance at different time points, and a 1:N number of snapshots may be generated, each of which may be used to restore a different target instance.
  • the disk ID of the Snapshot indicates the source attribute of the snapshot, that is, the snapshot is backed up from the disk cloud hard disk.
  • the snapshot in Figure 1e can be understood as a storage space, which can specifically indicate the storage area pointed to by the backup persistent volume object to which the data to be backed up of the container group is backed up.
  • a VSS and a VSC corresponding to the container group can be created according to the PVC and PV corresponding to the container group, and then the data to be backed up of the container group in the cloud hard disk disk is determined based on the PV, so that according to the VSS, the data to be backed up of the container group is backed up to the storage area pointed to by the VSC, so as to realize the migration of the data in the cloud hard disk disk to the storage area pointed to by the VSC in the snapshot.
  • the backup method of the service cluster instance may further include:
  • the dependent resources are backed up.
  • the dependent resources of the business cluster instance may specifically be sub-resources existing in the business cluster instance.
  • a business cluster instance may have various sub-resources, such as Probe, SchedulerPolicy, WorkloadConfig, etc.
  • These sub-resources are specifically CRD (Custom Resources Definition) resource objects extended by K8s APIService, which are all necessary for the operation of the business cluster instance. Therefore, when performing a snapshot backup of the business cluster instance, in addition to backing up the disk data corresponding to PVC/PV, all dependent sub-resources need to be snapshotted.
  • CRD Customer Resources Definition
  • the backup of sub-resources can utilize K8s' backend storage to store metadata related to sub-resources in etcd. Because K8s APIService supports customizing its own etcd backend storage, extended resources and sub-resource objects can be stored in its own etcd backend cluster by version (such as v1alpha/v1beta), and high availability (HA) across availability zones (AZs) is guaranteed.
  • K8s APIService supports customizing its own etcd backend storage
  • extended resources and sub-resource objects can be stored in its own etcd backend cluster by version (such as v1alpha/v1beta), and high availability (HA) across availability zones (AZs) is guaranteed.
  • etcd is an open source distributed unified key-value storage used for shared configuration, service discovery, and scheduling coordination of distributed systems or computer clusters.
  • the sub-resource object that is, the dependent resource of the business cluster instance, can specifically represent a resource (Resource) closely related to the property, method or operation, and use a separate permission control strategy.
  • this embodiment can determine the business cluster instance to be backed up, and the business cluster instance includes at least one container group; for each container group, set the source persistent volume declaration and source persistent volume object corresponding to the container group, and store the container group based on the source persistent volume object, the source persistent volume declaration is used to declare the storage attribute information required by the container group, and the source persistent volume object points to the data storage area of the container group; when the business cluster instance meets the backup trigger condition, for each container group therein, according to the source persistent volume declaration and source persistent volume object corresponding to the container group, create a backup persistent volume declaration and backup persistent volume object corresponding to the container group; for each container group therein, based on the source persistent volume object, obtain the data to be backed up of the container group; for each container group, according to the backup persistent volume declaration corresponding to the container group, back up the data to be backed up of the container group to the storage area pointed to by the backup persistent volume object corresponding to the container group, thereby realizing the data backup of each container group in
  • the present application when backing up a business cluster instance, creates a corresponding backup persistent volume declaration and a backup persistent volume object for each container group therein, obtains the data to be backed up of the container group from the source persistent volume object corresponding to the container group, and then backs up the data to be backed up of the container group to the storage area pointed to by the backup persistent volume object according to the backup persistent volume declaration; in this way, data backup of each container group in the business cluster instance is achieved, thereby realizing the backup processing of the business cluster instance as a whole, improving the backup efficiency of the business cluster instance, and facilitating the rapid backup of the business cluster instance.
  • the recovery device for the service cluster instance may be integrated in a second electronic device, which may be a terminal or a server.
  • the business cluster instance can be a cluster instance delivered by a stateful service (database). It is denoted as Cluster. It can be a cluster composed of multiple containers, which can be a cluster managed by containers based on a container orchestration engine (Kubernetes, K8s for short), which can be used to manage containerized applications on multiple hosts in a cloud platform.
  • Database stateful service
  • K8s container orchestration engine
  • a business cluster instance may include at least one business component, and each business component may include at least one container group.
  • a container group may be responsible for the deployment of a certain business component in a business cluster instance.
  • Each container group may include at least one container.
  • a container group (pod) may be a basic scheduling unit of Kubernetes, and a container group pod may contain multiple business processes.
  • the target instance can be restored at any time according to needs within the validity period of the snapshot.
  • the restored instance is consistent with the previous data and status.
  • the same snapshot can be restored to multiple target instances on demand, and different target instances can be in different namespaces.
  • the snapshot can be set through the snapshot expiration parameter snapshot-expiration-seconds (can be accurate to seconds). After the snapshot switch is turned on, if the expiration time is not set, the default snapshot data is saved for 7 days. During this period, the user can quickly restore the target business cluster instance through the snapshot at any time.
  • For each of the container groups based on the backup data of the container group, create a target backup persistent volume declaration and a target backup persistent volume object corresponding to the container group, wherein the target backup persistent volume declaration is used to declare the storage attribute information required by the container group, and the target backup persistent volume object points to the storage area of the backup data of the container group.
  • the target backup persistent volume declaration i.e., the persistent volume snapshot declaration
  • the storage attribute information required by the container group declared by the target backup persistent volume declaration may include storage capacity, file system type, etc., which is not limited in this embodiment.
  • the target backup persistent volume object is the persistent volume snapshot content, which represents the abstract resource object of the persistent volume snapshot content and is associated with the real backend snapshot storage resources, such as COS/NFS, etc.
  • the target backup persistent volume object can be recorded as VSC'.
  • the storage area pointed to by the target backup persistent volume object stores the backup data of the container group, that is, the snapshot data.
  • the backup data can be abstracted into VSS' and VSC' resource objects.
  • the target persistent volume declaration can be a specific application for storage resources, which represents the underlying storage object abstracted for pod use, declaring the required storage capacity (such as 100G), Node exclusive or shared, file system or block device, etc., which can be recorded as PVC' (PersistentVolumeClaim).
  • PVC' PersistentVolumeClaim
  • PVC' is actually a resource demand application issued by the user to the kubernetes system.
  • the target persistent volume object is an abstraction of storage resources. It represents the storage abstraction of the underlying hard disk and is associated with the real hard disk.
  • the source persistent volume object can be recorded as PV' (PersistentVolume), which is the persistent volume content.
  • the backup data of the container group is in a first storage area, and the instance recovery request indicates to restore the service cluster instance in a second storage area;
  • the step of “for each container group, creating a target backup persistent volume declaration and a target backup persistent volume object corresponding to the container group according to the backup data of the container group” may include:
  • the binding declaration information in the initial backup persistent volume object is updated to obtain a target backup persistent volume object.
  • the first storage area and the second storage area may be storage areas under different NSs.
  • NS namespace
  • K8s uses namespaces to place a group of related resources in the same namespace to achieve resource isolation and permission restrictions.
  • the backup and recovery of the business cluster instance may be in the same NS or in different NSs.
  • the backup and recovery are not in the same NS, it is necessary to update the binding declaration information in the initial backup persistent volume object created based on the backup data.
  • the binding declaration information can be corrected to the target backup persistent volume declaration to obtain the updated target backup persistent volume object.
  • the binding declaration information in the initial backup persistent volume object may be a VolumeSnapshotRef parameter field, and the VolumeSnapshotRef parameter field is used to reference the corresponding VolumeSnapshot.
  • each container group in the business cluster instance is run according to the target persistent volume declaration and target persistent volume object corresponding to each container group in the business cluster instance, thereby restoring the operation of each container group in the business cluster instance.
  • the step of “running the container group according to the target persistent volume declaration and the target persistent volume object corresponding to the container group” may include:
  • the container group is run.
  • the step of “binding the target persistent volume declaration and the target persistent volume object corresponding to the container group” may include:
  • the object attribute identifier is written into the configuration information of the target persistent volume declaration corresponding to the container group to establish a binding relationship between the target persistent volume declaration and the target persistent volume object.
  • the object attribute identifier is specifically a unique identifier assigned by the recovery system of the business cluster instance to the target persistent volume object, and the object attribute identifier is used to uniquely identify the target persistent volume object.
  • the object attribute identifier of the target persistent volume object is written into the configuration information of the target persistent volume declaration. Specifically, the binding object information in the configuration information of the target persistent volume declaration is updated to the object attribute identifier of the target persistent volume object.
  • the business data recovery process starts from the snapshot Snapshot (specifically, the backup data corresponding to business cluster instance 1).
  • VSS' and VSC' resource objects are created based on the backup data of the container group, and the VSS' and VSC' resource objects are bound to each other, and the ReadyToUse status of the two is true.
  • PVC' and PV' are created with VSS' and VSC' as data sources.
  • PVC' and PV' are bound to each other and the status is Bound, they can be used by the pod of the target business cluster instance, and the backup data is migrated and copied from the snapshot to the disk hard disk. The pod will then run, and finally the target business cluster instance will run normally.
  • the restored target business cluster instance can be recorded as business cluster instance 2.
  • Business cluster instance 2 is consistent with the data in the previous business cluster instance 1. The status remains consistent.
  • the backup and recovery of the service cluster instance may be in the same NS or in different NSs.
  • the backup and recovery process in the same NS is shown in Figure 2b.
  • the backup and recovery method of the service cluster instance provided in this application can also realize the cross-NS recovery of the service cluster instance.
  • the backup data (snapshot data) corresponding to the container group is in the ns1 storage area, and the instance recovery request indicates recovery in the ns2 storage area.
  • the specific implementation is: for each container group of the target business cluster instance to be restored, create VSC' based on the backup data of the container group, then create VSS' under the target NS (specifically, the ns2 storage area), and then change the VolumeSnapshotRef in VSC' to VSS' under the target NS. After that, the VSS controller inside K8s will tune VSS' and VSC' to be bound to each other and the status ReadyToUse is true.
  • create PVC' and PV' with VSS' and VSC' as data sources wait for them to be bound to each other and the status is Bound, then they can be used by the pod of the target business cluster instance, and the pod will run further, finally making the target business cluster instance run normally.
  • the step of “running the container group according to the target persistent volume declaration and the target persistent volume object corresponding to the container group” may include:
  • the container group is run according to the backup data corresponding to the dependent resource, the target persistent volume declaration and the target persistent volume object corresponding to the container group.
  • the dependent resources of the business cluster instance may specifically be sub-resources existing in the business cluster instance.
  • business cluster instances may have various sub-resources, such as Probe, SchedulerPolicy, WorkloadConfig, etc.
  • These sub-resources are specifically CRD resource objects extended by K8s APIService, which are all necessary for the operation of business cluster instances. Therefore, when performing a snapshot backup of a business cluster instance, in addition to backing up the disk data corresponding to PVC/PV, all dependent sub-resources need to be snapshotted.
  • CRD is a user-defined resource.
  • a stateful service instance depends on many sub-resources. If these sub-resources also depend on underlying persistent volume resources, the sub-resources can be packaged as a whole and uploaded to COS or NFS. Then, the sub-resource references after the package upload can be saved for backup. This can reduce the complexity of the overall backup and recovery logic of the business cluster instance and improve efficiency.
  • FIG. 2d it is the overall backup and recovery process of the business cluster instance, and the process is described as follows:
  • business cluster instance 1 By calling the business delivery interface, create a source business cluster instance (referred to as business cluster instance 1, src-cluster1). After business cluster instance 1 is initialized and data is persistently written and runs normally, a snapshot backup request can be initiated through the interface.
  • business cluster instance 1, src-cluster1 After business cluster instance 1 is initialized and data is persistently written and runs normally, a snapshot backup request can be initiated through the interface.
  • the backend will dynamically create a CSS (cluster instance snapshot) resource object based on the snapshot backup request, and then hand it over to the corresponding Snapshot-controller (snapshot controller) for reconciliation, and finally create the backup data of the data backup VSS, VSC, Snapshot (snapshot data) and sub-resource (sub-resource).
  • the table The snapshot backup process is successful. If the source business cluster instance needs to be deleted at this time, the GC-controller (Garbage Collector Controller) can safely delete the source business cluster instance.
  • the business can initiate a request to restore the target business cluster instance at any time according to demand.
  • the backend will start from the snapshot, create the VSS' and VSC' resource objects of the target instance, and bind the VSS' and VSC' resource objects to each other, and the ReadyToUse status of the two is true.
  • PVC' and PV' are created with VSS' and VSC' as data sources.
  • PVC' and PV' are bound to each other and the status is Bound, they can be used by the pod of the target business cluster instance, and the backup data will be migrated and copied from the snapshot to the disk cloud hard disk.
  • the pod will run, and the business components will run normally, and finally the target business cluster instance will run normally.
  • the target business cluster instance that is restored can be recorded as business cluster instance 2.
  • the data and status of business cluster instance 2 are consistent with those of the previous business cluster instance 1.
  • CSS ClusterSnapshot
  • CRD Customer Resources Definition
  • This application can quickly back up and restore database cluster instances and dependent sub-resources from the overall database instance level, not only realizing on-demand snapshots at any time, but also providing quick services immediately after a business instance is accidentally deleted, ensuring the security and stability of business data.
  • a snapshot can be automatically created for backup, including disk persistent volume data and sub-resource metadata, which can be used to quickly restore a business instance.
  • the generated snapshots can support a variety of back-end storage, such as COS object storage, NFS, cloud snapshots, etc., and their costs are much lower than ordinary cloud hard disks, so they can bring significant cost reduction and efficiency improvement effects to the business.
  • back-end storage such as COS object storage, NFS, cloud snapshots, etc.
  • the Snapshot-controller will retry through Exponential Backoff.
  • the retry may fail.
  • the Backoff counter can be reset in an appropriate way to quickly restore the backup process to normal.
  • snapshots can also be implemented based on XFS Reflink, which can further improve efficiency.
  • This application can provide a fast backup and recovery system for Kubernetes cluster stateful services, which can realize the fast backup and recovery of the entire instance and sub-resources of the database stateful service, so that the business instance can be quickly restored and run normally.
  • it also supports cross-NS business instance backup and recovery, and automatically backs up the entire instance (specifically, it may include dependent sub-resources) when the user deletes it by mistake, ensuring the security and stability of the business.
  • this embodiment can obtain the backup data of each container group in the business cluster instance when receiving an instance recovery request for the business cluster instance; for each container group therein, based on the backup data of the container group, create a target backup persistent volume declaration and a target backup persistent volume object corresponding to the container group, the target backup persistent volume declaration is used to declare the storage attribute information required by the container group, and the target backup persistent volume object points to the storage area of the backup data of the container group; for each container group therein, based on the target backup persistent volume declaration and the target backup persistent volume object corresponding to the container group, create a target persistent volume declaration and a target persistent volume object corresponding to the container group; according to the target persistent volume declaration and the target persistent volume object corresponding to the container group, run the container group, thereby restoring the operation of each container group in the business cluster instance.
  • the present application creates a target persistent volume declaration and a target persistent volume object for each container group in the business cluster instance to be restored.
  • the corresponding target backup persistent volume declaration and target backup persistent volume object are obtained, and based on the target backup persistent volume declaration and the target backup persistent volume object, the corresponding target persistent volume declaration and target persistent volume object are created; then, based on the created target persistent volume declaration and the target persistent volume object, the container group is run, so that the operation of each container group in the business cluster instance is restored in this way, that is, the overall recovery processing of the business cluster instance is realized, the recovery efficiency of the business cluster instance is improved, and it is conducive to the rapid recovery of the business cluster instance.
  • the embodiment of the present application also provides a backup and recovery system for a business cluster instance.
  • the backup and recovery system for the business cluster instance includes a backup device 31 for the business cluster instance and a recovery device 32 for the business cluster instance.
  • the backup device 31 for the business cluster instance may include a determination unit 3101, a storage unit 3102, a first creation unit 3103, a first acquisition unit 3104, and a backup unit 3105;
  • the recovery device 32 for the business cluster instance may include a second acquisition unit 3201, a second creation unit 3202, a third creation unit 3203, and an operation unit 3204, as follows:
  • the determining unit is used to determine a service cluster instance to be backed up, wherein the service cluster instance includes at least one container group.
  • a storage unit is used to set a source persistent volume declaration and a source persistent volume object corresponding to each container group, and store the container group based on the source persistent volume object, wherein the source persistent volume declaration is used to declare the storage attribute information required by the container group, and the source persistent volume object points to the data storage area of the container group.
  • the storage unit may include a setting subunit, a set acquisition subunit, a creation subunit and a storage subunit, as follows:
  • the setting subunit is used to set, for each container group, a source persistent volume declaration corresponding to the container group, wherein the source persistent volume declaration includes a storage capacity and a file system type required by the container group;
  • the storage subunit is used to store the data of the container group in the data storage area pointed to by the source persistent volume object according to the source persistent volume declaration and the binding relationship.
  • the first creation unit is used to create, for each container group, a backup persistent volume declaration and a backup persistent volume object corresponding to the container group according to the source persistent volume declaration and the source persistent volume object corresponding to the container group when the business cluster instance meets the backup trigger condition.
  • the first creation unit can be specifically used to create, for each container group, a backup persistent volume declaration and a backup persistent volume object corresponding to the container group based on the source persistent volume declaration and the source persistent volume object corresponding to the container group when it is detected that the business cluster instance is deleted and is in a backup startup state.
  • the first creation unit may be specifically configured to, when the current time satisfies the backup trigger time condition of the service cluster instance, for each of the container groups, generate a backup trigger time condition according to the corresponding backup trigger time condition of the container group.
  • the source persistent volume declaration and the source persistent volume object create a backup persistent volume declaration and a backup persistent volume object corresponding to the container group.
  • the first acquisition unit is configured to acquire, for each container group, the to-be-backed data of the container group based on a source persistent volume object corresponding to the container group.
  • the service cluster instance includes at least one service component, and the service component includes at least one container group;
  • the first acquisition unit may include a first determination subunit, a second determination subunit, a third determination subunit and a data acquisition subunit, as follows:
  • the first determining subunit is used to determine the instance data storage area of the business cluster instance to which the container group belongs based on the instance address information in the source persistent volume object corresponding to the container group;
  • a second determining subunit is configured to determine, from the instance data storage area, a component data storage area of the business component to which the container group belongs based on component address information in a source persistent volume object corresponding to the container group;
  • a third determining subunit is used to determine the data storage area of the container group from the component data storage area according to the container group address information in the source persistent volume object corresponding to the container group;
  • the data acquisition subunit is used to acquire the to-be-backed up data of the container group from the data storage area.
  • the backup unit is used to back up the to-be-backed-up data of the container group to the storage area pointed to by the backup persistent volume object corresponding to the container group for each of the container groups according to the backup persistent volume declaration corresponding to the container group.
  • the backup unit may include a first binding subunit and a backup subunit, as follows:
  • the first binding subunit is used to establish, for each of the container groups, a binding relationship between a backup persistent volume declaration and a backup persistent volume object corresponding to the container group;
  • the backup subunit is used to back up the to-be-backed-up data of the container group to the storage area pointed to by the backup persistent volume object corresponding to the container group according to the backup persistent volume declaration corresponding to the container group and the binding relationship.
  • the first binding sub-unit can be specifically used to obtain, for each of the container groups, an object attribute identifier of the backup persistent volume object corresponding to the container group; and write the object attribute identifier into the configuration information of the backup persistent volume declaration corresponding to the container group to establish a binding relationship between the backup persistent volume declaration corresponding to the container group and the backup persistent volume object.
  • the backup device of the service cluster instance may further include a dependent resource backup unit, as follows:
  • the dependent resource backup unit is used to analyze the resource reference association relationship of the business cluster instance, determine the dependent resources of the business cluster instance, and back up the dependent resources.
  • the second acquisition unit is configured to acquire the backup data of each container group in the service cluster instance when receiving an instance recovery request for the service cluster instance.
  • the second creation unit is used to create, for each of the container groups, a target backup persistent volume declaration and a target backup persistent volume object corresponding to the container group according to the backup data of the container group, wherein the target backup persistent volume declaration is used to declare the storage attribute information required by the container group, and the target backup persistent volume object points to the storage area of the backup data of the container group.
  • the backup data of the container group is in a first storage area, and the instance recovery request indicates to restore the service cluster instance in a second storage area;
  • the second creation unit may include a creation subunit and an update subunit, as follows:
  • the creation subunit is used to create, for each of the container groups, an initial backup persistent volume object and a target backup persistent volume declaration in the second storage area according to the backup data of the container group;
  • An updating subunit is used to update the binding declaration information in the initial backup persistent volume object based on the target backup persistent volume declaration to obtain the target backup persistent volume object corresponding to the container group.
  • the third creation unit is used to create, for each container group, a target persistent volume declaration and a target persistent volume object corresponding to the container group according to the target backup persistent volume declaration and the target backup persistent volume object corresponding to the container group.
  • the running unit is used to run the container group according to the target persistent volume declaration and the target persistent volume object corresponding to the container group.
  • the operation unit may include a second binding subunit and an operation subunit, as follows:
  • the second binding subunit is used to bind the target persistent volume declaration and the target persistent volume object corresponding to the container group;
  • the running subunit is used to run the container group when the target persistent volume declaration and the target persistent volume object are bound to each other.
  • the second binding sub-unit can be specifically used to obtain the object attribute identifier of the target persistent volume object of the container group; write the object attribute identifier into the configuration information of the target persistent volume declaration corresponding to the container group to establish a binding relationship between the target persistent volume declaration and the target persistent volume object.
  • the operation unit may include a dependent resource acquisition subunit and an instance operation subunit, as follows:
  • the dependent resource acquisition subunit is used to acquire the backup data corresponding to the dependent resources of the service cluster instance
  • the instance running subunit is used to run the container group according to the backup data corresponding to the dependent resources, the target persistent volume declaration and the target persistent volume object corresponding to the container group.
  • the business cluster instance to be backed up can be determined by the determination unit 3101, and the business cluster instance includes at least one container group; for each container group, the source persistent volume declaration and the source persistent volume object corresponding to the container group are set by the storage unit 3102, and the container group is stored based on the source persistent volume object, and the source persistent volume declaration is used to declare the storage attribute information required by the container group, and the source persistent volume object points to the data storage area of the container group; when the business cluster instance meets the backup trigger condition, for each container group therein, the first creation unit 3103 According to the source persistent volume declaration and source persistent volume object corresponding to the container group, a backup persistent volume declaration and a backup persistent volume object corresponding to the container group are created; the first acquisition unit 3104 acquires the data to be backed up of the container group based on the source persistent volume object; for each container group, the backup unit 3105 backs up the data to be backed up of the container group to the storage area pointed to by the backup persistent volume object
  • the second acquisition unit 3201 acquires the backup data of each container group in the business cluster instance; for each container group, the second creation unit 3202 creates a target backup persistent volume declaration and a target backup persistent volume object corresponding to the container group based on the backup data of the container group, the target backup persistent volume declaration being used to declare the storage attribute information required for the container group, and the target backup persistent volume object pointing to the storage area of the backup data of the container group; the third creation unit 3203 creates a target persistent volume declaration and a target persistent volume object corresponding to the container group based on the target backup persistent volume declaration and the target backup persistent volume object; the running unit 3204 runs the container group based on the target persistent volume declaration and the target persistent volume object corresponding to the container group to restore the operation of each container group in the business cluster instance.
  • This application can perform backup and recovery processing on the entire business cluster instance, improve the backup efficiency and recovery efficiency of the business cluster instance, and facilitate the rapid backup and recovery of the business cluster instance.
  • the embodiment of the present application further provides an electronic device, as shown in FIG4 , which shows a schematic diagram of the structure of the electronic device involved in the embodiment of the present application, and the electronic device may be a terminal or a server, etc. Specifically:
  • the electronic device may include components such as a processor 401 with one or more processing cores, a memory 402 with one or more computer-readable storage media, a power supply 403, and an input unit 404.
  • a processor 401 with one or more processing cores
  • a memory 402 with one or more computer-readable storage media
  • a power supply 403 with one or more computer-readable storage media
  • an input unit 404 may be included in the electronic device.
  • FIG4 does not limit the electronic device, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently. Among them:
  • the processor 401 is the control center of the electronic device, and uses various interfaces and lines to connect various parts of the entire electronic device. By running or executing software programs and/or modules stored in the memory 402, and calling data stored in the memory 402, the processor 401 performs various functions of the electronic device and processes data.
  • the processor 401 may include one or more processing cores; preferably, the processor 401 may integrate an application processor and a modem processor, wherein the application processor mainly processes the operating system, user interface, and application programs, and the modem processor mainly processes wireless communications. It is understandable that the above-mentioned modem processor may not be integrated into the processor 401.
  • the memory 402 can be used to store software programs and modules.
  • the processor 401 executes various functional applications and data processing by running the software programs and modules stored in the memory 402.
  • the memory 402 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device, etc.
  • the memory 402 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage devices. Accordingly, the memory 402 may also include a memory controller to provide the processor 401 with access to the memory 402.
  • the electronic device also includes a power supply 403 for supplying power to various components.
  • the power supply 403 can be logically connected to the processor 401 through a power management system, so that the power management system can manage charging, discharging, and power consumption.
  • the power supply 403 can also include one or more DC or AC power supplies, a recharging system, a power failure detection system, and a power supply control system. Any component such as a test circuit, power converter or inverter, power status indicator, etc.
  • the electronic device may further include an input unit 404, which may be used to receive input digital or character information and generate keyboard, mouse, joystick, optical or trackball signal input related to user settings and function control.
  • an input unit 404 which may be used to receive input digital or character information and generate keyboard, mouse, joystick, optical or trackball signal input related to user settings and function control.
  • the electronic device may also include a display unit, etc., which will not be described in detail herein.
  • the processor 401 in the electronic device will load the executable file corresponding to the process of one or more application programs into the memory 402 according to the following instructions, and the processor 401 will run the application program stored in the memory 402, thereby realizing various functions, and specifically, the operations in the backup and recovery method of the service cluster instance provided in the embodiment of the present application can be realized.
  • an embodiment of the present application provides a computer-readable storage medium, in which multiple instructions are stored.
  • the instructions can be loaded by a processor to execute the steps in any service cluster instance backup and recovery method provided in the embodiment of the present application.
  • the computer readable storage medium may include: read-only memory (ROM), random access memory (RAM), disk or CD, etc.
  • the instructions stored in the computer-readable storage medium can execute the steps in the backup and recovery method of any business cluster instance provided in the embodiments of the present application, the beneficial effects that can be achieved by the backup and recovery method of any business cluster instance provided in the embodiments of the present application can be achieved. Please refer to the previous embodiments for details and will not be repeated here.
  • a computer program product or a computer program includes computer instructions, the computer instructions are stored in a computer-readable storage medium.
  • a processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the method provided in various optional implementations of the backup and recovery of the above-mentioned service cluster instance.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请公开了一种业务集群实例的备份和恢复方法以及相关设备，相关实施例可应用于云技术、人工智能、智慧交通、辅助驾驶等各种场景；涉及数据库的数据备份，具体可针对待备份的业务集群实例中各容器组，设置容器组对应的源持久卷声明和源持久卷对象，基于源持久卷对象对容器组进行存储；当业务集群实例满足备份触发条件时，针对各容器组，根据容器组对应的源持久卷声明和源持久卷对象，创建容器组的备份持久卷声明和备份持久卷对象；基于源持久卷对象获取容器组的待备份数据；根据容器组的备份持久卷声明，将待备份数据备份至备份持久卷对象指向的存储区域，以实现业务集群实例中各容器组的数据备份。本申请提高了业务集群实例的备份效率。

Description

业务集群实例的备份和恢复方法以及相关设备
本申请要求于2022年10月12日提交中国专利局、申请号为2022112478396、申请名称为“业务集群实例的备份和恢复方法以及相关设备”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及计算机技术领域，具体涉及业务集群实例的备份和恢复技术。
背景技术
Kubernetes是一个开源的容器编排引擎，支持自动化部署、大规模可伸缩、应用容器化管理。Kubernetes集群可以包括至少一个容器组，容器组中可以运行应用实例。为了保证数据存储的持续性、可恢复性、高可用性，Kubernetes集群的数据在一定程度上需要实现容灾备份。
在目前的相关技术中，无法实现数据库中业务集群实例整体的备份，备份效率较低，不能实现业务集群实例的快速备份。
发明内容
本申请实施例提供一种业务集群实例的备份和恢复方法以及相关设备，相关设备可以包括业务集群实例的备份和恢复装置、电子设备、计算机可读存储介质和计算机程序产品，可以对业务集群实例整体进行备份处理，提高了业务集群实例的备份效率，有利于实现业务集群实例的快速备份。
本申请实施例提供一种业务集群实例的备份方法，由电子设备执行，包括：
确定待备份的业务集群实例，所述业务集群实例包括至少一个容器组；
针对每个所述容器组，设置所述容器组对应的源持久卷声明和源持久卷对象，并基于所述源持久卷对象对所述容器组进行存储，所述源持久卷声明用于声明所述容器组所需的存储属性信息，所述源持久卷对象指向所述容器组的数据存储区域；
当所述业务集群实例满足备份触发条件时，针对每个所述容器组，根据所述容器组对应的源持久卷声明和源持久卷对象，创建所述容器组对应的备份持久卷声明和备份持久卷对象；
针对每个所述容器组，基于所述容器组对应的源持久卷对象，获取所述容器组的待备份数据；
针对每个所述容器组，根据所述容器组对应的备份持久卷声明，将所述容器组的待备份数据备份至所述容器组对应的备份持久卷对象指向的存储区域。
本申请实施例提供一种业务集群实例的恢复方法，由电子设备执行，包括：
当接收到针对业务集群实例的实例恢复请求时，获取所述业务集群实例中各个容器组的备份数据；
针对每个所述容器组，根据所述容器组的备份数据，创建所述容器组对应的目标备份 持久卷声明和目标备份持久卷对象，所述目标备份持久卷声明用于声明所述容器组所需的存储属性信息，所述目标备份持久卷对象指向所述容器组的备份数据的存储区域；
针对每个所述容器组，根据所述容器组对应的目标备份持久卷声明和目标备份持久卷对象，创建所述容器组对应的目标持久卷声明和目标持久卷对象；
根据所述容器组对应的目标持久卷声明和目标持久卷对象，运行所述容器组。
相应的，本申请实施例提供一种业务集群实例的备份装置，包括：
确定单元，用于确定待备份的业务集群实例，所述业务集群实例包括至少一个容器组；
存储单元，用于针对每个所述容器组，设置所述容器组对应的源持久卷声明和源持久卷对象，并基于所述源持久卷对象对所述容器组进行存储，所述源持久卷声明用于声明所述容器组所需的存储属性信息，所述源持久卷对象指向所述容器组的数据存储区域；
第一创建单元，用于当所述业务集群实例满足备份触发条件时，针对每个所述容器组，根据所述容器组对应的源持久卷声明和源持久卷对象，创建所述容器组对应的备份持久卷声明和备份持久卷对象；
第一获取单元，用于针对每个所述容器组，基于所述容器组对应的源持久卷对象，获取所述容器组的待备份数据；
备份单元，用于针对每个所述容器组，根据所述容器组对应的备份持久卷声明，将所述容器组的待备份数据备份至所述容器组对应的备份持久卷对象指向的存储区域。
相应的，本申请实施例提供一种业务集群实例的恢复装置，包括：
第二获取单元，用于当接收到针对业务集群实例的实例恢复请求时，获取所述业务集群实例中各个容器组的备份数据；
第二创建单元，用于针对每个所述容器组，根据所述容器组的备份数据，创建所述容器组对应的目标备份持久卷声明和目标备份持久卷对象，所述目标备份持久卷声明用于声明所述容器组所需的存储属性信息，所述目标备份持久卷对象指向所述容器组的备份数据的存储区域；
第三创建单元，用于针对每个所述容器组，根据所述容器组对应的目标备份持久卷声明和所述目标备份持久卷对象，创建所述容器组对应的目标持久卷声明和目标持久卷对象；
运行单元，用于根据所述容器组对应的目标持久卷声明和目标持久卷对象，运行所述容器组。
本申请实施例提供一种电子设备，包括处理器和存储器，所述存储器存储有多条指令，所述处理器加载所述指令，以执行本申请实施例提供的业务集群实例的备份和恢复方法中的步骤。
本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，其中，所述计算机程序被处理器执行时实现本申请实施例提供的业务集群实例的备份和恢复方法中的步骤。
本申请实施例还提供一种计算机程序产品，包括计算机程序或指令，该计算机程序或指令被处理器执行时实现本申请实施例提供的业务集群实例的备份和恢复方法中的步骤。
本申请实施例提供了一种业务集群实例的备份和恢复方法以及相关设备，可以确定待 备份的业务集群实例，该业务集群实例包括至少一个容器组；针对每个容器组，设置该容器组对应的源持久卷声明和源持久卷对象，并基于该源持久卷对象对该容器组进行存储，源持久卷声明用于声明该容器组所需的存储属性信息，源持久卷对象指向该容器组的数据存储区域；当业务集群实例满足备份触发条件时，针对每个容器组，根据该容器组对应的源持久卷声明和源持久卷对象，创建该容器组对应的备份持久卷声明和备份持久卷对象；针对每个容器组，基于该容器组对应的源持久卷对象，获取该容器组的待备份数据；针对每个容器组，根据该容器组对应的备份持久卷声明，将该容器组的待备份数据备份至该容器组对应的备份持久卷对象指向的存储区域，以实现业务集群实例中每个容器组的数据备份。本申请通过上述方式，在对业务集群实例进行备份时，针对其中每个容器组，创建对应的备份持久卷声明和备份持久卷对象，并从容器组对应的源持久卷对象中获取该容器组的待备份数据，进而根据备份持久卷声明，将容器组的待备份数据备份至备份持久卷对象指向的存储区；如此实现业务集群实例中各个容器组的数据备份，从而实现了对业务集群实例整体的备份处理，提高了业务集群实例的备份效率，有利于实现业务集群实例的快速备份。
附图说明
图1a是本申请实施例提供的业务集群实例的备份和恢复方法的场景示意图；
图1b是本申请实施例提供的业务集群实例的备份和恢复方法的流程图；
图1c是本申请实施例提供的业务集群实例的备份和恢复方法的说明图；
图1d是本申请实施例提供的业务集群实例的备份和恢复方法的另一说明图；
图1e是本申请实施例提供的业务集群实例的备份和恢复方法的另一说明图；
图1f是本申请实施例提供的业务集群实例的备份和恢复方法的另一说明图；
图2a是本申请实施例提供的业务集群实例的备份和恢复方法的另一流程图；
图2b是本申请实施例提供的业务集群实例的备份和恢复方法的另一说明图；
图2c是本申请实施例提供的业务集群实例的备份和恢复方法的另一说明图；
图2d是本申请实施例提供的业务集群实例的备份和恢复方法的另一说明图；
图3a是本申请实施例提供的业务集群实例的备份装置的结构示意图；
图3b是本申请实施例提供的业务集群实例的恢复装置的结构示意图；
图4是本申请实施例提供的电子设备的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
本申请实施例提供一种业务集群实例的备份和恢复方法以及相关设备，相关设备可以包括业务集群实例的备份和恢复装置、电子设备、计算机可读存储介质和计算机程序产品。
具体地，本申请实施例提供适用于第一电子设备的业务集群实例的备份装置，该第一 电子设备可以为服务器等设备；本申请实施例还提供适用于第二电子设备的业务集群实例的恢复装置，该第二电子设备可以为服务器等设备。
如图1a所示，以终端和服务器协同执行业务集群实例的备份和恢复方法为例。本申请实施例提供的业务集群实例的备份和恢复系统包括终端10和服务器11等；终端10与服务器11之间通过网络连接，比如，通过有线或无线网络连接等，其中，业务集群实例的备份和恢复装置可以集成在服务器中。
在一个实施例中，服务器11可以用于：确定待备份的业务集群实例，该业务集群实例包括至少一个容器组；针对每个容器组，设置该容器组对应的源持久卷声明和源持久卷对象，并基于该源持久卷对象对该容器组进行存储，此处的源持久卷声明用于声明该容器组所需的存储属性信息，此处的源持久卷对象指向该容器组的数据存储区域；当业务集群实例满足备份触发条件时，针对每个容器组，根据该容器组对应的源持久卷声明和源持久卷对象，创建该容器组对应的备份持久卷声明和备份持久卷对象；针对每个容器组，基于该容器组对应的源持久卷对象，获取该容器组的待备份数据；针对每个容器组，根据该容器组对应的备份持久卷声明，将该容器组的待备份数据备份至该容器组对应的备份持久卷对象指向的存储区域，如此实现业务集群实例中每个容器组的数据备份。
其中，服务器11可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(CDN，Content Delivery Network)、以及大数据和人工智能平台等基础云计算服务的云服务器。本申请所公开的业务集群实例的备份和恢复方法或装置可以应用于多个服务器，多个服务器可组成为一区块链，而服务器为区块链上的节点。
其中，终端10可以用于：向服务器11发送针对业务集群实例的数据备份指令，以使服务器11基于该数据备份指令，实现业务集群实例中每个容器组的数据备份。其中，终端10可以包括手机、智能语音交互设备、智能家电、车载终端、飞行器、平板电脑、笔记本电脑、或个人计算机(PC，Personal Computer)等。终端10上还可以设置客户端，该客户端可以是应用程序客户端或浏览器客户端等等。
在另一个实施例中，服务器11可以用于：当接收到针对业务集群实例的实例恢复请求时，获取该业务集群实例中各个容器组的备份数据；针对每个容器组，根据该容器组的备份数据，创建该容器组对应的目标备份持久卷声明和目标备份持久卷对象，该目标备份持久卷声明用于声明该容器组所需的存储属性信息，该目标备份持久卷对象指向该容器组的备份数据的存储区域；针对每个容器组，根据该容器组对应的目标备份持久卷声明和目标备份持久卷对象，创建该容器组对应的目标持久卷声明和目标持久卷对象；根据该容器组对应的目标持久卷声明和目标持久卷对象，运行该容器组，以恢复对业务集群实例中各个容器组的运行。
其中，终端10可以用于：根据业务需求，向服务器11发送针对业务集群实例的实例恢复请求，以使服务器11基于该实例恢复请求，恢复对业务集群实例中各个容器组的运行。
本申请实施例提供的业务集群实例的备份和恢复方法涉及云技术领域中的云存储和数据库方向。本实施例可应用于云技术、人工智能、智慧交通、辅助驾驶等各种场景。
本实施例将从业务集群实例的备份装置的角度进行描述，该业务集群实例的备份装置具体可以集成在第一电子设备中，该第一电子设备可以是服务器或终端等设备。需说明的是，以下实施例的描述顺序不作为对实施例优选顺序的限定。
如图1b所示，该业务集群实例的备份方法的具体流程可以如下：
101、确定待备份的业务集群实例，所述业务集群实例包括至少一个容器组。
其中，业务集群实例具体可以为一个有状态服务(数据库)发货出来的集群实例，可以记为Cluster。它可以是多个容器构成的集群，该集群可以为基于容器编排引擎(Kubernetes，简称K8s)进行容器管理的集群，该容器编排引擎可以用于管理云平台中多个主机上容器化的应用。
其中，Kubernetes是用于自动部署、扩缩和管理容器化应用程序的开源系统，它可以实现将若干个容器组合成一个服务、以及动态地分配支持容器运行的主机等功能。
具体地，业务集群实例可以包括至少一个业务组件，每个业务组件可以包括至少一个容器组。如图1c所示，业务集群实例可以抽象为三层资源管理模型，从上到下依次分别为cluster、set、pod，cluster对应于业务实例，set对应于业务组件、pod对应于容器组。比如对于LibraDB产品，cluster实例为tdach-xxx，set包括zookeeper、clickhouse，pod则分别包括zookeeper pods、clickhouse-pods，满足了数据库产品的资源管理需求。通过此资源管理模型，还可以支持各种业务产品的接入，且支持业务组件的先后启动顺序、各业务组件参数自定义配置、业务pod多分片(shards)、多副本(replicas)等特性。
其中，LibraDB是一种分布式HTAP(Hybrid Transaction and Analytical Process，混合事务和分析处理)数据库，其基于可插拔式引擎设计、强大的数据融合能力和云原生系统架构，可以为用户提供一体化产品体验。ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，clickhouse是一个用于联机分析的列式数据库管理系统。
其中，容器组可以为业务集群实例中负责某个业务组件的部署的容器组。每个容器组中可以包括至少一个容器。具体地，容器组(pod)可以为Kubernetes的基本调度单元，一个容器组pod里可以有多个业务进程。
容器是软件的可执行单元，其中应用代码与库和依赖关系以通用方式打包在一起。容器利用操作系统虚拟化的形式，通过隔离进程和控制这些进程可以访问的CPU(中央处理器，central processing unit)量、内存量和磁盘量，让多个应用共享操作系统。
102、针对每个所述容器组，设置所述容器组对应的源持久卷声明和源持久卷对象，并基于所述源持久卷对象对所述容器组进行存储，所述源持久卷声明用于声明所述容器组所需的存储属性信息，所述源持久卷对象指向所述容器组的数据存储区域。
其中，源持久卷声明具体可以是对存储资源的一个申请，它表示为Pod使用而抽象出来的底层存储对象，声明需要的存储容量(如100G)、Node(节点)独占或共用、文件系统或块设备等，可以记为PVC(PersistentVolume Claim)。具体地，PVC就是用户向kubernetes系统发出的一种资源需求申请。
其中，源持久卷声明所声明的容器组需要的存储属性信息可以包括存储容量、文件系统类型等，本实施例对此不作限制。
其中，源持久卷对象是对存储资源的抽象，它表示底层硬盘的存储抽象，关联了真正的硬盘。源持久卷对象可以记为PV(Persistent Volume)，也即持久卷内容。
需要说明的是，这里的持久卷是一种集群资源，具体可以是K8s中对实际物理存储系统的抽象。持久卷可以理解为一个能挂载到容器内部的文件系统或块设备，其对应两种工作模式Filesystem和Block。
具体地，在容器组pod需要使用存储资源时，需要在Volume的定义中引用PVC类型的卷，将PVC挂载到容器内的某个路径下进行使用。pod在挂载PVC后，就能使用存储资源了。同一个PVC可以被多个pod同时挂载使用，在这种情况下，应用程序应该处理多个进程访问同一个存储的问题。
本实施例中，可以先设置容器组对应的PVC，再确定当前处于可用状态的PV集合(也即持久卷对象集合)，再从当前处于可用状态的PV集合中选取与PVC的配置信息匹配的PV，也即根据PVC的配置信息对多个PV进行初步筛选，可以过滤掉不符合PVC条件的PV，避免了PV和PVC绑定失败的情况，从而为PVC提供准确的PV绑定对象，再将PVC与选取到的某个PV建立绑定关系。
其中，PVC的配置信息可以包括但不限于名称，绑定状态，存储卷名称，存储空间，访问模式，存储类型等。
可选地，本实施例中，步骤“针对每个容器组，设置所述容器组对应的源持久卷声明和源持久卷对象，并基于所述源持久卷对象对所述容器组进行存储”，可以包括：
针对每个容器组，设置所述容器组对应的源持久卷声明，所述源持久卷声明包括所述容器组所需的存储容量和文件系统类型；
从当前处于可用状态的持久卷对象集合中，选取与所述存储容量、所述文件系统类型匹配的持久卷对象，作为该容器组对应的源持久卷对象；并建立选取的所述源持久卷对象与所述源持久卷声明之间的绑定关系；
根据所述源持久卷声明和所述绑定关系，将所述容器组的数据存储至所述源持久卷对象指向的数据存储区域。
其中，可用状态具体可指尚未被PVC绑定的状态。持久卷对象集合包含至少一个当前处于可用状态的持久卷对象。
其中，建立源持久卷对象与源持久卷声明之间的绑定关系，具体可以是将源持久卷对象的对象属性标识写入源持久卷声明的配置信息中。根据该绑定关系和源持久卷声明，可以确定源持久卷声明对应的源持久卷对象，从而将容器组的数据存储至该源持久卷对象指向的数据存储区域。
在一实施例中，K8s提供了持久卷对象PV和持久卷声明PVC两种资源类型，来满足容器数据持久化的需求，每个PV可以对应一块存储空间，如服务器上的存储卷Volume。容器在K8s中属于一种资源，容器资源在本身配置中指定需要使用的PVC，指定的PVC则在本身配置中指定需要使用的存储大小、存储模式等存储资源配置信息，最后K8s根据 该存储资源配置信息在当前kubernetes系统中进行配对，如有符合PVC的存储资源配置信息中声明要求的PV，则可以将该PV与PVC进行绑定。
具体地，数据库是云原生有状态服务的典型应用，对数据的高效存取、持久化存储有很高的要求。数据的持久化存储一般通过PV实现，通过在pod中指定对应的PVC，调用底层CSI(Container Storage Interface,容器存储接口)插件实现云硬盘的动态插拔、格式化、挂载，这样在pod中的Container(容器)就可以使用对应挂载的磁盘目录。
其中，CSI是K8s定义的进行容器存储配置的接口标准，该标准定义了创建持久卷、删除持久卷和快照等功能的接口。任何实现了CSI规范的存储都可以作为K8s的后端存储。K8s中可通过CSI Snapshotter controller(CSI快照控制器)来实现存储快照的功能。
其中，参考图1d，每一个容器组pod将会设置一个PVC来声明所需要的存储属性信息，如存储容量和卷模式，例如，可以声明所需要的存储容量为20Gi，卷模式为文件系统(Filesystem)；在设置PVC之后，可以由底层的CSI插件实现具体的PV持久化存储实现。PV的属性信息可以包括存储容量(如20Gi)、存储类型(如cbs-ssd)、以及回收策略等。
其中，PV底层关联了真正的硬盘Disk(具体也即云硬盘)系统，Disk的属性信息可以包括区域(region)、可用区(zone)、磁盘容量(如20Gi)、类型(如固态硬盘SSD)等，硬盘的使用将按照云服务标准进行计费，例如，可按包年包月、或按量计费等。
其中，回收策略可以是保留策略(Retain)，Retain策略表示在PVC删除时会保留对应的PV。存储类型(SC，StorageClass)可以用于将不同规格、硬盘性能高低等划分为特定类型，让业务按需求进行选择，灵活控制成本。
需要说明的是，存储资源(PV、PVC)相对于容器组(pod)都是独立管理的资源，可以单独删除。在执行删除资源操作时，系统会检测存储资源当前是否正在被使用，如果仍被使用，则相关资源的删除将被推迟，直到没有被使用才会执行删除操作，这样可以确保资源在被使用的情况下不会被直接删除而导致数据丢失。
其中，具体地，用户在使用存储资源完毕后，可以删除PVC。与该PVC绑定的PV将被标记为“已释放”，但不能立即与其它PVC绑定，因为通过之前PVC写入的数据可能还被留在存储设备上，只有在清除这些数据之后，该PV才能再次使用。管理员可以对PV设置资源回收策略(ReclaimPolicy)。
一些实施例中，PV的资源回收策略可以设置为Retain策略。Retain策略表示在删除PVC之后，与之绑定的PV不会被删除，仅被标记为已释放(released)，因此PV中的数据仍然存在，在清空之前不能被新的PVC使用，需要管理员清理之后才能继续使用，其清理步骤可以如下：
(1)删除PV资源对象，此时与该PV关联的某些外部存储提供商的后端存储资产(asset)中的数据仍然存在；
(2)手工清理PV后端存储资产中的数据；
(3)手工删除后端存储资产。如果希望重用该存储资产，则可以创建一个新的PV与之关联。
本实施例中，容器组pod通过使用PVC来访问PV，pod需与PVC在同一个命名空间中，PVC会与集群中合适的PV进行绑定，并将PV挂载到Pod上。
103、当所述业务集群实例满足备份触发条件时，针对每个所述容器组，根据所述容器组对应的源持久卷声明和源持久卷对象，创建所述容器组对应的备份持久卷声明和备份持久卷对象。
其中，备份触发条件也即触发对业务集群实例快照的条件，它可以根据实际情况进行设置，本实施例对此不作限制。例如，备份触发条件可以是业务集群实例被删除，也可以是当前时间满足业务集群实例的备份触发时间条件等。
快照也称Snapshot，是存储数据卷的常见服务，其可以用于记录存储数据卷在过去某个时间点的数据内容状态，它能够在存储数据卷遭受损坏或者数据写入失误后恢复到指定时间点的数据内容状态，对于数据内容的保护有着非常重要的意义。
具体地，用户的数据库有状态服务，按业务需求，可以定期打全量快照，也可以在不慎误删的情况下自动打全量快照，以便之后可快速恢复数据及业务集群实例的正常运行。
本实施例中，备份持久卷声明也即持久卷快照声明，表示持久卷快照的抽象资源对象，它可以记为VSS，全称为Volume Snapshot。
其中，备份持久卷对象也即持久卷快照内容，表示持久卷快照内容的抽象资源对象，关联了真正的后端快照存储资源，如COS/NFS等。备份持久卷对象可以记为VSC，全称Volume Snapshot Content。
其中，COS(Cloud Object Storage)为云对象存储服务，是一种非结构化对象分布式、海量存取系统。NFS(Network File System)为网络文件系统，是一种分布式、海量存取系统。
可选地，本实施例中，步骤“当所述业务集群实例满足备份触发条件时，针对每个所述容器组，根据所述容器组对应的源持久卷声明和源持久卷对象，创建所述容器组对应的备份持久卷声明和备份持久卷对象”，可以包括：
当检测到所述业务集群实例被删除、且处于备份启动状态时，针对每个所述容器组，根据所述容器组对应的源持久卷声明和源持久卷对象，创建所述容器组对应的备份持久卷声明和备份持久卷对象。
其中，备份触发条件可以设置为业务集群实例被删除、且处于备份启动状态。备份启动状态具体可以是指业务集群实例的快照开关处于开启状态下。
具体地，在每种业务产品的Cluster Preset中，可以通过设置disable Snapshot(禁用快照)参数为true/false(真/假)进行快照开关控制，如果不设置开关值，则默认为开启。
在用户的业务集群实例销毁后，且快照开关为开启状态下，本申请提供的业务集群实例的备份装置会自动创建快照进行备份，具体包括磁盘持久卷数据和子资源元数据等的备份。
其中，Cluster Preset为业务集群实例模板，具体表示业务集群实例提前预配置的规格模板，例如，提前预配置的规格模板可以包括对应组件的image(镜像)、cpu/memory(处理器/内存)、参数配置等。
经过对生产实践的使用场景进行深入分析后，发现对存储数据卷生成快照的需求往往 具有定时和周期的特性，比如通常需要在每天晚间2点生成一次快照，再如需要在每周周末晚间2点生成一次快照等，因此本申请还可以提出另一种快照自动生成的技术方案，即应用管理员通过预先设置快照时间的方式，对指定存储数据卷的快照生成过程进行自动化管理。
可选地，本实施例中，步骤“当所述业务集群实例满足备份触发条件时，针对每个所述容器组，根据所述容器组对应的源持久卷声明和源持久卷对象，创建所述容器组对应的备份持久卷声明和备份持久卷对象”，可以包括：
当当前时间满足所述业务集群实例的备份触发时间条件时，针对每个所述容器组，根据所述容器组对应的源持久卷声明和源持久卷对象，创建所述容器组对应的备份持久卷声明和备份持久卷对象。
其中，备份触发时间条件可以根据实际情况进行设置，本实施例对此不作限制。例如，备份触发时间条件可以设置为每天凌晨02:00进行快照。
具体地，用户可设置定时快照策略，如定时快照策略可以为每小时或每天凌晨02:00进行一次备份，在设置定时快照策略后，业务集群实例的备份装置则会按照用户指定的时间策略，进行定期快照备份。
104、针对每个所述容器组，基于所述容器组对应的源持久卷对象，获取所述容器组的待备份数据。
其中，源持久卷对象指向其对应的容器组的数据存储区域，因此，可以根据源持久卷对象，来确定其对应的容器组的数据存储地址，从而根据该数据存储地址，获取容器组的待备份数据。
可选地，本实施例中，所述业务集群实例包括至少一个业务组件，所述业务组件包括至少一个容器组；
步骤“基于所述容器组对应的源持久卷对象，获取所述容器组的待备份数据”，可以包括：
基于所述容器组对应的源持久卷对象中的实例地址信息，确定所述容器组所属的业务集群实例的实例数据存储区域；
基于所述容器组对应的源持久卷对象中的组件地址信息，从所述实例数据存储区域中确定所述容器组所属的业务组件的组件数据存储区域；
根据所述容器组对应的源持久卷对象中的容器组地址信息，从所述组件数据存储区域中确定所述容器组的数据存储区域；
从所述数据存储区域中获取所述容器组的待备份数据。
其中，对于每个容器组，本实施例可以先确定该容器组所属的业务集群实例的实例数据存储区域，再进一步确定该容器组所属的业务组件的组件数据存储区域，从而再确定该容器组的数据存储区域，这样通过层层递进查询，可快速确定容器组的数据存储区域。
105、针对每个所述容器组，根据所述容器组对应的备份持久卷声明，将所述容器组的待备份数据备份至所述容器组对应的备份持久卷对象指向的存储区域。
可选地，本实施例中，步骤“针对每个所述容器组，根据所述容器组对应的备份持久 卷声明，将所述容器组的待备份数据备份至所述容器组对应的备份持久卷对象指向的存储区域”，可以包括：
针对每个所述容器组，建立所述容器组对应的备份持久卷声明和备份持久卷对象之间的绑定关系；
根据所述容器组对应的备份持久卷声明和所述绑定关系，将所述容器组的待备份数据备份至所述容器组对应的备份持久卷对象指向的存储区域。
其中，可以根据容器组对应的备份持久卷声明和绑定关系，确定备份持久卷声明对应的备份持久卷对象，从而将源持久卷对象中存储的容器组的待备份数据写入到该备份持久卷对象指向的存储区域。
可选地，本实施例中，步骤“针对每个所述容器组，建立所述容器组对应的备份持久卷声明和备份持久卷对象之间的绑定关系”，可以包括：
针对每个容器组，获取所述容器组对应的备份持久卷对象的对象属性标识；
将所述对象属性标识写入所述容器组对应的备份持久卷声明的配置信息中，以建立所述容器组对应的备份持久卷声明和备份持久卷对象之间的绑定关系。
其中，对象属性标识具体是业务集群实例的备份系统为该备份持久卷对象分配的唯一标识，对象属性标识用于唯一标识该备份持久卷对象。
其中，将备份持久卷对象的对象属性标识写入到备份持久卷声明的配置信息中，具体可以是，将备份持久卷声明的配置信息中的绑定对象信息更新为该备份持久卷对象的对象属性标识。
在一具体实施例中，当业务定期发起快照或业务集群实例销毁自动发起快照时，可以针对每个容器组，通过调用相关接口，分别从PVC/PV创建VSS/VSC，从而底层存储从Disk云硬盘创建Snapshot快照，其中，PVC和PV、以及VSS和VSC相互之间有ID(Identity document，标识信息)绑定关系，参考图1e。
在一些实施例中，可以在不同时间点，针对同一个业务集群实例发起多个快照请求，将生成1:N数量的快照，每个快照可用于恢复不同的目标实例。
其中，Snapshot快照的硬盘标识(Disk-id)表示快照的来源属性，也即快照是从disk云硬盘中备份得到的。图1e中的快照Snapshot可以理解为一个存储空间，具体可以表示上述将容器组的待备份数据备份至的备份持久卷对象指向的存储区域。
具体地，本实施例中，在满足备份触发条件时，可针对业务集群实例的每个容器组，根据容器组对应的PVC和PV，创建该容器组对应的VSS和VSC，再基于PV确定云硬盘disk中容器组的待备份数据，从而根据VSS，将容器组的待备份数据备份至VSC指向的存储区域，以实现将云硬盘disk中的数据迁移到快照中VSC指向的存储区域。
可选地，本实施例中，该业务集群实例的备份方法还可以包括：
对所述业务集群实例的资源引用关联关系进行分析，确定所述业务集群实例的依赖资源；
对所述依赖资源进行备份处理。
其中，业务集群实例的依赖资源，具体可以是业务集群实例中存在的子资源。
具体地，为满足有状态服务多种管控需求，业务集群实例可能存在各种不同的子资源，如Probe(探针)、SchedulerPolicy(调度策略)、WorkloadConfig(工作负载配置)等，这些子资源具体是通过K8s APIService扩展的CRD(Custom Resources Definition)资源对象，都是业务集群实例运行所必须依赖的，因此在进行业务集群实例快照备份时，除了将PVC/PV对应的磁盘数据进行备份，还需要将依赖的所有子资源全部进行快照备份。其中，CRD，即是用户自定义资源。
在一具体实施例中，子资源的备份可以利用K8s的后端存储，将子资源相关的元数据存储在etcd中。因K8s APIService支持自定义自己的etcd后端存储，因此可以将扩展的资源、子资源对象按版本(如v1alpha/v1beta)存储在自己的etcd后端集群中，并保证了跨可用区(AZ)的高可用(HA)。
其中，etcd是一种开源的分布式统一键值存储，用于分布式系统或计算机集群的共享配置、服务发现和的调度协调。
如图1f所示，在对业务集群实例整体进行备份时，可以根据每个容器组的PVC/PV，创建VSS/VSC，根据VSS/VSC将PV对应的磁盘数据进行备份，此外，还可以将业务集群实例依赖的所有子资源对象(SubResource)全部进行快照备份。其中，子资源对象，也即业务集群实例的依赖资源，具体地，在K8s中可以表示一个资源(Resource)紧密相关的属性、方法或操作，并使用单独的权限控制策略。
由上可知，本实施例可以确定待备份的业务集群实例，该业务集群实例包括至少一个容器组；针对每个容器组，设置该容器组对应的源持久卷声明和源持久卷对象，并基于该源持久卷对象对该容器组进行存储，该源持久卷声明用于声明该容器组所需的存储属性信息，该源持久卷对象指向该容器组的数据存储区域；当该业务集群实例满足备份触发条件时，针对其中每个容器组，根据该容器组对应的源持久卷声明和源持久卷对象，创建该容器组对应的备份持久卷声明和备份持久卷对象；针对其中每个容器组，基于该源持久卷对象，获取该容器组的待备份数据；针对每个容器组，根据该容器组对应的备份持久卷声明，将该容器组的待备份数据备份至该容器组对应的备份持久卷对象指向的存储区域，如此实现所述业务集群实例中每个容器组的数据备份。本申请通过上述方式，在对业务集群实例进行备份时，针对其中每个容器组，创建对应的备份持久卷声明和备份持久卷对象，并从容器组对应的源持久卷对象中获取该容器组的待备份数据，进而根据备份持久卷声明，将容器组的待备份数据备份至备份持久卷对象指向的存储区；如此实现业务集群实例中各个容器组的数据备份，从而实现了对业务集群实例整体的备份处理，提高了业务集群实例的备份效率，有利于实现业务集群实例的快速备份。
本实施例将从业务集群实例的恢复装置的角度进行描述，该业务集群实例的恢复装置具体可以集成在第二电子设备中，该第二电子设备可以是终端或者服务器等设备。
如图2a所示，该业务集群实例的恢复方法的具体流程如下：
201、当接收到针对业务集群实例的实例恢复请求时，获取所述业务集群实例中各个容器组的备份数据。
其中，业务集群实例具体可以为一个有状态服务(数据库)发货出来的集群实例，可 以记为Cluster。它可以是多个容器构成的集群，该集群可以为基于容器编排引擎(Kubernetes，简称K8s)进行容器管理的集群，该容器编排引擎可以用于管理云平台中多个主机上容器化的应用。
具体地，业务集群实例可以包括至少一个业务组件，每个业务组件可以包括至少一个容器组。其中，容器组可以在业务集群实例中负责某个业务组件的部署。每个容器组中可以包括至少一个容器。具体地，容器组(pod)可以为Kubernetes的基本调度单元，一个容器组pod里可以有多个业务进程。
在业务集群实例的快照创建成功后，在快照有效期内，可随时根据需求进行目标实例的恢复，恢复后运行起来的实例与之前的数据、状态都保持一致。另外，同一个快照，可以按需恢复出多个目标实例，不同目标实例可以分别处于不同的命名空间。
在一具体实施例中，快照可通过快照过期参数snapshot-expiration-seconds(可精确到秒)进行设置，快照开关开启后，如果不设置过期时间，则默认快照数据保存7天。在这段时间内，用户可随时通过快照快速恢复目标业务集群实例。
202、针对每个所述容器组，根据所述容器组的备份数据，创建所述容器组对应的目标备份持久卷声明和目标备份持久卷对象，所述目标备份持久卷声明用于声明所述容器组所需的存储属性信息，所述目标备份持久卷对象指向所述容器组的备份数据的存储区域。
其中，目标备份持久卷声明，即持久卷快照声明，表示持久卷快照的抽象资源对象，它可以记为VSS’。目标备份持久卷声明所声明的容器组需要的存储属性信息可以包括存储容量、文件系统类型等，本实施例对此不作限制。
其中，目标备份持久卷对象即持久卷快照内容，表示持久卷快照内容的抽象资源对象，关联了真正的后端快照存储资源，如COS/NFS等。目标备份持久卷对象可以记为VSC’。目标备份持久卷对象所指向的存储区域存储有容器组的备份数据，也即快照数据，本实施例可以将该备份数据抽象为VSS’和VSC’资源对象。
203、针对每个所述容器组，根据所述容器组对应的目标备份持久卷声明和目标备份持久卷对象，创建所述容器组对应的目标持久卷声明和目标持久卷对象。
其中，目标持久卷声明具体可以是对存储资源的一个申请，它表示为pod使用而抽象出来的底层存储对象，声明需要的存储容量(如100G)、Node(节点)独占或共用、文件系统或块设备等，可以记为PVC’(PersistentVolumeClaim)。具体地，PVC’其实就是用户向kubernetes系统发出的一种资源需求申请。
其中，目标持久卷对象是对存储资源的抽象，它表示底层硬盘的存储抽象，关联了真正的硬盘。源持久卷对象可以记为PV’(PersistentVolume)，也即持久卷内容。
可选地，本实施例中，所述容器组的备份数据处于第一存储区域，所述实例恢复请求指示在第二存储区域中恢复所述业务集群实例；
步骤“针对每个所述容器组，根据所述容器组的备份数据，创建所述容器组对应的目标备份持久卷声明和目标备份持久卷对象”，可以包括：
针对每个所述容器组，根据所述容器组的备份数据，创建处于所述第二存储区域中的初始备份持久卷对象和目标备份持久卷声明；
基于所述目标备份持久卷声明，对所述初始备份持久卷对象中的绑定声明信息进行更新，得到目标备份持久卷对象。
其中，第一存储区域和第二存储区域具体可以是不同NS下的存储区域。NS(Namespace)即命名空间。具体地，K8s通过命名空间将一组相关资源放在同一个命名空间内，以达到资源隔离和权限限制的目的。
具体地，业务集群实例的备份与恢复可能在同一个NS内，也可能在不同的NS。当备份与恢复不在同一个NS中时，需要对基于备份数据创建的初始备份持久卷对象中的绑定声明信息进行更新，具体可以将该绑定声明信息更正为目标备份持久卷声明，即可得到更新后的目标备份持久卷对象。
其中，初始备份持久卷对象中的绑定声明信息可以是VolumeSnapshotRef参数字段，该VolumeSnapshotRef参数字段用于对相应的VolumeSnapshot的引用。
204、根据所述容器组对应的目标持久卷声明和目标持久卷对象，运行所述容器组。
如此通过上述方式，根据业务集群实例中各个容器组各自对应的目标持久卷声明和目标持久卷对象，运行该业务集群实例中的各个容器组，从而恢复对该业务集群实例中各个容器组的运行。
可选地，本实施例中，步骤“根据所述容器组对应的目标持久卷声明和目标持久卷对象，运行所述容器组”，可以包括：
将所述容器组对应的目标持久卷声明和目标持久卷对象进行绑定；
当所述目标持久卷声明和所述目标持久卷对象互为绑定关系时，运行所述容器组。
可选地，本实施例中，步骤“将所述容器组对应的目标持久卷声明和目标持久卷对象进行绑定”，可以包括：
获取所述容器组的目标持久卷对象的对象属性标识；
将所述对象属性标识写入所述容器组对应的目标持久卷声明的配置信息中，以建立所述目标持久卷声明和所述目标持久卷对象之间的绑定关系。
其中，对象属性标识具体是业务集群实例的恢复系统为该目标持久卷对象分配的唯一标识，对象属性标识用于唯一标识该目标持久卷对象。
其中，将目标持久卷对象的对象属性标识写入目标持久卷声明的配置信息中，具体可以是，将目标持久卷声明的配置信息中的绑定对象信息更新为该目标持久卷对象的对象属性标识。
在一具体实施例中，如图2b所示，业务数据的恢复流程从快照Snapshot(具体也即业务集群实例1对应的备份数据)开始，针对待恢复的目标业务集群实例的每个容器组，基于容器组的备份数据创建VSS’和VSC’资源对象，并将VSS’和VSC’资源对象相互绑定，且二者的ReadyToUse(即用)状态为true。然后，以VSS’和VSC’为数据源创建PVC’和PV’，等待PVC’和PV’相互绑定且状态为Bound(绑定)后，即可被目标业务集群实例的pod使用，将备份数据从snapshot迁移复制到disk硬盘上，进一步pod将会运行起来，最终使得目标业务集群实例正常运行，其中，恢复运行起来的目标业务集群实例可以记为业务集群实例2，业务集群实例2与之前的业务集群实例1中数据、 状态都保持一致。
具体地，业务集群实例的备份与恢复可能在同一个NS内，也可能在不同的NS。对同一个NS内的备份与恢复的流程如图2b所示。本申请提供的业务集群实例的备份和恢复方法还可以实现业务集群实例跨NS恢复。
针对不同NS的备份与恢复，则需要特殊的逻辑处理。参考图2c，容器组对应的备份数据(快照数据)处于ns1存储区域，实例恢复请求指示在ns2存储区域中恢复，其具体实现为：针对待恢复的目标业务集群实例的每个容器组，基于容器组的备份数据创建VSC’，接着创建目标NS(具体也即ns2存储区域)下面的VSS’，然后，将VSC’里面的VolumeSnapshotRef改为目标NS下的VSS’，之后K8s内部VSS控制器会将VSS’和VSC’调谐为相互绑定且状态ReadyToUse为true。然后，以VSS’和VSC’为数据源创建PVC’和PV’，等待其相互绑定且状态为Bound后，即可被目标业务集群实例的pod使用，进一步pod将会运行起来，最终使得目标业务集群实例正常运行。
其中，对VolumeSnapshotRef的更改具体可以包括：
vsc.Spec.VolumeSnapshotRef.Name＝vss.GetName()
vsc.Spec.VolumeSnapshotRef.Namespace＝vss.GetNamespace()
vsc.Spec.VolumeSnapshotRef.UID＝vss.GetUID()
可选地，本实施例中，步骤“根据所述容器组对应的目标持久卷声明和目标持久卷对象，运行所述容器组”，可以包括：
获取所述业务集群实例的依赖资源对应的备份数据；
根据所述依赖资源对应的备份数据、所述容器组对应的目标持久卷声明和目标持久卷对象，运行所述容器组。
其中，业务集群实例的依赖资源，具体可以是业务集群实例中存在的子资源。
为满足有状态服务多种管控需求，业务集群实例可能存在各种不同的子资源，如Probe(探针)、SchedulerPolicy(调度策略)、WorkloadConfig(工作负载配置)等，这些子资源具体是通过K8s APIService扩展的CRD资源对象，都是业务集群实例运行所必须依赖的，因此在进行业务集群实例快照备份时，除了将PVC/PV对应的磁盘数据进行备份，还需要将依赖的所有子资源全部进行快照备份。其中，CRD，即是用户自定义资源。
具体地，有状态服务实例中依赖很多子资源，这些子资源若还有依赖底层持久卷资源，可将子资源打包为一个整体，上传到COS或NFS，然后保存这个打包上传后的子资源引用进行备份，可减少业务集群实例整体备份与恢复逻辑的复杂度，提高效率。
具体地，如图2d所示，为业务集群实例的总体备份恢复流程，过程描述如下：
首先，通过调用业务发货接口，创建源业务集群实例(记为业务集群实例1，src-cluster1)，等业务集群实例1经过实例初始化、数据持久化写入，正常运行起来后，可通过接口发起快照备份请求。
此时，后端将根据快照备份请求动态创建一个CSS(集群实例快照)资源对象，然后交给对应的Snapshot-controller(快照控制器)去调谐(Reconcile)，最终创建出数据备份VSS、VSC、Snapshot(快照数据)和子资源(sub-resource)的备份数据。到这一步，表 示快照备份流程成功。如果此时源业务集群实例需要删除，则GC-controller(Garbage Collector Controller，垃圾收集控制器)可安全的将源业务集群实例真正删除。
备份数据准备完成后，业务可根据需求随时发起恢复目标业务集群实例的请求，后端将从Snapshot(快照数据)开始，创建目标实例的VSS’和VSC’资源对象，并将VSS’和VSC’资源对象相互绑定，且二者的ReadyToUse(即用)状态为true。然后，以VSS’和VSC’为数据源创建PVC’和PV’，等待PVC’和PV’相互绑定且状态为Bound(绑定)后，即可被目标业务集群实例的pod使用，将备份数据从snapshot迁移复制到disk云硬盘上，进一步pod将会运行起来，进一步业务组件也会正常运行，最终使得目标业务集群实例正常运行，其中，恢复运行起来的目标业务集群实例可以记为业务集群实例2，业务集群实例2与之前的业务集群实例1中数据、状态都保持一致。
其中，CSS(ClusterSnapshot):即集群实例快照，自定义的CRD(Custom Resources Definition，用户自定义资源)对象，表示一个业务集群实例的快照抽象实体对象，里面包括了备份相关的元数据。
本申请从数据库实例整体水平，可快速备份与恢复数据库集群实例及依赖的子资源，不仅实现业务按需随时打快照，而且在业务实例误删后可第一时间快速服务，保证业务数据的安全稳定。此外，用户不慎误删实例后，还可以自动创建快照进行备份，包括磁盘持久卷数据和子资源元数据等，可用于快速恢复业务实例。
另外，生成的快照可支持多种后端存储，如COS对象存储、NFS、云快照等，其成本相比于普通的云硬盘低很多，因此可以为业务带来显著的降本增效效果。
一些实施例中，在进行快照备份过程中，若发生接口或流程异常，Snapshot-controller(快照控制器)会通过Exponential Backoff(指数退避)方式进行重试，当快照资源不够或账户欠费时，可能会一直重试失败。当资源满足条件或接口恢复时，可以通过适当的方式重置Backoff计数器，快速让备份流程恢复正常。
磁盘打快照是一个相对耗时的过程，本实施例中，除了基于Block制作快照外，还可以通过基于XFS Reflink的方式实现快照，效率可以进一步提升。
本申请可以提供一种面向Kubernetes集群有状态服务的快速备份与恢复系统，能够实现数据库有状态服务整体实例及子资源的快速备份与恢复，让业务实例可以快速恢复并正常运行。另外，也支持跨NS的业务实例备份与恢复，在用户误删时会自动进行整体实例备份(具体可包括依赖的子资源)，保证业务的安全稳定。
由上可知，本实施例可以当接收到针对业务集群实例的实例恢复请求时，获取该业务集群实例中各个容器组的备份数据；针对其中每个容器组，根据该容器组的备份数据，创建该容器组对应的目标备份持久卷声明和目标备份持久卷对象，该目标备份持久卷声明用于声明该容器组所需的存储属性信息，该目标备份持久卷对象指向该容器组的备份数据的存储区域；针对其中每个容器组，根据该容器组对应的目标备份持久卷声明和目标备份持久卷对象，创建该容器组对应的目标持久卷声明和目标持久卷对象；根据容器组对应的目标持久卷声明和目标持久卷对象，运行该容器组，如此恢复对所述业务集群实例中各个容器组的运行。本申请通过上述方式，针对待恢复的业务集群实例中的每个容器组，创建对 应的目标备份持久卷声明和目标备份持久卷对象，并根据该目标备份持久卷声明和目标备份持久卷对象，创建对应的目标持久卷声明和目标持久卷对象；进而，根据所创建的目标持久卷声明和目标持久卷对象，运行该容器组，如此通过该方式恢复业务集群实例中各个容器组的运行，即实现对业务集群实例整体的恢复处理，提高了业务集群实例的恢复效率，有利于实现业务集群实例的快速恢复。
为了更好地实施以上方法，本申请实施例还提供一种业务集群实例的备份和恢复系统。该业务集群实例的备份和恢复系统包括业务集群实例的备份装置31和业务集群实例的恢复装置32。如图3a所示，业务集群实例的备份装置31可以包括确定单元3101、存储单元3102、第一创建单元3103、第一获取单元3104和备份单元3105；如图3b所示，业务集群实例的恢复装置32可以包括第二获取单元3201，第二创建单元3202，第三创建单元3203和运行单元3204，如下：
A.业务集群实例的备份装置31
(1)确定单元3101；
确定单元，用于确定待备份的业务集群实例，所述业务集群实例包括至少一个容器组。
(2)存储单元3102；
存储单元，用于针对每个所述容器组，设置所述容器组对应的源持久卷声明和源持久卷对象，并基于所述源持久卷对象对所述容器组进行存储，所述源持久卷声明用于声明所述容器组所需的存储属性信息，所述源持久卷对象指向所述容器组的数据存储区域。
可选的，在本申请的一些实施例中，所述存储单元可以包括设置子单元、集合获取子单元、建立子单元和存储子单元，如下：
所述设置子单元，用于针对每个所述容器组，设置所述容器组对应的源持久卷声明，所述源持久卷声明包括所述容器组所需的存储容量和文件系统类型；
建立子单元，用于从当前处于可用状态的持久卷对象集合中，选取与所述存储容量、所述文件系统类型匹配的持久卷对象，作为所述容器组对应的源持久卷对象；并建立选取的所述源持久卷对象与所述源持久卷声明之间的绑定关系；
存储子单元，用于根据所述源持久卷声明和所述绑定关系，将所述容器组的数据存储至所述源持久卷对象指向的数据存储区域。
(3)第一创建单元3103；
第一创建单元，用于当所述业务集群实例满足备份触发条件时，针对每个所述容器组，根据所述容器组对应的源持久卷声明和源持久卷对象，创建所述容器组对应的备份持久卷声明和备份持久卷对象。
可选的，在本申请的一些实施例中，所述第一创建单元具体可以用于当检测到所述业务集群实例被删除、且处于备份启动状态时，针对每个所述容器组，根据所述容器组对应的源持久卷声明和源持久卷对象，创建所述容器组对应的备份持久卷声明和备份持久卷对象。
可选的，在本申请的一些实施例中，所述第一创建单元具体可以用于当当前时间满足所述业务集群实例的备份触发时间条件时，针对每个所述容器组，根据所述容器组对应的 源持久卷声明和源持久卷对象，创建所述容器组对应的备份持久卷声明和备份持久卷对象。
(4)第一获取单元3104；
第一获取单元，用于针对每个所述容器组，基于所述容器组对应的源持久卷对象，获取所述容器组的待备份数据。
可选的，在本申请的一些实施例中，所述业务集群实例包括至少一个业务组件，所述业务组件包括至少一个容器组；
所述第一获取单元可以包括第一确定子单元、第二确定子单元、第三确定子单元和数据获取子单元，如下：
所述第一确定子单元，用于基于所述容器组对应的源持久卷对象中的实例地址信息，确定所述容器组所属的业务集群实例的实例数据存储区域；
第二确定子单元，用于基于所述容器组对应的源持久卷对象中的组件地址信息，从所述实例数据存储区域中确定所述容器组所属的业务组件的组件数据存储区域；
第三确定子单元，用于根据所述容器组对应的源持久卷对象中的容器组地址信息，从所述组件数据存储区域中确定所述容器组的数据存储区域；
数据获取子单元，用于从所述数据存储区域中获取所述容器组的待备份数据。
(5)备份单元3105；
备份单元，用于针对每个所述容器组，根据所述容器组对应的备份持久卷声明，将所述容器组的待备份数据备份至所述容器组对应的备份持久卷对象指向的存储区域。
可选的，在本申请的一些实施例中，所述备份单元可以包括第一绑定子单元和备份子单元，如下：
所述第一绑定子单元，用于针对每个所述容器组，建立所述容器组对应的备份持久卷声明和备份持久卷对象之间的绑定关系；
备份子单元，用于根据所述容器组对应的备份持久卷声明和所述绑定关系，将所述容器组的待备份数据备份至所述容器组对应的备份持久卷对象指向的存储区域。
可选的，在本申请的一些实施例中，所述第一绑定子单元具体可以用于针对每个所述容器组，获取所述容器组对应的备份持久卷对象的对象属性标识；将所述对象属性标识写入所述容器组对应的备份持久卷声明的配置信息中，以建立所述容器组对应的备份持久卷声明和备份持久卷对象之间的绑定关系。
可选的，在本申请的一些实施例中，所述业务集群实例的备份装置还可以包括依赖资源备份单元，如下：
所述依赖资源备份单元，用于对所述业务集群实例的资源引用关联关系进行分析，确定所述业务集群实例的依赖资源；对所述依赖资源进行备份处理。
B.业务集群实例的恢复装置32
(6)第二获取单元3201；
第二获取单元，用于当接收到针对业务集群实例的实例恢复请求时，获取所述业务集群实例中各个容器组的备份数据。
(7)第二创建单元3202；
第二创建单元，用于针对每个所述容器组，根据所述容器组的备份数据，创建所述容器组对应的目标备份持久卷声明和目标备份持久卷对象，所述目标备份持久卷声明用于声明所述容器组所需的存储属性信息，所述目标备份持久卷对象指向所述容器组的备份数据的存储区域。
可选的，在本申请的一些实施例中，所述容器组的备份数据处于第一存储区域，所述实例恢复请求指示在第二存储区域中恢复所述业务集群实例；
所述第二创建单元可以包括创建子单元和更新子单元，如下：
所述创建子单元，用于针对每个所述容器组，根据所述容器组的备份数据，创建处于所述第二存储区域中的初始备份持久卷对象和目标备份持久卷声明；
更新子单元，用于基于所述目标备份持久卷声明，对所述初始备份持久卷对象中的绑定声明信息进行更新，得到所述容器组对应的目标备份持久卷对象。
(8)第三创建单元3203；
第三创建单元，用于针对每个所述容器组，根据所述容器组对应的目标备份持久卷声明和目标备份持久卷对象，创建所述容器组对应的目标持久卷声明和目标持久卷对象。
(9)运行单元3204；
运行单元，用于根据所述容器组对应的目标持久卷声明和目标持久卷对象，运行所述容器组。
可选的，在本申请的一些实施例中，所述运行单元可以包括第二绑定子单元和运行子单元，如下：
所述第二绑定子单元，用于将所述容器组对应的目标持久卷声明和目标持久卷对象进行绑定；
运行子单元，用于当所述目标持久卷声明和所述目标持久卷对象互为绑定关系时，运行所述容器组。
可选的，在本申请的一些实施例中，所述第二绑定子单元具体可以用于获取所述容器组的目标持久卷对象的对象属性标识；将所述对象属性标识写入所述容器组对应的目标持久卷声明的配置信息中，以建立所述目标持久卷声明和所述目标持久卷对象之间的绑定关系。
可选的，在本申请的一些实施例中，所述运行单元可以包括依赖资源获取子单元和实例运行子单元，如下：
所述依赖资源获取子单元，用于获取所述业务集群实例的依赖资源对应的备份数据；
实例运行子单元，用于根据所述依赖资源对应的备份数据、所述容器组对应的目标持久卷声明和目标持久卷对象，运行所述容器组。
由上可知，本实施例可以由确定单元3101确定待备份的业务集群实例，该业务集群实例包括至少一个容器组；针对每个容器组，通过存储单元3102设置该容器组对应的源持久卷声明和源持久卷对象，并基于该源持久卷对象对该容器组进行存储，该源持久卷声明用于声明该容器组所需的存储属性信息，该源持久卷对象指向该容器组的数据存储区域；当该业务集群实例满足备份触发条件时，针对其中每个容器组，通过第一创建单元3103 根据该容器组对应的源持久卷声明和源持久卷对象，创建该容器组对应的备份持久卷声明和备份持久卷对象；由第一获取单元3104基于该源持久卷对象，获取该容器组的待备份数据；针对每个容器组，通过备份单元3105根据该容器组对应的备份持久卷声明，将该容器组的待备份数据备份至该容器组对应的备份持久卷对象指向的存储区域，以实现业务集群实例中每个容器组的数据备份；
或者，当接收到针对业务集群实例的实例恢复请求时，由第二获取单元3201获取业务集群实例中各个容器组的备份数据；针对每个容器组，通过第二创建单元3202根据该容器组的备份数据，创建该容器组对应的目标备份持久卷声明和目标备份持久卷对象，目标备份持久卷声明用于声明该容器组所需的存储属性信息，目标备份持久卷对象指向该容器组的备份数据的存储区域；通过第三创建单元3203根据该目标备份持久卷声明和该目标备份持久卷对象，创建该容器组对应的目标持久卷声明和目标持久卷对象；通过运行单元3204根据容器组对应的目标持久卷声明和目标持久卷对象，运行该容器组，以恢复对业务集群实例中各个容器组的运行。
本申请可以对业务集群实例整体进行备份和恢复处理，提高了业务集群实例的备份效率和恢复效率，有利于实现业务集群实例的快速备份与恢复。
本申请实施例还提供一种电子设备，如图4所示，其示出了本申请实施例所涉及的电子设备的结构示意图，该电子设备可以是终端或者服务器等，具体来讲：
该电子设备可以包括一个或者一个以上处理核心的处理器401、一个或一个以上计算机可读存储介质的存储器402、电源403和输入单元404等部件。本领域技术人员可以理解，图4中示出的电子设备结构并不构成对电子设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。其中：
处理器401是该电子设备的控制中心，利用各种接口和线路连接整个电子设备的各个部分，通过运行或执行存储在存储器402内的软件程序和/或模块，以及调用存储在存储器402内的数据，执行电子设备的各种功能和处理数据。可选的，处理器401可包括一个或多个处理核心；优选的，处理器401可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器401中。
存储器402可用于存储软件程序以及模块，处理器401通过运行存储在存储器402的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器402可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据电子设备的使用所创建的数据等。此外，存储器402可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。相应地，存储器402还可以包括存储器控制器，以提供处理器401对存储器402的访问。
电子设备还包括给各个部件供电的电源403，优选的，电源403可以通过电源管理系统与处理器401逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。电源403还可以包括一个或一个以上的直流或交流电源、再充电系统、电源故障检 测电路、电源转换器或者逆变器、电源状态指示器等任意组件。
该电子设备还可包括输入单元404，该输入单元404可用于接收输入的数字或字符信息，以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。
尽管未示出，该电子设备还可以包括显示单元等，在此不再赘述。具体在本实施例中，电子设备中的处理器401会按照如下的指令，将一个或一个以上的应用程序的进程对应的可执行文件加载到存储器402中，并由处理器401来运行存储在存储器402中的应用程序，从而实现各种功能，具体可以实现本申请实施例提供的业务集群实例的备份和恢复方法中的操作。
以上各个操作的具体实施可参见前面的实施例，在此不再赘述。
本领域普通技术人员可以理解，上述实施例的各种方法中的全部或部分步骤可以通过指令来完成，或通过指令控制相关的硬件来完成，该指令可以存储于一计算机可读存储介质中，并由处理器进行加载和执行。
为此，本申请实施例提供一种计算机可读存储介质，其中存储有多条指令，该指令能够被处理器进行加载，以执行本申请实施例所提供的任一种业务集群实例的备份和恢复方法中的步骤。
以上各个操作的具体实施可参见前面的实施例，在此不再赘述。
其中，该计算机可读存储介质可以包括：只读存储器(ROM，Read Only Memory)、随机存取记忆体(RAM，Random Access Memory)、磁盘或光盘等。
由于该计算机可读存储介质中所存储的指令，可以执行本申请实施例所提供的任一种业务集群实例的备份和恢复方法中的步骤，因此，可以实现本申请实施例所提供的任一种业务集群实例的备份和恢复方法所能实现的有益效果，详见前面的实施例，在此不再赘述。
根据本申请的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述业务集群实例的备份和恢复方面的各种可选实现方式中提供的方法。
以上对本申请实施例所提供的一种业务集群实例的备份和恢复方法以及相关设备进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (18)

  1. 一种业务集群实例的备份方法，由电子设备执行，包括：
    确定待备份的业务集群实例，所述业务集群实例包括至少一个容器组；
    针对每个所述容器组，设置所述容器组对应的源持久卷声明和源持久卷对象，并基于所述源持久卷对象对所述容器组进行存储，所述源持久卷声明用于声明所述容器组所需的存储属性信息，所述源持久卷对象指向所述容器组的数据存储区域；
    当所述业务集群实例满足备份触发条件时，针对每个所述容器组，根据所述容器组对应的源持久卷声明和源持久卷对象，创建所述容器组对应的备份持久卷声明和备份持久卷对象；
    针对每个所述容器组，基于所述容器组对应的源持久卷对象，获取所述容器组的待备份数据；
    针对每个所述容器组，根据所述容器组对应的备份持久卷声明，将所述容器组的待备份数据备份至所述容器组对应的备份持久卷对象指向的存储区域。
  2. 根据权利要求1所述的方法，所述针对每个所述容器组，根据所述容器组对应的备份持久卷声明，将所述容器组的待备份数据备份至所述容器组对应的备份持久卷对象指向的存储区域，包括：
    针对每个所述容器组，建立所述容器组对应的备份持久卷声明和备份持久卷对象之间的绑定关系；
    根据所述容器组对应的备份持久卷声明和所述绑定关系，将所述容器组的待备份数据备份至所述容器组对应的备份持久卷对象指向的存储区域。
  3. 根据权利要求2所述的方法，所述针对每个所述容器组，建立所述容器组对应的备份持久卷声明和备份持久卷对象之间的绑定关系，包括：
    针对每个所述容器组，获取所述容器组对应的备份持久卷对象的对象属性标识；将所述对象属性标识写入所述容器组对应的备份持久卷声明的配置信息中，以建立所述容器组对应的备份持久卷声明和备份持久卷对象之间的绑定关系。
  4. 根据权利要求1至3任一项所述的方法，所述针对每个所述容器组，设置所述容器组对应的源持久卷声明和源持久卷对象，并基于所述源持久卷对象对所述容器组进行存储，包括：
    针对每个所述容器组，设置所述容器组对应的源持久卷声明，所述源持久卷声明包括所述容器组所需的存储容量和文件系统类型；
    从当前处于可用状态的持久卷对象集合中，选取与所述存储容量、所述文件系统类型匹配的持久卷对象，并建立选取的所述源持久卷对象与所述源持久卷声明之间的绑定关系；
    根据所述源持久卷声明和所述绑定关系，将所述容器组的数据存储至所述源持久卷对象指向的数据存储区域。
  5. 根据权利要求1至4任一项所述的方法，所述业务集群实例包括至少一个业务组件，所述业务组件包括至少一个容器组；
    所述基于所述容器组对应的源持久卷对象，获取所述容器组的待备份数据，包括：
    基于所述容器组对应的源持久卷对象中的实例地址信息，确定所述容器组所属的业务集群实例的实例数据存储区域；
    基于所述容器组对应的源持久卷对象中的组件地址信息，从所述实例数据存储区域中确定所述容器组所属的业务组件的组件数据存储区域；
    根据所述容器组对应的源持久卷对象中的容器组地址信息，从所述组件数据存储区域中确定所述容器组的数据存储区域；
    从所述数据存储区域中获取所述容器组的待备份数据。
  6. 根据权利要求1至5任一项所述的方法，所述方法还包括：
    对所述业务集群实例的资源引用关联关系进行分析，确定所述业务集群实例的依赖资源；
    对所述依赖资源进行备份处理。
  7. 根据权利要求1至6任一项所述的方法，所述当所述业务集群实例满足备份触发条件时，针对每个所述容器组，根据所述容器组对应的源持久卷声明和源持久卷对象，创建所述容器组对应的备份持久卷声明和备份持久卷对象，包括：
    当检测到所述业务集群实例被删除、且处于备份启动状态时，针对每个所述容器组，根据所述容器组对应的源持久卷声明和源持久卷对象，创建所述容器组对应的备份持久卷声明和备份持久卷对象。
  8. 根据权利要求1至6任一项所述的方法，所述当所述业务集群实例满足备份触发条件时，针对每个所述容器组，根据所述容器组对应的源持久卷声明和源持久卷对象，创建所述容器组对应的备份持久卷声明和备份持久卷对象，包括：
    当当前时间满足所述业务集群实例的备份触发时间条件时，针对每个所述容器组，根据所述容器组对应的源持久卷声明和源持久卷对象，创建所述容器组对应的备份持久卷声明和备份持久卷对象。
  9. 一种业务集群实例的恢复方法，由电子设备执行，包括：
    当接收到针对业务集群实例的实例恢复请求时，获取所述业务集群实例中各个容器组的备份数据；
    针对每个所述容器组，根据所述容器组的备份数据，创建所述容器组对应的目标备份持久卷声明和目标备份持久卷对象，所述目标备份持久卷声明用于声明所述容器组所需的存储属性信息，所述目标备份持久卷对象指向所述容器组的备份数据的存储区域；
    针对每个所述容器组，根据所述容器组对应的目标备份持久卷声明和目标备份持久卷对象，创建所述容器组对应的目标持久卷声明和目标持久卷对象；
    根据所述容器组对应的目标持久卷声明和目标持久卷对象，运行所述容器组。
  10. 根据权利要求9所述的方法，所述根据所述容器组对应的目标持久卷声明和目标持久卷对象，运行所述容器组，包括：
    将所述容器组对应的目标持久卷声明和目标持久卷对象进行绑定；
    当所述目标持久卷声明和所述目标持久卷对象互为绑定关系时，运行所述容器组。
  11. 根据权利要求10所述的方法，所述将所述容器组对应的目标持久卷声明和目标 持久卷对象进行绑定，包括：
    获取所述容器组的目标持久卷对象的对象属性标识；
    将所述对象属性标识写入所述容器组对应的目标持久卷声明的配置信息中，以建立所述目标持久卷声明和所述目标持久卷对象之间的绑定关系。
  12. 根据权利要求9至11任一项所述的方法，所述容器组的备份数据处于第一存储区域，所述实例恢复请求指示在第二存储区域中恢复所述业务集群实例；
    所述针对每个所述容器组，根据所述容器组的备份数据，创建所述容器组对应的目标备份持久卷声明和目标备份持久卷对象，包括：
    针对每个所述容器组，根据所述容器组的备份数据，创建处于所述第二存储区域中的初始备份持久卷对象和目标备份持久卷声明；
    基于所述目标备份持久卷声明，对所述初始备份持久卷对象中的绑定声明信息进行更新，得到所述容器组对应的目标备份持久卷对象。
  13. 根据权利要求9至12任一项所述的方法，所述根据所述容器组对应的目标持久卷声明和目标持久卷对象，运行所述容器组，包括：
    获取所述业务集群实例的依赖资源对应的备份数据；
    根据所述依赖资源对应的备份数据、所述容器组对应的目标持久卷声明和目标持久卷对象，运行所述容器组。
  14. 一种业务集群实例的备份装置，包括：
    确定单元，用于确定待备份的业务集群实例，所述业务集群实例包括至少一个容器组；
    存储单元，用于针对每个所述容器组，设置所述容器组对应的源持久卷声明和源持久卷对象，并基于所述源持久卷对象对所述容器组进行存储，所述源持久卷声明用于声明所述容器组所需的存储属性信息，所述源持久卷对象指向所述容器组的数据存储区域；
    第一创建单元，用于当所述业务集群实例满足备份触发条件时，针对每个所述容器组，根据所述容器组对应的源持久卷声明和源持久卷对象，创建所述容器组对应的备份持久卷声明和备份持久卷对象；
    第一获取单元，用于针对每个所述容器组，基于所述容器组对应的源持久卷对象，获取所述容器组的待备份数据；
    备份单元，用于针对每个所述容器组，根据所述容器组对应的备份持久卷声明，将所述容器组的待备份数据备份至所述容器组对应的备份持久卷对象指向的存储区域。
  15. 一种业务集群实例的恢复装置，包括：
    第二获取单元，用于当接收到针对业务集群实例的实例恢复请求时，获取所述业务集群实例中各个容器组的备份数据；
    第二创建单元，用于针对每个所述容器组，根据所述容器组的备份数据，创建所述容器组对应的目标备份持久卷声明和目标备份持久卷对象，所述目标备份持久卷声明用于声明所述容器组所需的存储属性信息，所述目标备份持久卷对象指向所述容器组的备份数据的存储区域；
    第三创建单元，用于针对每个所述容器组，根据所述容器组对应的目标备份持久卷声 明和目标备份持久卷对象，创建所述容器组对应的目标持久卷声明和目标持久卷对象；
    运行单元，用于根据所述容器组对应的目标持久卷声明和目标持久卷对象，运行所述容器组。
  16. 一种电子设备，包括存储器和处理器；所述存储器存储有应用程序，所述处理器用于运行所述存储器内的应用程序，以执行权利要求1至8任一项所述的业务集群实例的备份方法或权利要求9至13任一项所述的业务集群实例的恢复方法中的步骤。
  17. 一种计算机可读存储介质，所述计算机可读存储介质存储有多条指令，所述指令适于处理器进行加载，以执行权利要求1至8任一项所述的业务集群实例的备份方法或权利要求9至13任一项所述的业务集群实例的恢复方法中的步骤。
  18. 一种计算机程序产品，包括计算机程序或指令，该计算机程序或指令被处理器执行时实现权利要求1至8任一项所述的业务集群实例的备份方法或权利要求9至13任一项所述的业务集群实例的恢复方法中的步骤。
PCT/CN2023/117413 2022-10-12 2023-09-07 业务集群实例的备份和恢复方法以及相关设备 WO2024078211A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US18/588,833 US20240202077A1 (en) 2022-10-12 2024-02-27 Service cluster instance backup and recovery methods and related devices

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202211247839.6A CN117909020A (zh) 2022-10-12 2022-10-12 业务集群实例的备份和恢复方法以及相关设备
CN202211247839.6 2022-10-12

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/588,833 Continuation US20240202077A1 (en) 2022-10-12 2024-02-27 Service cluster instance backup and recovery methods and related devices

Publications (1)

Publication Number Publication Date
WO2024078211A1 true WO2024078211A1 (zh) 2024-04-18

Family

ID=90668784

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/117413 WO2024078211A1 (zh) 2022-10-12 2023-09-07 业务集群实例的备份和恢复方法以及相关设备

Country Status (3)

Country Link
US (1) US20240202077A1 (zh)
CN (1) CN117909020A (zh)
WO (1) WO2024078211A1 (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111338854A (zh) * 2020-05-25 2020-06-26 南京云信达科技有限公司 基于Kubernetes集群快速恢复数据的方法及系统
US20210200814A1 (en) * 2019-12-30 2021-07-01 Servicenow, Inc. Discovery of containerized platform and orchestration services
CN113296871A (zh) * 2020-04-10 2021-08-24 阿里巴巴集团控股有限公司 容器组实例的处理方法、设备及系统
CN113946276A (zh) * 2020-07-16 2022-01-18 北京达佳互联信息技术有限公司 集群中的磁盘管理方法、装置及服务器

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210200814A1 (en) * 2019-12-30 2021-07-01 Servicenow, Inc. Discovery of containerized platform and orchestration services
CN113296871A (zh) * 2020-04-10 2021-08-24 阿里巴巴集团控股有限公司 容器组实例的处理方法、设备及系统
CN111338854A (zh) * 2020-05-25 2020-06-26 南京云信达科技有限公司 基于Kubernetes集群快速恢复数据的方法及系统
CN113946276A (zh) * 2020-07-16 2022-01-18 北京达佳互联信息技术有限公司 集群中的磁盘管理方法、装置及服务器

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ZHITIAN: "Getting Started from Scratch, K8s | Application Storage and Persistent Data Volumes: Storage Snapshots and Topology Scheduling", DEVELOPER COMMUNITY, 10 October 2019 (2019-10-10), XP093158025, Retrieved from the Internet <URL:https://developer.aliyun.com/article/720355> *

Also Published As

Publication number Publication date
CN117909020A (zh) 2024-04-19
US20240202077A1 (en) 2024-06-20

Similar Documents

Publication Publication Date Title
US11199971B2 (en) Managing operational parameters for migrating data for resized volumes
US20130085990A1 (en) Replica placement strategy for distributed data persistence
US10852996B2 (en) System and method for provisioning slave storage including copying a master reference to slave storage and updating a slave reference
CN104301360A (zh) 一种日志数据记录的方法、日志服务器及系统
WO2013132377A1 (en) Managing tenant-specific data sets in a multi-tenant environment
JP2013545162A5 (zh)
US20190188309A1 (en) Tracking changes in mirrored databases
US20220121523A1 (en) Identifying database backup copy chaining
KR101551706B1 (ko) 고가용성 가상머신 구성 시스템 및 방법, 이를 기록한 기록매체
US10452680B1 (en) Catch-up replication with log peer
CN104462185A (zh) 一种基于混合结构的数字图书馆云存储系统
CN105912424A (zh) 一种基于云架构的终端程序快速备份及恢复方法
CN111684437B (zh) 按时间顺序排序的错位更新键-值存储系统
US12032847B2 (en) Cross-platform replication of logical units
US9207966B2 (en) Method and system for providing a high-availability application
US9798483B2 (en) Object storage power consumption optimization
US10587685B2 (en) Cross-platform replication of logical units
CN109032753A (zh) 一种异构虚拟机硬盘托管方法、系统、存储介质及Nova平台
US11341159B2 (en) In-stream data load in a replication environment
CN112783436A (zh) 用于信息生命周期管理的同步对象放置
WO2024078211A1 (zh) 业务集群实例的备份和恢复方法以及相关设备
CN109766220A (zh) 应用系统的备份恢复方法、装置及计算机可读存储介质
CN114816272A (zh) Kubernetes环境下的磁盘管理系统
CN111694908B (zh) 数据存储方法、装置及存储介质
US10938919B1 (en) Registering client devices with backup servers using domain name service records

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23876416

Country of ref document: EP

Kind code of ref document: A1