Methods and apparatus for multi-phase multi-source backup

• US 9,465,696 B2
• Filed: 09/06/2011
• Issued: 10/11/2016
• Est. Priority Date: 06/03/2011
• Status: Expired due to Fees

• Current Assignee: Apple Inc.
• Original Assignee: Apple Inc.
• Inventors: McNeil, Kenneth B., Freedman, Gordon J., Krugler, Eric
• Primary Examiner(s): Uddin, Md. I
• Application Number:
  US13/226,409
• Publication Number:
  US 20120310889A1
• Time in Patent Office: 1,862 Days
• Field of Search: 707/640, 707/641, 707/646, 707/652, 707/639
• US Class Current: 1/1
• CPC Class Codes: G06F 11/1451 by selection of backup contents
• CPC Class Codes: G06F 11/1458 Management of the backup or restore process
• CPC Class Codes: G06F 11/1461 Backup scheduling policy
• CPC Class Codes: G06F 11/1464 for networked environments
• CPC Class Codes: G06F 11/1469 Backup restoration techniques
• CPC Class Codes: H04L 67/5683 Storage of data provided by user terminals, i.e. reverse caching

Abstract

Methods and apparatus that identify a change of resources in a device to a first backup source are described. In response to receiving a token from the first backup source for authorization to a second backup source, the change of resources can be backed up to the second backup source with the token. The change of resources can be committed to the first backup source if the back up of the change to the second backup source is successful.

Claims

1. A non-transitory computer-readable medium configured to store instructions that, when executed by a processor included in a server, cause the server to carry out steps that include:

storing, by the server, sequential snapshots that represent a file system of a device over time, the sequential snapshots including at least a first snapshot that is a complete backup of the file system and a second snapshot that is a partial backup of the file system that identifies files in the file system that have changed with respect to the first snapshot;

identifying, by the server, a change in at least one resource stored in the file system of the device, wherein communication between the server and the device is based at least in part on metadata associated with the at least one resource that represents a first level of abstraction of the at least one resource;

transmitting, from the server to the device, a token configured to authorize the device to backup, to one or more remote storage locations, a collection of data chunks that represent the at least one resource, wherein communication between the one or more remote storage locations and the device is based at least in part on the collection of data chunks, and the collection of data chunks represents a second layer of abstraction of the at least one resource that is distinct from the first level of abstraction; and

committing the change in the at least one resource to the server upon receiving a confirmation that the backup is complete, wherein committing the change includes;

merging the second snapshot with the first snapshot as an atomic operation, and

subsequent to identifying that merging the second snapshot with the first snapshot is successful, and upon determining that a number of the sequential snapshots satisfies a threshold;

generating a third snapshot that accounts for the change in the at least one resource such that a fixed number of snapshots is maintained for the device as the file system changes over time.

2. The medium of claim 1, wherein identifying comprises:

synchronizing a snapshot of the server with the device, the snapshot indicating resources that have already been backed up for the device at a previous point of time; and

comparing the resources of the device with the snapshot for identifying the change.

3. The medium of claim 2, wherein the device stores a cache snapshot, and synchronizing comprises:

determining, by the server, whether the cache snapshot is outdated with respect to the snapshot.

4. The medium of claim 2, wherein synchronizing is based on identifiers of the device, and the snapshot is maintained corresponding to the identifiers in the server.

5. The medium of claim 2, wherein the resources include files in the file system, and comparing comprises:

scanning the file system to track which files need to be backed up and which files have already been backed up based on the snapshot.

6. The medium of claim 5, wherein a file is not backed up when the file is available from a network accessible site.

7. The medium of claim 1, wherein the steps further include maintaining metadata for the at least one resource, wherein the metadata describes information about the at least one resource without describing actual content of the at least one resource.

8. The medium of claim 7, wherein the device is associated with an account having a backup quota, and the authorization indicates that backup space for the change of the resources is reserved in the backup storage without exceeding the backup quota.

9. The medium of claim 7, wherein a portion of the actual content corresponds to the change of the resources, and backing up comprises:

authenticating the device with the backup storage based on the token, the token referenced by the server; and

in response to instructions received from the backup storage, splitting the portion of the actual content into chunks of data according to the separate layer of abstraction of the resources.

10. The medium of claim 9, wherein the steps further include:

identifying, by the backup storage, which chunks of data do not exist and need to be backed up; and

uploading the chunks of data to the one or more remote storage locations.

11. The medium of claim 10, wherein the identifying which of the chunks of data comprises:

generating chunk identifiers uniquely identifying each chunk of data, wherein the backup storage determines that a chunk of data has already been backed up according to a chunk identifier of the chunk of data.

12. The medium of claim 11, wherein the chunk identifiers are signatures hashed from corresponding chunk data.

13. The medium of claim 11, wherein the resources include a file associated with at least one of the chunks of data split from the file, and the steps further include:

assigning an arbitrary identifier to the file as a reference in the backup storage for the chunks of data; and

deleting the file when the arbitrary identifier is no longer referenced.

14. The medium of claim 13, wherein a first one of the chunks of data does not need to be backed up when a second chunk of data exists in the backup storage and the second chunk of data is identified by a particular identifier identifying the first chunk of data, and the first and second chunks of data are associated with separate files assigned with separate arbitrary identifiers.

15. The medium of claim 10, wherein the uploading is enabled by an authentication key received in the device from the backup storage.

16. A computer implemented method, comprising:

at a server;

storing, by the server, sequential snapshots that represent a file system of a device over time, the sequential snapshots including at least a first snapshot that is a complete backup of the file system and a second snapshot that is a partial backup of the file system that identifies files in the file system that have changed with respect to the first snapshot;

identifying, by the server, a change in at least one resource stored in the file system of the device, wherein communication between the server and the device is based at least in part on metadata associated with the at least one resource that represents a first level of abstraction of the at least one resource;

transmitting, from the server to the device, a token configured to authorize the device to backup, to one or more remote storage locations, a collection of data chunks that represent the at least one resource, wherein communication between the one or more remote storage locations and the device is based at least in part on the collection of data chunks, and the collection of data chunks represents a second layer of abstraction of the at least one resource that is distinct from the first level of abstraction; and

committing the change in the at least one resource to the server upon receiving a confirmation that the backup is complete, wherein committing the change includes;

merging the second snapshot with the first snapshot as an atomic operation, and

subsequent to identifying that merging the second snapshot with the first snapshot is successful, and upon determining that a number of the sequential snapshots satisfies a threshold;

generating a third snapshot that accounts for the change in the at least one resource such that a fixed number of snapshots is maintained for the device as the file system changes over time.

17. The method of claim 16, wherein identifying comprises:

synchronizing a snapshot of the server with the device, the snapshot indicating resources that have already been backed up for the device at a previous point of time; and

comparing the resources of the device with the snapshot for identifying the change.

18. A server, comprising:

one or more processors; and

a memory storing instructions that, when executed by the one or more processors, the one or more processors to carry out steps that include;

storing, by the server, sequential snapshots that represent a file system of a device over time, the sequential snapshots including at least a first snapshot that is a complete backup of the file system and a second snapshot that is a partial backup of the file system that identifies files in the file system that have changed with respect to the first snapshot;

identifying, by the server, a change in at least one resource stored in the file system of the device, wherein communication between the server and the device is based at least in part on metadata associated with the at least one resource that represents a first level of abstraction of the at least one resource;

transmitting, from the server to the device, a token configured to authorize the device to backup, to one or more remote storage locations, a collection of data chunks that represent the at least one resource, wherein communication between the one or more remote storage locations and the device is based at least in part on the collection of data chunks, and the collection of data chunks represents a second layer of abstraction of the at least one resource that is distinct from the first level of abstraction; and

committing the change in the at least one resource to the server upon receiving a confirmation that the backup is complete, wherein committing the change includes;

merging the second snapshot with the first snapshot as an atomic operation, and

subsequent to identifying that merging the second snapshot with the first snapshot is successful, and upon determining that a number of the sequential snapshots satisfies a threshold;

generating a third snapshot that accounts for the change in the at least one resource such that a fixed number of snapshots is maintained for the device as the file system changes over time.

19. The server of claim 18, wherein identifying comprises:

synchronizing a snapshot of the server with the device, the snapshot indicating resources that have already been backed up for the device at a previous point of time; and

comparing the resources of the device with the snapshot for identifying the change.