# US 11,030,052 B2 · Data protection using checkpoint restart for cluster shared resources > Agents: this data is available as JSON from the patentgrep API and MCP server — see https://patentgrep.com/llms.txt - Number: US 11,030,052 B2 - Document ID: US11030052B2 - Status: Granted - Kind: B2 - Application number: 16/123,997 - Filed: 2018-09-06 - Published: 2019-01-03 - Granted: 2021-06-08 - Earliest claimed: 2015-06-26 - Assignees: EMC IP Holding Company LLC - Applicants: EMC IP Holding Company LLC - Inventors: Ajith Gopinath; Sathyamoorthy Viswanathan; Kishore Kumar - Web page: https://patentgrep.com/patent/US11030052B2 ## CPC - G06F 11/1451: {by selection of backup contents} - G06F 11/203: {using migration} - G06F 11/1464: {for networked environments} - G06F 11/2035: {without idle spare hardware} - G06F 11/2046: {where the redundant components share persistent storage (G06F11/2043 takes precedence)} - G06F 2201/84: Using snapshots, i.e. a logical point-in-time copy of the data - G06F: ELECTRIC DIGITAL DATA PROCESSING (computer systems based on specific computational models G06N) ## Abstract Techniques to back up a cluster resource are disclosed. In various embodiments, an active cluster node is used to take and store persistently on a cluster shared volume a snapshot of the cluster shared volume. The persistent snapshot is used to back up the cluster shared volume, including by storing checkpoint information indicating as the backup progresses which portions of the snapshot have been backed up. A cluster environment with which the cluster shared volume is associated is monitored to detect any failover or failback affecting the backup. ## Claims ### Claim 1 A method of backing up a cluster resource, comprising: determining, by one or more processors, that backup of a cluster shared volume is to be performed; and in response to determining that the backup of the cluster shared volume is to be performed: causing, by the one or more processors, an active cluster node to take and store persistently on the cluster shared volume a persistent snapshot of the cluster shared volume; using, by the one or more processors, the persistent snapshot to back up the cluster shared volume to a backup storage node connected to the active cluster node via a network, including by storing checkpoint information indicating as the backup progresses which portions of the persistent snapshot have been backed up, wherein using the active cluster node to take and store persistently on the cluster shared volume the persistent snapshot of the cluster shared volume includes invoking a virtual shadow copy service (VSS) in a manner that results in the persistent snapshot being store persistently on the cluster shared volume; and in response to a determination that a failure is detected, restarting a backup of the cluster shared volume based at least in part on the checkpoint information. ### Claim 2 (depends on 1) The method of claim 1, further comprising detecting the failure. ### Claim 3 (depends on 2) The method of claim 2, further comprising determining that a cluster service with which the backup is associated has become available after the failure. ### Claim 4 (depends on 3) The method of claim 3, wherein restarting the backup of the cluster shared volume based at least in part on the checkpoint information comprises: using a most recently stored checkpoint information to resume the backup starting at a point determined based at least in part on the most recently stored checkpoint information. ### Claim 5 (depends on 2) The method of claim 2, wherein the failure is a failover or a failback. ### Claim 6 (depends on 1) The method of claim 1, wherein using the active cluster node to take and store persistently on the cluster shared volume the persistent snapshot of the cluster shared volume includes invoking a virtual shadow copy service (VSS) in a manner that results in the persistent snapshot being store persistently on the cluster shared volume. ### Claim 7 (depends on 1) The method of claim 1, further comprising: monitoring, by the one or more processors, a cluster environment with which the cluster shared volume is associated to detect an occurrence of a failure affecting the backup, wherein monitoring the cluster environment with which the cluster shared volume is associated to detect the failure affecting the backup includes using an application programming interface (API) associated with the cluster environment to poll the cluster environment periodically to determine whether the failure has occurred. ### Claim 8 (depends on 1) The method of claim 1, further comprising restarting the backup from a beginning a backup snapshot in response to a determination that the failure occurs and a cluster service with which the backup is associated does not become available again within a prescribed timeout period. ### Claim 9 (depends on 1) The method of claim 1, further comprising completing the backup and deleting the persistent snapshot. ### Claim 10 (depends on 1) The method of claim 1, wherein the restarting the backup of the cluster shared volume based at least in part on the checkpoint information comprises determining portions of the cluster shared volume to backup based on the checkpoint information. ### Claim 11 (depends on 1) The method of claim 1, further comprising: determining that backup of the cluster shared volume is complete; and in response to a determination that the backup of the cluster shared volume is complete, deleting the persistent snapshot of the cluster shared volume from the cluster shared volume. ### Claim 12 (depends on 1) The method of claim 1, further comprising: monitoring, by the one or more processors, a cluster environment with which the cluster shared volume is associated to detect an occurrence of a failure affecting the backup, wherein the monitoring to detect the occurrence of a failure affecting the backup comprises determining whether a backup of the persistent snapshot to the cluster shared volume is interrupted. ### Claim 13 (depends on 1) The method of claim 1, wherein the persistent snapshot corresponds to a persistent virtual shadow copy service (VSS) shadow copy of the cluster shared volume. ### Claim 14 (depends on 1) The method of claim 1, wherein the persistent snapshot is retained until back up of the cluster shared volume is completed. ### Claim 15 (depends on 1) The method of claim 1, further comprising: receiving an indication to backup the cluster resource, wherein the determining that the backup of the cluster shared volume is to be performed is based at least in part on the receiving the indication to backup the cluster resource. ### Claim 16 (depends on 1) The method of claim 1, wherein the persistently storing the persistent snapshot of the cluster shared volume comprises storing the persistent snapshot of the cluster shared volume on the cluster shared volume. ### Claim 17 (depends on 1) The method of claim 1, wherein the persistent snapshot of the cluster shared volume is made available to a cluster node for which the failure occurred. ### Claim 18 (depends on 1) The method of claim 1, wherein the checkpoint information is stored at a predefined granularity. ### Claim 19 (depends on 1) The method of claim 1, wherein the persistent snapshot is stored on the same cluster shared volume to which the persistent snapshot corresponds. ### Claim 20 (depends on 1) The method of claim 1, wherein persistent snapshot is deleted in response to a determination that the backup of the cluster shared volume to which the persistent snapshot corresponds is completed. ### Claim 21 A system to back up a cluster resource, comprising: a communication interface; and a processor coupled to the communication interface and configured to: determine that backup of a cluster shared volume is to be performed; and in response to determining that the backup of the cluster shared volume is to be performed: cause an active cluster node to take and store persistently on the cluster shared volume a persistent snapshot of the cluster shared volume; use the persistent snapshot to back up the cluster shared volume to a backup storage node connected to the active cluster node via a network, including by storing checkpoint information indicating as the backup progresses which portions of the persistent snapshot have been backed up, wherein using the active cluster node to take and store persistently on the cluster shared volume the persistent snapshot of the cluster shared volume includes invoking a virtual shadow copy service (VSS) in a manner that results in the persistent snapshot being store persistently on the cluster shared volume; and in response to a determination that a failure is detected, restarting a backup of the cluster shared volume based at least in part on the checkpoint information. ### Claim 22 A computer program product to back up a cluster resource, the computer program product being embodied in a non-transitory computer readable medium and comprising computer instructions for: determining, by one or more processors, that backup of a cluster shared volume is to be performed; and in response to determining that the backup of the cluster shared volume is to be performed: cause an active duster node to take and store persistently on the duster shared volume a persistent snapshot of the duster shared volume; using the persistent snapshot to back up the cluster shared volume to a backup storage node connected to the active cluster node via a network, including by storing checkpoint information indicating as the backup progresses which portions of the persistent snapshot have been backed up, wherein using the active duster node to take and store persistently on the cluster shared volume the persistent snapshot of the cluster shared volume includes invoking a virtual shadow copy service (VSS) in a manner that results in the persistent snapshot being store persistently on the cluster shared volume; and in response to a determination that a failure is detected, restarting a backup of the cluster shared volume based at least in part on the checkpoint information.