Optimized lock detection in a change block tracker

Patent metadata

Field	Value
Publication number	US-10078641-B1
Application number	US-201514985211-A
Country	US
Kind code	B1
Filing date	Dec 30, 2015
Priority date	Dec 30, 2015
Publication date	Sep 18, 2018
Grant date	Sep 18, 2018

Abstract

A method for optimizing lock detection in a change block tracker (CBT). A volume subject to the backup constantly receives writes. Therefore, it is important to divide writes that occurred before the lock and the write that occurred after the lock. The CBT is installed into kernel at the installation of the backup agent (application). The detection of changes is started at the completion of a previous snapshot. Snapshot creation request (SCR) is generated. Lock request is received by the CBT. Once the lock request is intercepted, the current changes are moved to frozen changes. The CBT processes the SCR and creates a collection of changes—i.e., snapshot with a Name. The CBT moves the current changes to the snapshot Name.

First claim

What is claimed is:

1. A method for optimization of lock detection in a change block tracker (CBT), the method comprising:
starting, by a hardware processor, change tracking using a CBT launched on a kernel of a computer system;
intercepting, by the hardware processor, a first lock request and moving current changes to frozen changes;
moving, by the hardware processor, upon intercepting subsequent lock requests, changes occurring after a previous lock request to a snapshot having a name, and to the frozen changes;
receiving, at the hardware processor, a freeze command from a backup client, wherein the freeze command indicates a name of the snapshot; and
processing, by the hardware processor, changes to the snapshot in chronological order by;
moving, by the hardware processor, a current snapshot to the frozen changes, if the name of the current snapshot is not the same as the name of the snapshot indicated by the freeze command, otherwise:
moving, by the hardware processor, the current snapshot to the frozen changes and copying the previous snapshot to the current changes, and moving subsequent snapshots to the current changes.

2. The method of claim 1 , wherein the snapshot is a read-only snapshot.

3. A method for optimization of lock detection in a change block tracker (CBT), the method comprising:
in response to a snapshot creation request, generating, by a hardware processor, a first collection comprising changes to a volume of a computer system, the volume subject to change tracking and a second collection comprising changes to a snapshot that both correspond to a first snapshot name;
intercepting, by a hardware processor, a first lock request and moving current changes to frozen changes;
moving changes occurring after the first lock request to the first collection comprising volume changes, after a next lock request;
saving, by a hardware processor, changes to the second collection comprising snapshot changes, upon receiving a snapshot modification request;
moving, by the hardware processor, changes occurring after the next snapshot creation request to the second collection comprising snapshot changes and to the frozen changes upon receiving a next lock request;
moving, by the hardware processor, changes occurring after the next lock request to a third collection comprising volume changes associated with a current snapshot name, upon subsequent lock requests;
saving, by the hardware processor, changes to a fourth collection comprising snapshot changes associated with the current snapshot name, upon a subsequent snapshot modification request; and
processing, by the hardware processor, snapshot changes in a chronological order upon reception of a freeze command accompanied with a snapshot name the processing comprising:
if the current snapshot name is not the same as the snapshot name indicated by the freeze command, moving the volume changes corresponding to the current snapshot name to the frozen changes and deleting any changes to the fourth collection, otherwise:
moving the volume changes corresponding to the current snapshot name to the frozen changes, and copying changes to the third collection to the current changes, and moving changes to the fourth collection to the frozen changes and copying the changes to the fourth collection to the current changes.

4. The method of claim 3 , wherein the collections comprise writable snapshot.

5. The method of claim 3 , wherein the frozen changes are deleted after a backup is successfully created.

6. The method of claim 3 , wherein the frozen changes are merged with current changes collection in case of a failed backup, and reverted changes are used on a next backup.

7. The method of claim 1 , further comprising:
making the frozen changes available to the backup client.

8. The method of claim 1 , further comprising: prior to intercepting the first lock request, generating, by the hardware processor, the snapshot having the name upon reception of a snapshot creation requests.

9. The method of claim 3 , further comprising:
prior to generating the first collection:
launching a CBT on a kernel of the computer system.

10. The method of claim 9 , further comprising, prior to generating the first collection and after launching the CBT:
starting change tracking by the CBT on the volume.

11. The method of claim 3 , wherein the freeze command is received from a backup client.

12. The method of claim 3 comprising:
creating, by the hardware processor, the third collection comprising volume changes and a fourth collection comprising snapshot changes, both collections associated with a current snapshot name, upon receiving a next snapshot creation request after receiving the snapshot modification request.

13. The method of claim 3 , further comprising:
moving subsequent volume changes to the current changes and deleting the subsequent snapshot changes; and
making the frozen changes available to read for the backup client.

14. A method for optimization of lock detection in a change block tracker (CBT), the method comprising:
intercepting, by a hardware processor, a first lock request and moving current changes to frozen changes, wherein change tracking is started on a volume of a computer;
moving, by the hardware processor, upon intercepting subsequent lock requests, changes occurring after a previous lock request to a snapshot on the volume associated with a first snapshot name, and moving the changes to the frozen changes;
receiving, at the hardware processor, a freeze command from a backup client, wherein the freeze command indicates a second snapshot name; and
moving, by the hardware processor, a current snapshot to the frozen changes, when the first snapshot name is not the same as the second snapshot name, otherwise:
moving, by the hardware processor, the current snapshot to the frozen changes and copying the previous snapshot to the current changes, and moving subsequent snapshots to the current changes.

15. The method of claim 14 , further comprising, prior to intercepting the first lock request: generating, by the hardware processor, the snapshot on the volume upon reception of a snapshot creation request.

16. The method of claim 14 , further comprising:
making the frozen changes available to the backup client after the moving the current snapshot to the frozen changes.

17. A system for optimization of lock detection in a change block tracker (CBT), the method comprising:
a hardware processor configured to:
intercept a first lock request and moving current changes to frozen changes, wherein change tracking is started on a volume of a computer;
move upon intercepting subsequent lock requests, changes occurring after a previous lock request to a snapshot on the volume associated with a first snapshot name, and moving the changes to the frozen changes;
receive a freeze command from a backup client, wherein the freeze command indicates a second snapshot name; and
move a current snapshot to the frozen changes, when the first snapshot name is not the same as the second snapshot name, otherwise:
move the current snapshot to the frozen changes and copying the previous snapshot to the current changes, and moving subsequent snapshots to the current changes.

18. The system of claim 17 , wherein the snapshot is a read-only snapshot.

19. The system of claim 17 , wherein the hardware processor is further configured to, prior to intercepting the first lock request: generate, by the hardware processor, the snapshot on the volume upon reception of a snapshot

Assignees

• Acronis Int Gbmh
• Acronis Int Gmbh

Inventors

• Redko Andrey
• Protassov Stanislav S
• Beloussov Serguei M
• Shmulevich Mark

Classifications

• G06F11/1448

  Management of the data involved in backup or backup restore · CPC title

• G06F17/30088 Primary

  Physics · mapped topic

• G06F2201/825

  the problem or solution involving locking · CPC title

• G06F11/3041

  where the computing system component is an input/output interface (interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units G06F13/00) · CPC title

• G06F16/128 Primary

  Details of file system snapshots on the file-level, e.g. snapshot creation, administration, deletion (error detection or correction of the data by redundancy in operations or in hardware G06F11/14, G06F11/16) · CPC title