Synchronization of sequential access storage components with backup catalog

• US 9,454,591 B2
• Filed: 02/27/2013
• Issued: 09/27/2016
• Est. Priority Date: 05/26/2010
• Status: Active Grant

• Current Assignee: International Business Machines Corporation
• Original Assignee: International Business Machines Corporation
• Inventors: Akirav, Shay H., Budilovsky, Evgeny, Drobchenko, Elena, Lazar, Aharon, Leneman, Ofer, Maoz, Itay, Paz, Gil E.
• Primary Examiner(s): Wong, Leslie
• Application Number:
  US13/778,460
• Publication Number:
  US 20140074781A1
• Time in Patent Office: 1,308 Days
• Field of Search: 707/613, 707/610, 707/614, 707/623, 707/764, 707/676
• US Class Current: 1/1
• CPC Class Codes: G06F 11/1458 Management of the backup or restore process
• CPC Class Codes: G06F 11/2094 Redundant storage or storage space G06F11/2056 takes precedence
• CPC Class Codes: G06F 16/273 Asynchronous replication or reconciliation
• CPC Class Codes: G06F 2201/82 Solving problems relating to consistency ensuring consistency in mirrored systems G06F11/2064

Abstract

Subsequent to a storage operation performed on the source instance by a source component, a synchronization message is sent to a replicated component for the replicated instance. The synchronization message is stored locally in a persistent storage location associated with the source component along with an indicator representative of a time the storage operation was performed. Pursuant to receipt of the synchronization message by the replicated component, the replicated component is updated to a dirty state to indicate a lack of full synchronization between the source and replicated instances.

Claims

1. A method for synchronization of source and replicated instances of sequential access storage components with a backup catalog in a computing environment by a processor device, comprising:

subsequent to a storage operation performed on the source instance by a source component, sending a synchronization message to a replicated component for the replicated instance, wherein the synchronization message is stored locally in a persistent storage location associated with the source component along with an indicator representative of a time the storage operation was performed;

pursuant to receipt of the synchronization message by the replicated component, updating the replicated component to a dirty state to indicate a lack of full synchronization between the source and replicated instances;

acknowledging receipt of the synchronization message by the replicated component to the source component by sending a dirty state acknowledgement;

wherein if the replicated component has previously sent the dirty state acknowledgment, withholding sending an additional synchronization message; and

if, during a subsequent recovery process, the dirty state is not yet cleared, the replicated component is deemed ineligible for participation in a full restoration operation.

2. The method of claim 1, further including creating the synchronization message on the source component.

3. The method of claim 1, further including, subsequent to a completion of a replication operation, clearing the dirty state of the replicated component.

4. The method of claim 1, further including, subsequent to receipt of the synchronization message, storing the synchronization message in a persistent storage location associated with the replicated component.

5. The method of claim 1, further including querying the replicated component for a status of the dirty state using a request handler according to a predefined schedule.

6. The method of claim 5, further including, if at least one of querying the replicated component for the status of the dirty state and updating the replicated component to the dirty state fails, maintaining the at least one of the query and the update for subsequent retry by the source component.

7. The method of claim 6, further including retrying the one of the query and the update according to a user-defined timeframe, wherein:

if the timeframe expires, the one of the query and the update is discarded and an alert is sent to the user, and

if retrying the one of the query and the update is successful, the one of the query and the update is deleted from the source component.

8. A system for synchronization of source and replicated instances of sequential access storage components with a backup catalog in a computing environment, comprising:

at least one processor device operable in the computing environment, the at least one processor in communication with a source component and a replicated component, wherein the at least one processor device;

subsequent to a storage operation performed on the source instance by the source component, sends a synchronization message to the replicated component for the replicated instance, wherein the synchronization message is stored locally in a persistent storage location associated with the source component along with an indicator representative of a time the storage operation was performed;

pursuant to receipt of the synchronization message by the replicated component, updates the replicated component to a dirty state to indicate a lack of full synchronization between the source and replicated instances;

acknowledges receipt of the synchronization message by the replicated component to the source component by sending a dirty state acknowledgement;

wherein if the replicated component has previously sent the dirty state acknowledgment, withholds sending an additional synchronization message; and

if, during a subsequent recovery process, the dirty state is not yet cleared, deems the replicated component ineligible for participation in a full restoration operation.

9. The system of claim 8, wherein the at least one processor device creates the synchronization message on the source component.

10. The system of claim 8, wherein the at least one processor device, subsequent to a completion of a replication operation, clears the dirty state of the replicated component.

11. The system of claim 8, wherein the at least one processor device, subsequent to receipt of the synchronization message, stores the synchronization message in a persistent storage location associated with the replicated component.

12. The system of claim 8, wherein the at least one processor device queries the replicated component for a status of the dirty state using a request handler according to a predefined schedule.

13. The system of claim 12, wherein the at least one processor device, if at least one of querying the replicated component for the status of the dirty state and updating the replicated component to the dirty state fails, maintains the at least one of the query and the update for subsequent retry by the source component.

14. The system of claim 13, wherein the at least one processor device retries the one of the query and the update according to a user-defined timeframe, wherein:

if the timeframe expires, the one of the query and the update is discarded and an alert is sent to the user, and

if retrying the one of the query and the update is successful, the one of the query and the update is deleted from the source component.

15. A computer program product for synchronization of source and replicated instances of sequential access storage components with a backup catalog in a computing environment by a processor device, the computer program product comprising a computer-readable storage medium having computer-readable program code portions stored therein, the computer-readable program code portions comprising:

a first executable portion that, subsequent to a storage operation performed on the source instance by a source component, sends a synchronization message to a replicated component for the replicated instance, wherein the synchronization message is stored locally in a persistent storage location associated with the source component along with an indicator representative of a time the storage operation was performed;

a second executable portion that, pursuant to receipt of the synchronization message by the replicated component, updates the replicated component to a dirty state to indicate a lack of full synchronization between the source and replicated instances;

a third executable portion that acknowledges receipt of the synchronization message by the replicated component to the source component by sending a dirty state acknowledgement;

wherein if the replicated component has previously sent the dirty state acknowledgment, withholds sending an additional synchronization message; and

a fourth executable portion that if, during a subsequent recovery process, the dirty state is not yet cleared, deems the replicated component ineligible for participation in a full restoration operation.

16. The computer program product of claim 15, further including a fifth executable portion that creates the synchronization message on the source component.

17. The computer program product of claim 15, further including a fifth executable portion that, subsequent to a completion of a replication operation, clears the dirty state of the replicated component.

18. The computer program product of claim 15, further including a fifth executable portion that, subsequent to receipt of the synchronization message, stores the synchronization message in a persistent storage location associated with the replicated component.

19. The computer program product of claim 15, further including a fifth executable portion that queries the replicated component for a status of the dirty state using a request handler according to a predefined schedule.

20. The computer program product of claim 19, further including a sixth executable portion that, if at least one of querying the replicated component for the status of the dirty state and updating the replicated component to the dirty state fails, maintains the at least one of the query and the update for subsequent retry by the source component.

21. The computer program product of claim 20, further including a seventh executable portion that retries the one of the query and the update according to a user-defined timeframe, wherein:

if the timeframe expires, the one of the query and the update is discarded and an alert is sent to the user, and

if retrying the one of the query and the update is successful, the one of the query and the update is deleted from the source component.