# US 8,788,831 B2 · More elegant exastore apparatus and method of operation

> Agents: this data is available as JSON from the patentgrep API and MCP server — see https://patentgrep.com/llms.txt

- Number: US 8,788,831 B2
- Document ID: US8788831B2
- Status: Granted
- Kind: B2
- Application number: 13/246,386
- Filed: 2011-09-27
- Published: 2012-01-19
- Granted: 2014-07-22
- Earliest claimed: 2009-03-20
- Assignees: Barracuda Networks, Inc.
- Applicants: Lindsay Eugene Snider
- Inventors: Lindsay Eugene Snider
- Web page: https://patentgrep.com/patent/US8788831B2

## CPC

- G06F 21/6218: {to a system of files or objects, e.g. local or distributed file system or database}
- G06F 3/067: {Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]}
- G06F 11/1453: {using de-duplication of the data}
- G06F 11/1464: {for networked environments}
- H04L 9/0894: {Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage}
- H04L 9/3236: {using cryptographic hash functions}
- G06F 21/60: Protecting data
- G06F 21/62: Protecting access to data via a platform, e.g. using keys or access control rules
- G06F: ELECTRIC DIGITAL DATA PROCESSING (computer systems based on specific computational models G06N)
- H04L: TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION (arrangements common to telegraphic and telephonic communication H04M)

## Abstract

An apparatus to scale for multiple petabyte backup in redundant locations. Workload is automatically shared among many servers by a characteristic derived from the content itself. Duplicate storage is eliminated by checking for the existence or absence of simple files and appending client identification to files shared among multiple subscribers. Replication depends on simple atomic file operations rather than use of tables or databases. An efficient storage method for much larger quantities of data than conventional services.

## Claims

### Claim 1

A computer-implemented method for control of an apparatus comprising a processor configured by instructions stored on a non-transitory computer readable medium, the method comprising:
receiving from a backup client of a plurality of backup clients distinguishable by a client identifier, a substantially unique characteristic derived from a shard;
determining when the shard is a previously stored shard or a new shard to be stored by determining if a flat file already exists which has a name comprising the substantially unique characteristic derived from the shard,
when the shard is a previously stored shard,
appending the client identifier of the backup client to an end of a previously stored uniquely named flat file,
when the shard is a new shard to be stored,
requesting and storing the shard into an assigned server, and
creating and storing a new uniquely named flat file which contains an encryption key and the client identifier of the backup client, wherein the name of the new uniquely named flat file comprises the substantially unique characteristic derived from the shard,
creating a token file to request replication of the shard and the uniquely named flat file to at least one non-transitory computer-readable medium on another apparatus.

### Claim 2 (depends on 1)

The method of claim 1 wherein the substantially unique characteristic derived from the shard is a plurality of cryptographic hashes concatenated into a delimited string.

### Claim 3 (depends on 1)

The method of claim 1 wherein the shard is a portion of a data file.

### Claim 4 (depends on 1)

The method of claim 1 further comprising
deleting the token file when a shard of a uniquely named flat file has been successfully replicated.

### Claim 5 (depends on 4)

The method of claim 4 further comprising
assigning the shard and the substantially named flat file to a server according to an excerpt from the substantially unique characteristic derived from the shard.

### Claim 6 (depends on 5)

The method of claim 5 wherein the excerpt is a range of characters in the substantially unique characteristic.

### Claim 7 (depends on 6)

The method of claim 6 further comprising
assigning the shard to a group of servers based on the client identifier of the backup client.

### Claim 8

A method comprising,
receiving a shard and meta-data of a shard from a backup client, wherein the meta-data comprises a key for the shard;
assigning the shard to a server based on the first n bytes of the key,
creating a file containing an encryption key and a client id of the backup client, wherein the file containing the encryption key and the client id of the backup client referencing the shard is named with the metadata of the shard; and
storing the file and the shard on the server.

### Claim 9 (depends on 8)

The method of claim 8 wherein storing the file and storing the shard comprises
adding an action request file to the queue of the selected server and its replication server(s).

### Claim 10 (depends on 9)

The method of claim 9 further comprising
assigning to a group of servers based on the backup client ID.

### Claim 11 (depends on 8)

The method of claim 8 wherein the key is a hash computed on the shard.

### Claim 12

An apparatus comprising
a file management circuit to determine if a uniquely named flat file exists,
when the uniquely named flat file exists, to append a client identifier to the end of the file,
when the uniquely named flat file does not exist, to create and store a flat file comprising an encryption key and a client identifier and to request and store a shard with the substantially unique characteristic as the name of the flat file,
a receiver circuit configured to receive from a backup client a substantially unique characteristic derived from a shard and a client identifier, to assign the shard to a server according to an excerpt from the substantially unique characteristic, to assign the shard to a group of servers according to the client identifier, and request and receive a shard when the shard has been determined not to have been previously stored,
a file write and delete circuit configured to
append an additional client identifier to an end of a stored uniquely named flat file,
create and store a new uniquely named flat file containing an encryption key and a client identifier when the flat file does not already exist,
create at least one token file to request replication of a shard or a uniquely named flat file, and
delete the token file when the requested replication has succeeded.