Patent Description:
<CIT> discloses a system that processes data. The system includes a first client that encrypts a first set of data, uploads the encrypted first set of data to a volume on a cloud storage system, and creates a commit record of the upload. The system also includes a synchronization server that verifies access to the volume by the first client and includes the commit record in a change set containing a set of commit records associated with the volume.

<CIT> discloses an interface of a content management system that manages synchronized content on storage systems.

In at least one implementation, the disclosed technology provides a method for use with a cloud storage system according to claim <NUM>. The disclosed method includes receiving, at a cloud upload module from a storage device, an object that includes data and metadata, where the metadata including an object ID and an ingest timestamp corresponding to a time that the data was ingested into the storage device. The method also includes determining whether the object ID exists in an object database of objects stored in the cloud storage system. The method also includes determining a conflict status regarding uploading of the received object into the cloud storage system based on the ingest timestamp of the received object, responsive to the object ID being determined to exist in the object database.

There is further disclosed a computer program according to claim <NUM>. There is also disclosed a system according to claim <NUM>.

In cloud storage systems, data (e.g., data objects, such as files and/or blobs) is typically uploaded to cloud storage systems by way of online dedicated data servers and/or offline storage devices (e.g., hard disk drives, solid-state drives) that are physically transported from a customer site to a data center for upload into the cloud storage system. While dedicated data servers typically have relatively low latency when transferring data to a cloud storage system, the quantity of data that such data servers can transfer is often limited (i.e., they have relatively low bandwidth). Furthermore, increased upload latency can often result when customers are continuously generating data but have little to no network connectivity to transfer this data over the wire. In relation to transportable storage devices, they enjoy relatively high bandwidth, as TBs of data can be stored onto such device in short periods of time. However, use of transportable storage devices also results in increased latency (e.g., days, weeks) as such devices typically need to be physically shipped (offline) on a truck or the like from a customer data center to a cloud data center for upload to the cloud storage system.

The disclosed technology makes use of one or more transportable storage devices (each referred to herein as "data boxes," "data box pods," or "pods") that are communicatively coupled (e.g., wired, wirelessly) behind one or more dedicated data servers (each referred to herein as a "data box edge," "edge data server," or "edge" and collectively an "edge storage system") to take advantage of the benefits of the data servers and transportable storage devices while limiting their disadvantages. A data box edge stores data (e.g., from one or more client devices) and copies the data to one or more of the data boxes to which it is communicatively coupled. The data box edge may maintain the data thereon (for access by client devices) until and if storage on the edge becomes limited, at which time the edge may delete the data therefrom and thereafter serve requests for the data from its one or more data boxes (e.g., where the data boxes may effectively serve as a cloud storage space for the edge).

In some cases, an edge may store additional copies of the data on other of the pods to which it is communicatively coupled. The edge also maintains a namespace including a database of object identifiers (e.g., data object names) that link to the copies of the data on the edge and/or on the pod(s). In any case, an edge indicates when one of its pods is filled up and thus ready for offline shipment to the cloud. Upon communicative decoupling of a pod from its edge and during transport to a data center for upload to the cloud storage system, the object identifier for the data stored on the pod may remain in the namespace of the edge. Accordingly, upon the edge receiving a request for the object identifier of the data before the pod has reached the data center, the edge may return a "data temporarily unavailable" message to the requester. In the case where the data is stored on another pod to which the edge is communicatively coupled, the edge may retrieve the data from such pod and return the same to the requester. Upon the edge receiving a request for the object identifier of the data after receipt of the pod at the data center and upload of the data to the cloud storage system, the edge may download the data from the cloud storage system and serve the data to the requesting device. Once the data in transit has been ingested into the cloud storage system, the edge drops (deletes) the one or more additional copies of the data and may continue to fill data continuously to the pods on-premise.

Upon ingestion of data on one or more edges, the data can be uploaded from the one or more edges on a low-latency, low bandwidth LAN to the cloud storage system (when the edge(s) is/are online) and/or copied to one or more of its pods and transferred to the cloud by way of physically transporting the pod(s) to a cloud data center and uploading the data to the cloud (e.g., as a high-latency, high-bandwidth WAN to the cloud). When different versions of the same data are delivered/uploaded to the cloud storage system from edges and/or pods in various orders, the most recent version of the data will ultimately be stored in the cloud for subsequent downloads to the edges while older versions may be deleted or archived.

For example, a first version of data may be ingested into an edge at a first time and copied onto a first of its pods, which may be subsequently communicatively decoupled from its edge, transported to a data center, and uploaded to the cloud storage center. The namespaces of all edges at a customer's site may then be refreshed to include the object identifier of the first data version. At a (later) second time, a first user may access the object identifier in the namespace of a first edge to download a copy of the data from the cloud storage center and create a second version of the data, which may be ingested into the first edge at a first ingest time and copied to one of its pods. At a still later third time, a second user may access the object identifier in the namespace of a second edge to download a copy of the data from the cloud storage center and create a third version of the data which may be ingested into the first edge at a second ingest time and copied to one of its pods.

Assuming no further updates to the data occur, the third version of the data will be the version ultimately stored to the cloud storage system (regardless of the order in which the two pods arrive at the cloud data center as the second time is more recent than the first time). If the pod storing the second version arrives first, the second version may be initially uploaded, and then the third version may be uploaded and overwrite the second version when the pod storing the third version arrives. For example, a cloud upload module or engine may analyze ingest time metadata associated with the second and third versions to determine that the third version is more recent. Alternatively, if the pod storing the third version arrives first, the third (most recent) version may be uploaded. When the second version arrives at the cloud data center, the cloud upload module may inhibit uploading of the second version as its ingest metadata is older than that of the third version.

As another example, the cloud storage system may already store a version of a data object along with metadata including a first ingest time (i.e., the time at which the data version was ingested to an edge). Upon subsequent receipt at the cloud upload module of another version of the object having metadata including a second ingest time older than the first ingest time, the cloud upload module may disallow uploading of the other version of the obj ect.

Data can be concurrently uploaded from the edge and transported in the pod for upload to take advantage of low latency connections of the edge when available and high bandwidth of the pod. By the time the pod arrives at the cloud data center for upload to the cloud storage system, the cloud upload module can determine which portions of the data were already uploaded from the edge and then only initiate upload from the pod those portions not yet uploaded. In various implementations, the edge can upload to the cloud using an edge upload module, and the pod can upload to the cloud using a cloud upload module. The ordering of such uploads may vary, which can create out-of-order conflicts in the uploaded data if not handled.

Different edges may contain different versions of the same cloud data, and in the end, the most recent cloud data will end up in the cloud storage system. While connected to the Internet, an edge can download the most recent cloud data from all other edges. Furthermore, changes made by users to data versions in the cloud are eventually propagated back to the edge(s) and vice versa.

<FIG> illustrates an example system <NUM> for managing online and offline transfer of data between a cloud storage system <NUM> and one or more remote storage systems. As shown, a user may create or otherwise obtain data on a client device <NUM> (e.g., laptop, tablet, internet of things (IoT) device, and/or other computing device) and ingest the same from the client device <NUM> into an edge storage system <NUM> of a customer site made up of one or more data box edges <NUM>. Thereafter, each data box edge <NUM> automatically copies or otherwise backs up the ingested data (e.g., full files/blobs) into one or more data box pods <NUM> to which each of the data box edges <NUM> is communicatively coupled.

Each data box edge <NUM> may be a physical device (e.g., rack-mounted server or the like) residing on a customer's premises and data objects may be written to the data box edge <NUM>, such as via Network File System (NFS), Server Message Block (SMB) and Azure storage protocols. In some arrangements, the data box edge <NUM> may preprocess data obtained from one or more client devices <NUM> such as by aggregating data, modifying data (e.g., to remove Personally Identifiable Information (PII)), and the like. A local web user interface of the data box edge <NUM> allows users to run diagnostics, shut down and restart the data box edge <NUM>, and the like. Furthermore, a resource (e.g., application) in a portal used to access the cloud storage system <NUM> allows users to manage the data box edge <NUM> from a web interface accessible from various geographical locations.

Before either of the data box edge(s) <NUM> or data box pod(s) <NUM> is substantially filled, requests for the data may be served from the data box edge(s) <NUM> and/or the data box pod(s) <NUM>. When the data box edge <NUM> is online, it may upload the data to the cloud storage system <NUM> in any appropriate manner. Additionally, or alternatively, the data box pod(s) <NUM> may be communicatively decoupled from the edge storage system <NUM> and then physically transported (e.g., offline via a truck or the like) to a data center <NUM> for upload of the data to the cloud storage system <NUM>. For example, upon a data box pod <NUM> becoming at least substantially filled, the edge storage system <NUM> may detect the same and generate a signal that the data box pod <NUM> needs to be shipped to the data center <NUM> for upload of the data.

Regardless of the order in which the data arrives at the cloud storage system <NUM> or data center <NUM>, the correct (e.g., most recent) version of the data is the version that will be stored in the cloud storage system <NUM>. For example, in the event that a new version of data is ingested into a data box edge <NUM> and uploaded to the cloud storage system <NUM> while an older version of the data stored on a data box pod <NUM> is being shipped to the data center <NUM>, the disclosed technology will inhibit the older version, once the data box pod <NUM> arrives at the data center <NUM>, from being uploaded to the cloud storage system <NUM> so as to not overwrite the newer version (e.g., by way of detecting that the newer version is linked to a more recent edge ingest time than is the older version). Each data box edge <NUM> can also download data from the cloud storage system <NUM>.

<FIG> illustrates another example system for managing online and offline transfer of data between a cloud storage system <NUM> and one or more remote storage systems in a manner ensuring that in the case of multiple different versions of data being stored at different times in different portions of the system, the most recent (correct) version of the data will be the version ultimately stored on the cloud storage system <NUM> and later downloaded for storage to one or more data box edges <NUM> in the system while older versions will be archived and/or deleted. A customer data center <NUM> broadly includes at least one client device <NUM> (e.g., laptop, desktop, tablet, and/or another computing device), and at least one data box edge <NUM> (e.g., data server, only one shown in <FIG>) that is configured to ingest copies of data created on or otherwise obtained by the client device <NUM>. The customer data center <NUM> may also employ one or more one data box pods <NUM> (e.g., transportable storage devices, only one shown in <FIG>) communicatively coupled (e.g., wired, wirelessly) to each data box edge <NUM> to which the data box edge <NUM> is configured to automatically copy data ingested from client device <NUM>. It should be understood that the edge can operate without any pods connected to it, any pods in transport, or any pods uploading to the cloud storage system <NUM>.

Data from each data box edge <NUM> may be selectively written (uploaded) to the cloud storage system <NUM>, data from the cloud storage system <NUM> may be read by each data box edge <NUM>, and each data box edge <NUM> may refresh data already stored on the data box edge <NUM> with updated versions of the data stored on the cloud storage system <NUM>. Furthermore, each data box pod <NUM> may be communicatively decoupled (e.g., detached) from its corresponding data box edge <NUM> and transported to a cloud data center <NUM> for selective upload of the data stored on the data box pod <NUM> to the cloud storage system. In one arrangement, an indication that the data box pod <NUM> is unable to accept further storage of data thereon may be generated by the data box pod <NUM> and passed to the data box edge <NUM> whereby the communicative decoupling of the data box pod <NUM> from the data box edge <NUM> occurs responsive to the received indication.

As discussed herein, it is important that in the case where multiple versions of the same data are stored at different times in different portions of the system, the most recent (correct) version of the data will be the version ultimately stored on the cloud storage system <NUM>. In this regard, the disclosed technology generates and makes use of metadata to allow for the intelligent assessment of multiple versions of data and identification of the correct version of the data to be stored on a cloud storage system. The technology encapsulates the metadata (and sometimes also the actual customer data) into "objects" (e.g., data structures) that are stored in various portions of the system and used to reconcile conflicts among multiple data versions as will be discussed.

Upon ingestion of customer data <NUM> (e.g., one or more data objects) from client device <NUM> into data box edge <NUM>, the data box edge <NUM> generates or obtains metadata including a last data box edge ingest time ("dbit") <NUM> and an object identifier ("obj id") <NUM> and then encapsulates the data <NUM> and metadata into a data object <NUM>. The dbit <NUM> represents a time that the data <NUM> was ingested or copied into the data box edge <NUM> (e.g., as identified by a timestamp of the client device <NUM> or the data box edge <NUM>) while the object identifier <NUM> is used to uniquely identify the data <NUM> from other pieces of data (e.g., other data objects). However, in the case where two different pieces of data <NUM> represent different versions of the same underlying data object, for example, the two data objects <NUM> for such two pieces of data <NUM> would share the same object identifier <NUM>. While <FIG> only illustrates a single data object <NUM> in the data box edge <NUM>, it is to be understood that each data box edge <NUM> may store numerous data objects <NUM>. For example, two or more data objects in different locations (e.g., the edge, one or more pods, the cloud) and/or different states (e.g., different ingest times) may share the same object identifiers <NUM> but have different dbits <NUM>; alternatively, two or more data objects may have different object identifiers <NUM>, data <NUM>, and dbits <NUM>; and the like.

As noted herein, when moving data from the edge via data box pods, the data box edge <NUM> copies data objects <NUM> to one or more data box pods <NUM> that are communicatively coupled to the data box edge <NUM>. Thus, while the same reference numerals are used to describe the data object <NUM> in the data box edge <NUM> and the data object <NUM> in the data box pod <NUM>, it is to be understood that the data objects are logically different (different storage locations, different states), even if they have the same information/data. The data objects <NUM> may be maintained in the data box edge <NUM> and the data box pod <NUM> until such time that the data box edge <NUM> needs to make more room for further data ingestion from the client device <NUM>, at which time the data box edge <NUM> may delete the actual data storage of the data object <NUM> from the data box edge <NUM>, leaving a placeholder or "data stub" in the namespace of the data box edge <NUM> and treating the data object <NUM> in the data box pod <NUM> as a cloud-based version of the data (that it can "download" from the data box pod <NUM> as needed) while the data box pod <NUM> is communicatively coupled to the data box edge <NUM> (e.g., before shipment to the cloud data center <NUM>). In this manner, data storage associated with the data object <NUM> is removed from the data box edge <NUM>, but the object identifier of the data object <NUM> remains in the namespace of the data box edge <NUM>. The data box edge <NUM> or data box pod <NUM> also assigns a pod identifier ("pod id") <NUM> to the data box pod <NUM> to uniquely identify the data box pod <NUM> among other data box pods <NUM> in the customer data center <NUM>.

To read a data object <NUM> from a data box pod <NUM> at the customer data center <NUM>, the data box edge <NUM> may determine whether the pod id of an incoming request matches a pod id <NUM> in an object <NUM> of the metabase <NUM>, whether at least one data object <NUM> exists in the data box pod <NUM>, and whether the dbit <NUM> of the data box pod <NUM> matches the dbit <NUM> of the metabase <NUM>; if so, the data <NUM> of the data box pod <NUM> is returned. Otherwise, a "not found" message or the like is returned. To write a data object <NUM> to a data box pod <NUM> at the customer data center <NUM>, the data box edge <NUM> may specifies the pod id <NUM> of the data box pod <NUM> in a write request, writes the data object <NUM> to the corresponding data box pod <NUM> that matches a pod id <NUM>, and updates the ingest time (e.g., dbit <NUM>) of the data object written to the data box pod <NUM>.

Upon communicative decoupling of the data box pod <NUM> from its data box edge <NUM> (e.g., upon detection that the data box pod <NUM> is full or at another appropriate time) and shipment to the cloud data center <NUM>, the data <NUM> and metadata on the data box pod <NUM> may be uploaded to the cloud storage system <NUM> in any appropriate manner (e.g., LAN, WAN, etc.). As part of the upload of the data <NUM> and metadata to the cloud storage system <NUM>, the cloud storage system <NUM> generates or obtains additional metadata and then encapsulates the data <NUM>, metadata from the data box pod <NUM>, and additional metadata into a data object <NUM> and stores the same in any appropriate region or area of the cloud storage system <NUM>. While only a single data object <NUM> is illustrated in <FIG>, the cloud storage system <NUM> may actually store numerous objects corresponding to numerous different object identifiers <NUM> and different data <NUM>.

As shown, the additional metadata includes an entity tag ("etag") <NUM>, a last data box upload time ("dbut") <NUM>, and optionally a last cloud modify time ("mt") <NUM>. The etag <NUM> is generated by the cloud storage system <NUM> each time a data object <NUM> is created or updated in the cloud storage system <NUM> and allows a last writer of the data <NUM> in the data object <NUM> (who alone knows the etag <NUM>) to take a "happy path" to the data object <NUM> and further update the data object <NUM> without having to "lease" the data object (determine whether or not data objects <NUM> from the data box edge <NUM> or data box pod <NUM> conflicts) assuming no updates to the data object <NUM> have occurred on the cloud storage system <NUM>. The dbut <NUM> represents a time that the data <NUM> was uploaded from the data box edge <NUM> to the cloud storage system <NUM> (e.g., as identified by a timestamp of the data box edge <NUM> or cloud storage system <NUM>) or from the cloud data center <NUM> to the cloud storage system <NUM> (e.g., as identified by a timestamp of the cloud data center <NUM> or cloud storage system <NUM>). The mt <NUM> is generated by the cloud storage system <NUM> each time a data object <NUM> is updated on the cloud storage system <NUM> (e.g., whether by a third party editing the object directly on the cloud storage system <NUM>, via upload of updated data from the cloud data center <NUM>, or upload of updated data from the data box edge <NUM>).

Each data box edge <NUM> maintains and/or has access to a metabase (mb) <NUM> that is broadly configured to store metadata for objects maintained in the customer data center <NUM> and cloud storage system <NUM> for use in identifying object conflicts as discussed in more detail below. The mb <NUM> may be maintained within the data box edge <NUM> and/or be maintained in a separate device and accessible to the data box edge <NUM> in any appropriate manner. For each respective object identifier <NUM>, the data box edge <NUM> may encapsulate within an object <NUM> the current etag <NUM> received from the cloud storage system <NUM> (e.g., which may be pushed down to the customer data center <NUM> upon creation or update of a corresponding data object <NUM>), the dbit <NUM>, the pod identifier <NUM>, and the object identifier <NUM>. While each data object <NUM> in the cloud storage system <NUM> is illustrated as including both the customer data <NUM> and the various pieces of metadata, one implementation envisions that the cloud storage system <NUM> may also include a metabase of the metadata while the customer data <NUM> may be stored separately from the metabase. In this implementation, the metadata would be linked to the customer data <NUM> by way of the object identifier <NUM> (e.g., where the same object identifier <NUM> would be stored with the metadata in the metabase and separately with the customer data <NUM>).

Before discussing how the metadata is utilized by the disclosed technology to identify conflicts among various data objects, reference is made to <FIG> which illustrates how a customer data center <NUM> may include a plurality of data box edges <NUM> storing objects <NUM>, where each data box edge <NUM> includes one or more data box pods <NUM> communicatively coupled thereto, and where each data box edge includes a metabase <NUM> of objects <NUM>. Furthermore, each data box edge <NUM> maintains a namespace <NUM> (e.g., directory) of object identifiers (UIDs) <NUM> (e.g., data object paths) corresponding to customer data in the data box edge <NUM>, its data box pods <NUM>, other data box edges <NUM>, and the cloud storage system. Upon ingestion of customer data into a data box edge <NUM> and creation of corresponding objects <NUM>, the data box edge <NUM> creates or obtains a UID <NUM> for the data in the namespace <NUM> that allows users to see that the data exists (e.g., via a user interface in communication with the namespace <NUM>).

In various implementations, the object identifiers at the edge, the pod, and the cloud are identical. In other implementations, the object identifiers at the edge, the pod, and the cloud may be mapped transformations of each other or otherwise different by providing enough information to allow correspondence and/or association of such object identifiers to be determined by the edge, the pod, and the cloud.

As discussed herein, situations exist in which particular data is only available on a single data box pod <NUM> (e.g., the data has been removed from its corresponding data box edge <NUM>) which is subsequently communicatively decoupled from its data box edge <NUM> and has not yet reached the cloud data center for upload to the cloud storage system. In this case, the UID <NUM> for the data on the data box pod remains in the namespace <NUM> of the data box edge <NUM> so that client devices can see that the corresponding data exists (in contrast to other systems where data on a transportable device in transit is essentially invisible to client devices until the transportable device has been uploaded to a cloud storage system). However, manipulation of the UID <NUM> in the namespace <NUM> before uploading of the data to the cloud storage system induces the data box edge <NUM> to return a "data temporarily unavailable" message or the like to the user. In this regard, the UID <NUM> serves as a data stub while the data box pod <NUM> is in transit. Once the data has been uploaded to the cloud storage system, manipulation of the corresponding UID <NUM> in the namespace <NUM> induces the data box edge <NUM> to download the corresponding data from the cloud storage system and serve the data to the client device.

In the situation where a data box edge <NUM> has uploaded one or more particular objects <NUM> to the cloud storage system, the data box edge <NUM> may "ghost" (e.g., remove, stub) the one or more objects from the data box edge <NUM> while maintaining their corresponding UIDs <NUM> in the namespace <NUM>. A subsequent access of such corresponding UIDs <NUM> induces the data box edge <NUM> to download the corresponding data from the cloud storage system and serve the data to the client device. The various data box edges <NUM> are also configured to share updates to their respective namespaces <NUM> with the other data boxes edges <NUM> such that the namespaces <NUM> of all data box edges <NUM> are identical or nearly identical in substantially real time. In relation to access of a particular UID <NUM> in the namespace <NUM> of a data box edge <NUM> where the corresponding data is stored on the data box edge <NUM>, the data box edge <NUM> returns the data to the client device. In relation to access of a particular UID <NUM> in the namespace <NUM> of a data box edge <NUM> where the corresponding data is only stored in the cloud storage system, the data box edge <NUM> downloads and returns the corresponding data to the client device. In relation to access of a particular UID <NUM> in the namespace <NUM> of a data box edge <NUM> where the corresponding data is only stored on another data box edge <NUM> (or only on the other data box edge's <NUM> corresponding data box pod <NUM>), the data box edge <NUM> may request and receive the corresponding data from the other data box edge <NUM> and then serve the data to the client device, in some implementations.

As discussed herein, it is important for the disclosed technology to maintain the most recent version of data (e.g., of a data object) on the cloud storage system despite various versions of the data possibly existing on data box edges, data box pods communicatively coupled to their data box edges or in transit, and the like. With reference now to <FIG>, an object upload module <NUM> is illustrated that is configured to determine a conflict status of an object stored in a data box pod. The object upload module <NUM> may be resident on the cloud data center and/or on the cloud storage system. Broadly, the object upload module <NUM> includes a receiver <NUM> that receives a pod object <NUM> and an object analyzer <NUM> that evaluates the metadata of the pod object <NUM> in view of objects stored in the cloud storage system to determine whether data and metadata in the pod object should be uploaded to the cloud storage system.

The analyzer <NUM> may initially use the object identifier <NUM> of the pod object <NUM> as a key into a database of objects in the cloud storage system to determine whether the same object identifier <NUM> already exists in the cloud storage system. If the analyzer <NUM> determines that the same object identifier does not already exist in the cloud storage system, the object upload module <NUM> may then initiate upload of the pod object <NUM> into the cloud storage system whereby the cloud storage system creates a corresponding cloud object <NUM>. In this case, the object identifier <NUM> of the cloud object <NUM> would be the same as the object identifier <NUM> of the pod object <NUM>, the dbit <NUM> of the cloud object <NUM> would be the same as the dbit <NUM> of the pod object <NUM>, and the data <NUM> of the cloud object <NUM> would be the same as the data <NUM> of the pod object <NUM>.

If the analyzer <NUM> determines that the object identifier <NUM> of the pod object <NUM> already exists in the cloud storage system (i.e., the object identifier <NUM> of an existing cloud object <NUM> in the cloud storage system matches the object identifier <NUM> of the incoming pod object <NUM>), then the analyzer <NUM> initially compares the respective dbits <NUM>, <NUM>. If the dbit <NUM> of the existing cloud object <NUM> is more recent than the dbit <NUM> of the pod object <NUM>, then the data <NUM> in the existing cloud object <NUM> was modified more recently than the data <NUM> in the incoming pod object <NUM> (e.g., updated data associated with the same object identifier was ingested into a data box pod after ingestion of the data <NUM> of the pod object <NUM> but uploaded to the cloud storage system before arrival of the pod object <NUM> at the object upload module <NUM>). Accordingly, the object upload module <NUM> inhibits uploading of the pod object <NUM> into the cloud storage system.

Even if the dbit <NUM> of the pod object <NUM> is more recent than the dbit <NUM> of the cloud object <NUM>, the analyzer <NUM> then assesses whether the mt <NUM> in the cloud object <NUM> is more recent than the dbut <NUM> in the cloud object <NUM>; if so, this means that a user has updated the data <NUM> in the cloud object <NUM> from or at the cloud storage system rather than via a data box edge or pod. Specifically, if a user has updated the data <NUM> directly via the cloud storage system, the mt <NUM> would be updated but the dbut <NUM> would not. Accordingly, the object upload module <NUM> inhibits uploading of the pod object <NUM> into the cloud storage system.

If the analyzer <NUM> determines that the dbit <NUM> is more recent that the dbit <NUM> and the dbut <NUM> is more recent than the mt <NUM>, then the object upload module <NUM> allows upload of the pod object <NUM> into the cloud storage space. In this case, the cloud storage system would replace the dbit <NUM> with the dbit <NUM> of the incoming pod object <NUM> and replace the data <NUM> with the data <NUM> in the incoming pod object <NUM>. The cloud storage system would also update the mt <NUM> and the dbut <NUM> to the current time and generate a new etag <NUM>. In one implementation, the cloud storage system may subtract a predetermined amount of "slop" time from the current time before setting the updated dbut <NUM>. In any case, subsequent requests for the UID in the namespace of one or more of the data box edges would initiate download of the updated data <NUM> from the cloud storage system to the requesting data box edge. As part of this process, the downloading data box edge would update the corresponding object in its metabase (e.g., metabase <NUM> of <FIG>) to reflect the updated metadata.

With reference now to <FIG>, an object upload module <NUM> is illustrated that is configured to determine a conflict status of an object stored in the edge storage system (e.g., a data box edge) to be uploaded to the cloud storage system. The object upload module <NUM> may be resident on the cloud storage system and/or on the edge storage system. Broadly, the object upload module <NUM> includes a receiver <NUM> that receives a metabase object <NUM> and an object analyzer <NUM> (e.g., a conflict manager) that evaluates the metadata of the metabase object <NUM> in view of objects stored in the cloud storage system to determine whether data and metadata should be uploaded from the corresponding data box edge to the cloud storage system. While the metabase object <NUM> is illustrated as including data <NUM> for purposes of facilitating the below discussion, the data <NUM> may in some arrangements be stored in an object of the data box edge (e.g., as in <FIG>) in which case the object upload module <NUM> would retrieve the data from the data box edge object and facilitate upload of the same to the cloud storage system if the object upload module <NUM> so decides.

The analyzer <NUM> may initially use the object identifier <NUM> of the metabase object <NUM> as a key into a database of objects in the cloud storage system to determine whether the same object identifier <NUM> already exists in the cloud storage system. If the analyzer <NUM> determines that the same object identifier does not already exist in the cloud storage system, the object upload module <NUM> may then initiate upload of the metabase object <NUM> into the cloud storage system whereby the cloud storage system creates a corresponding cloud object <NUM>. In this case, the object identifier <NUM> of the cloud object <NUM> would be the same as the object identifier <NUM> of the metabase object <NUM>, the dbit <NUM> of the cloud object <NUM> would be the same as the dbit <NUM> of the metabase object <NUM>, and the data <NUM> of the cloud object <NUM> would be the same as the data <NUM> of the metabase object <NUM>.

If the analyzer <NUM> determines that the object identifier <NUM> of the metabase object <NUM> already exists in the cloud storage system (i.e., the object identifier <NUM> of an existing cloud object <NUM> in the cloud storage system matches the object identifier <NUM> of the incoming metabase object <NUM>), then the analyzer <NUM> then determines whether the etag <NUM> of the incoming metabase object <NUM> matches the etag <NUM> of the existing cloud object <NUM>. As discussed herein, an etag <NUM> is generated by the cloud storage system each time the cloud object <NUM> is updated (e.g., each time the data <NUM> is updated), and typically only the user associated with the most recent update of the object <NUM> is aware of the etag <NUM>.

Accordingly, if the analyzer <NUM> determines that the etag <NUM> in the incoming metabase object <NUM> matches the etag <NUM> in the existing cloud object <NUM>, this means it is the most recent user that is updating its own data, and the object upload module <NUM> thus initiates upload of the metabase object <NUM> to the cloud storage system. In other words, the user of the etag <NUM> matching the etag <NUM> allows the user to take a "happy path" to the cloud object <NUM> and thus modify the data <NUM> free of having to first determine whether any other updates have priority. In this case, the cloud storage system would replace the dbit <NUM> with the dbit <NUM> of the incoming metabase object <NUM> and replace the data <NUM> with the data <NUM> in the incoming metabase object <NUM>. The cloud storage system would also update the mt <NUM> and the dbut <NUM> to the current time and generate a new etag <NUM>. In this regard, subsequent requests for the UID in the namespace of one or more of the data box edges would initiate download of the updated data <NUM> from the cloud storage system to the requesting data box edge. As part of this process, the downloading data box edge would update the corresponding object in its metabase (e.g., metabase <NUM> of <FIG>) to reflect the updated metadata (e.g., the updated dbit <NUM>, mt <NUM>, dbut <NUM>, etag <NUM>, etc.).

If the analyzer <NUM> determines that the etag <NUM> in the incoming metabase object <NUM> does not match the etag <NUM> in the existing cloud object <NUM>, then the data <NUM> in the incoming metabase object <NUM> was presumably not generated by the user associated with the most recent update of the data <NUM> in the cloud object <NUM>. Accordingly, the analyzer <NUM> then compares the respective dbits <NUM>, <NUM>. If the dbit <NUM> of the existing cloud object <NUM> is more recent than the dbit <NUM> of the metabase object <NUM>, then the data <NUM> in the existing cloud object <NUM> was modified more recently that the data <NUM> in the incoming metabase object <NUM> (e.g., updated data associated with the same object identifier was ingested into a data box edge after ingestion of the data <NUM> of the metabase object <NUM> but uploaded to the cloud storage system before arrival of the metabase object <NUM> at the object upload module <NUM>). Accordingly, the object upload module <NUM> inhibits uploading of the metabase object <NUM> into the cloud storage system.

Even if the dbit <NUM> of the metabase object <NUM> is more recent than the dbit <NUM> of the cloud object <NUM>, the analyzer <NUM> then assesses whether the mt <NUM> in the cloud object <NUM> is more recent than the dbut <NUM> in the cloud object <NUM>; if so, this means that a user has updated the data <NUM> in the cloud object <NUM> from or at the cloud storage system rather than via a data box edge or pod. Accordingly, the object upload module <NUM> inhibits uploading of the metabase object <NUM> into the cloud storage system. If the analyzer <NUM> determines that the dbit <NUM> is more recent that the dbit <NUM> and the dbut <NUM> is more recent than the mt <NUM>, then the object upload module <NUM> allows upload of the metabase object <NUM> into the cloud storage system. In this case, the cloud storage system would replace the dbit <NUM> with the dbit <NUM> of the incoming metabase object <NUM> and replace the data <NUM> with the data <NUM> in the incoming metabase object <NUM>. The cloud storage system would also update the mt <NUM> and the dbut <NUM> to the current time and generate a new etag <NUM>. In this regard, subsequent requests for the UID in the namespace of one or more of the data box edges would initiate download of the updated data <NUM> from the cloud storage system to the requesting data box edge. As part of this process, the downloading data box edge would update the corresponding object in its metabase (e.g., metabase <NUM> of <FIG>) to reflect the updated metadata.

It should be understood that an object upload module at a pod or for uploading of pod data to the cloud, such as the object upload module <NUM> may employ the same or similar uploading operations and accompanying data as an object upload module at an edge, such the object upload module <NUM>. Alternatively, either one of the modules may have different operations and/or data. For example, in one implementation, etags may not be transported with a pod (such as shown in <FIG>) and, as such, the object upload module <NUM> may not be capable of comparing etags with the cloud storage system metabase. However, in other implementations, etags may be transported with the pod, and so etag comparison may be available for uploading from a pod to the cloud.

<FIG> illustrates an example method <NUM> of determining a conflict status of objects and managing uploads of the objects to a cloud storage system. Upon an operation <NUM> of receiving an object from a remote storage device (e.g., from a data box pod or edge, etc.), the method <NUM> includes a query <NUM> asking whether an object ID of the received object already exists in the cloud storage system. In response to a negative answer to the query <NUM>, the method <NUM> proceeds to an upload operation <NUM> whereby the received object is uploaded to the cloud storage system. Otherwise, the method <NUM> proceeds to another query operation <NUM> asking whether an entity tag (e.g., etag) of the received object already exists in the cloud storage system. In response to an affirmative answer to the query operation <NUM>, the method <NUM> proceeds to the upload operation <NUM>. Otherwise, the method proceeds to a further query <NUM> asking whether an ingest timestamp (e.g., dbit) associated with the existing object id in the cloud storage system is more recent than an ingest timestamp in the received object. In response to an affirmative answer to the query <NUM>, the method <NUM> concludes that a conflict status for the potential upload is that there is a conflict (i.e., between the received object and an existing object in the cloud storage system) and then proceeds to an upload disallowing operation <NUM> that disallows upload of the received object into the cloud storage system. Otherwise, the method <NUM> proceeds to a still yet further query <NUM> asking whether a last cloud modified timestamp (e.g., mt) associated with the existing object id in the cloud storage system is more recent than a last cloud upload timestamp (e.g., dbut) associated with the existing object id in the cloud storage system. The method <NUM> concludes that a conflict status for the potential upload is that there is a conflict and then proceeds to the upload disallowing operation <NUM> in response to an affirmative answer to the query <NUM> and concludes that a conflict status for the potential upload is that there is no conflict and then proceeds to the upload operation <NUM> in response to a negative answer to the query <NUM>.

<FIG> illustrates example operations <NUM> for managing requests to read objects in a cloud storage system. A query operation <NUM> asks whether an entity tag is already present in a data box edge metabase (e.g., metabase <NUM> of <FIG>). If so, another query operation <NUM> asks whether the entity tag in the metabase is the same as an entity tag already present in the cloud storage system. If so, then a data returning operation <NUM> includes returning data in the cloud storage system associated with the entity tag to the data box edge or other requested location. If the answer to the query operation <NUM> is negative, then a message returning operation <NUM> returns an "object not found" message or the like (e.g., a "wait" message). If the answer to the query operation <NUM> is negative, then another query operation <NUM> asks whether an ingest timestamp in the metabase is equal to the ingest timestamp in the cloud storage system (e.g., both of which are associated with the same object identifier). A positive answer to the query operation <NUM> includes a setting operation <NUM> that sets the entity tag in the metabase to be the same as that in the cloud storage system. A negative answer to the query operation <NUM> and/or completion of the setting operation <NUM> directs processing to the query operation <NUM> to evaluate whether the etags have changed.

<FIG> illustrates example operations <NUM> of refreshing objects from a cloud storage system to an edge storage system. A query operation <NUM> initially asks whether a data object handle is open or work on that data object is incomplete. If so, a waiting operation <NUM> includes waiting before returning to the query <NUM>. Otherwise, a query operation <NUM> compares an ingest timestamp of an existing object in the cloud storage system to an ingest timestamp of a corresponding object in the edge storage server (e.g., as stored in metabase <NUM> of <FIG>), both of the ingest timestamps being linked to the same object identifier. If the ingest timestamp from the cloud storage system is equal to the ingest timestamp from the edge storage server, then processing returns to the query operation <NUM>.

If the ingest timestamp from the cloud storage system is greater than the ingest timestamp from the edge storage server, then a concluding operation <NUM> concludes that the cloud storage system has newer data than the edge storage system (e.g., the data <NUM> in cloud data object <NUM> is newer than data <NUM> in data box edge <NUM>, the object identifiers <NUM> in the cloud data object <NUM> and data box edge <NUM> being the same). Thereafter, a replacing operation <NUM> replaces the entity tag of the edge storage server (e.g., the entity tag in the metabase <NUM>) with the entity tag of the cloud storage system and the ingest timestamp of the edge storage server with the ingest timestamp of the cloud storage system. Processing then returns to the query operation <NUM>.

If the ingest timestamp from the cloud storage system is greater than the ingest timestamp from the edge storage server, then another concluding operation <NUM> concludes that the edge storage system has newer data than the cloud storage system. Thereafter, a query operation <NUM> queries whether the last cloud upload timestamp (e.g., dbut) is the same as or more recent than the last cloud modified timestamp (e.g., mt). If so, a concluding operation <NUM> concludes that a transportable device (e.g., data box pod) is in transit; otherwise, a concluding operation <NUM> concludes that the edge and cloud storage systems both have newer data than a third-party cloud update. If an object is in the data box edge metabase but a corresponding object is not yet in the cloud storage system, a user would have to wait if a data object handle is open or work on that data object is incomplete. Otherwise, the data box edge concludes that the object is stale and thereafter deletes the data box edge object (e.g., data object <NUM> in <FIG>) and the corresponding metabase object (e.g., object <NUM> in <FIG>). Processing then returns to the query operation <NUM>.

As discussed previously, existing servers that make use of transportable storage devices (e.g., for backups, etc.) remove the names of data objects on the transportable storage devices from a namespace of the servers upon communicative decoupling of the transportable storage devices from the servers for eventual upload to a cloud storage system (e.g., assuming the servers also no longer maintain a copy of the corresponding data objects). However, this situation can sometimes result in temporary "loss" of the data objects (e.g., client devices cannot see the data objects) during the time after communicative decoupling of a transportable storage device from a server and before upload of the data objects on the transportable storage device to a cloud storage system.

In this regard, <FIG> illustrates an example method <NUM> of maintaining object identifier of corresponding objects in a namespace of an edge storage system after decoupling of a transportable storage device on which the objects are stored from the edge storage system so that client device users can continue to "see" the object identifiers (e.g., data object names, etc.) linked with the objects while the transportable storage device is in transport. A storing operation <NUM> initially includes storing a data object in an edge storage system (e.g., ingesting data object <NUM> from client device <NUM> into data box edge <NUM> in <FIG>) and an object identifier inclusion operation <NUM> includes including an object identifier (e.g., a data object name) for the object in a namespace of the edge storage system (e.g., in namespace <NUM> of a data box edge <NUM> of <FIG>). As discussed herein, the various data box edges of an edge storage system of a customer data center may be configured to share all their respective namespaces and resolve duplicates in substantially real-time such that each data box edge has a substantially identical namespace.

A copying operation <NUM> includes copying the object to a transportable storage device (e.g., data box pod <NUM> of <FIG>) that is communicatively coupled to the edge storage system and then a decoupling operation <NUM> includes communicatively decoupling the transportable storage device from the edge storage system. For example, the transportable storage device may be decoupled from the edge storage system and then physically transported to a cloud data center or the like for upload to a cloud storage system. In some implementations, data storage associated with the data object may be removed (e.g., deleted) from the edge storage system (e.g., before the decoupling operation <NUM>). As discussed herein, situations exist in which particular data is only available on a single data box pod <NUM> (e.g., the data has been removed from its corresponding data box edge <NUM>) which is subsequently communicatively decoupled from its data box edge <NUM> and has not yet reached the cloud data center for upload to the cloud storage system. In this case, the UID <NUM> for the data on the data box pod remains in the namespace <NUM> of the data box edge <NUM> so that client devices can see that the corresponding data exists (in contrast to other systems where data on a transportable device in transit is essentially invisible to client devices until the transportable device has been uploaded to a cloud storage system). However, manipulation of the UID <NUM> in the namespace <NUM> before uploading of the data to the cloud storage system induces the data box edge <NUM> to return a "data temporarily unavailable" message or the like to the user. In this regard, the UID <NUM> serves as a data "stub" while the data box pod <NUM> is in transit. Once the data has been uploaded to the cloud storage system, manipulation of the corresponding UID <NUM> in the namespace <NUM> induces the data box edge <NUM> to download the corresponding data from the cloud storage system and serve the data to the client device.

At this point, the data object is considered "ghosted" from the edge storage system (e.g., from the data box edge from which the transportable storage device was just communicatively decoupled) but the data object is still "stubbed" in the namespace (via its corresponding object identifier) to maintain visibility of the object identifier in the namespace. A query operation <NUM> then asks whether a request for an object identifier of the data object in a namespace of the edge storage system has been received. If not, the query operation <NUM> is performed again. Otherwise, a query operation <NUM> asks whether the data object corresponding to the requested object identifier has been uploaded into the cloud storage system. If not, a return message operation <NUM> includes returning an unavailability message to the requester (e.g., indicating that the object is temporarily unavailable). If the answer to the query operation <NUM> is positive, then a downloading operation <NUM> includes downloading a copy of the data object from the cloud storage system to the edge storage system.

In one arrangement, additional transportable storage devices may be communicatively coupled to the edge storage system, and additional data objects may be stored from the edge storage system to such additional transportable storage device(s). In this case, such additional data objects would be identified by additional object identifiers which are maintained in the namespace of the edge storage system after subsequent communicative decoupling of such additional transportable storage device(s).

In one implementation, pod identifiers (e.g., pod id <NUM> in <FIG>) may be cleared from the metabase of the data box edge upon upload of the object(s) to the cloud storage system so that future attempts to read the object(s) from the particular pod/transportable storage device are not made. For example, the cloud storage system may generate and send any appropriate communication regarding the upload to the customer data center to initiate such cleaning up of the metabases of the data box edges. In one implementation, multiple copies of objects may be stored on multiple pods of a corresponding data box edge to allow reads of an object stored on a transportable storage device is transit to be serviced by another transportable storage device that is still communicatively coupled to the data box edge. Upon upload of the objects on the in-transit device to the cloud storage system, the cloud storage system can message the edge storage system regarding the same to thereby trigger cleaning of the corresponding object copies from the remaining transportable storage devices. In one implementation, the cloud data center may maintain a metabase of metadata (e.g., dbit, dbut, etag, etc.) regarding the data stored in the cloud storage system. In this regard, data box edges would update the metabase when uploading objects directly to the cloud storage system.

Data box edges can copy full files/blobs to one or more of its data box pods. In the case where a user desires to modify a file/blob on a data box edge that has already been ghosted from the data box edge to a data box pod or cloud storage system, the file/blob is first pulled down to the data box edge from the data box pod or cloud storage system, modified as necessary, and then recopied to the data box pod (and/or another of its data box pods) in its entirety. In the case where the only copy of the file/blob is on an in-transit data box edge, the pulling down would have to wait until the file/blob on the in-transit data box edge reaches the cloud storage system. It is noted that multiple data box edges may be largely disconnected from the internet for long periods of time while ingesting data from different clients (e.g., at different data centers or submarines). One or more of the data box edges may periodically copy or write objects to data box pods and/or upload objects to the cloud storage system and the technologies disclosed herein synchronize objects and identify conflicts among multiple versions of objects.

<FIG> illustrates an example computing device <NUM> for use in synchronizing online and offline transfer of data to a cloud storage system. The example computing device <NUM> may be used to determine whether objects should be uploaded from an edge storage system or transportable storage device to a cloud storage system in a manner ensuring that the most recent versions of objects are the versions stored in the cloud storage system while older versions are deleted or archived, even when multiple versions of objects are in various locations in a system and arriving at the cloud storage system for potential upload and various times. The computing device <NUM> may be a client device, such as a laptop, mobile device, desktop, tablet, or a server/cloud device. The computing device <NUM> includes one or more processor(s) <NUM>, and a memory <NUM>. The memory <NUM> generally includes both volatile memory (e.g., RAM) and non-volatile memory (e.g., flash memory). An operating system <NUM> resides in the memory <NUM> and is executed by the processor(s) <NUM>.

In an example computing device <NUM>, as shown in <FIG>, one or more modules or segments, such as an object upload module <NUM> (e.g., object upload modules <NUM>, <NUM> of <FIG>), edge storage system <NUM> (e.g., associated with data box edge <NUM> of <FIG> for use in maintaining the namespace <NUM>), applications, application modules, and other modules, are loaded into the operating system <NUM> on the memory <NUM> and/or storage <NUM> and installed in and executed by the object upload module <NUM> and/or other processor(s) <NUM>. The object upload module <NUM> also includes memory for storing data, metadata, objects, and/or other secured data. The storage <NUM> may be local to the computing device <NUM> or may be remote and communicatively connected to the computing device <NUM> and may include another server. The storage <NUM> may store resources that are requestable by client devices (not shown).

The computing device <NUM> includes a power supply <NUM>, which is powered by one or more batteries or other power sources and which provides power to other components of the computing device <NUM>. The power supply <NUM> may also be connected to an external power source that overrides or recharges the built-in batteries or other power sources.

The computing device <NUM> may include one or more communication transceivers <NUM> which may be connected to one or more antenna(s) <NUM> to provide network connectivity (e.g., mobile phone network, Wi-Fi®, Bluetooth®) to one or more other servers and/or client devices (e.g., mobile devices, desktop computers, or laptop computers). The computing device <NUM> may further include a network adapter <NUM>, which is a type of communication device. The computing device <NUM> may use the adapter and any other types of communication devices for establishing connections over a wide-area network (WAN) or local-area network (LAN). It should be appreciated that the network connections shown are exemplary and that other communications devices and means for establishing a communications link between the computing device <NUM> and other devices may be used.

The computing device <NUM> may include one or more input devices <NUM> such that a user may enter commands and information (e.g., a keyboard or mouse). These and other input devices may be coupled to the server by one or more interfaces <NUM> such as a serial port interface, parallel port, or universal serial bus (USB). The computing device <NUM> may further include a display <NUM>, such as a touch screen display.

The computing device <NUM> may include a variety of tangible processor-readable storage media and intangible processor-readable communication signals. Tangible processor-readable storage can be embodied by any available media that can be accessed by the computing device <NUM> and includes both volatile and nonvolatile storage media, removable and non-removable storage media. Tangible processor-readable storage media excludes intangible communications signals and includes volatile and nonvolatile, removable and non-removable storage media implemented in any method or technology for storage of information such as processor-readable instructions, data structures, program modules or other data. Tangible processor-readable storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CDROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible medium which can be used to store the desired information and which can be accessed by the computing device <NUM>. In contrast to tangible processor-readable storage media, intangible processor-readable communication signals may embody processor-readable instructions, data structures, program modules or other data resident in a modulated data signal, such as a carrier wave or other signal transport mechanism. By way of example, and not limitation, intangible communication signals include signals traveling through wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media.

Ascertaining further includes ascertaining that a last cloud modified timestamp for the object ID stored in the object database is more recent than a last cloud upload timestamp for the object ID stored in the object database.

Another example method of any preceding method may be provided, wherein the allowing includes replacing, with the data in the received object, data in the cloud storage system associated with the object ID and replacing, with the metadata in the received object, metadata in the database associated with the object ID.

Replacing the metadata may include replacing, with the ingest timestamp of the received object, the ingest timestamp for the object ID stored in the object database and replacing, with an entity tag in the received object, an entity tag for the object ID stored in the object database.

The method may further include allowing upload of at least a portion of the received object into the cloud storage system responsive to the a) object ID being determined to not exist in the object database or b) the object ID being determined to exist in the object database and an entity tag for the object ID stored in the object database matching an entity tag of the received object.

Some implementations may comprise one or more example tangible processor-readable storage media embodied with instructions for executing on one or more processors and circuits of a device a process for use with a cloud storage system. The process includes receiving, at a cloud upload module from a storage device, an object that includes data and metadata. The metadata includes an object ID and an ingest timestamp corresponding to a time that the data was ingested into the storage device. The process further includes determining whether the object ID exists in an object database of objects stored in the cloud storage system and determining a conflict status regarding uploading of the received object into the cloud storage system based on the ingest timestamp of the received object, responsive to the object ID being determined to exist in the object database.

One or more other example tangible processor-readable storage media of any preceding media are provided, wherein the operation of determining a conflict status includes ascertaining that an ingest timestamp for the object ID stored in the object database is more recent than the ingest timestamp of the received object, determining that the conflict status is that a conflict exists between the received object and an existing object in the cloud storage system responsive to the ascertaining, and disallowing upload of the received object into the cloud storage system responsive to the determined conflict status.

One or more other example tangible processor-readable storage media of any preceding media are provided, wherein the ascertaining further includes ascertaining that a last cloud modified timestamp for the object ID stored in the object database is more recent than a last cloud upload timestamp for the object ID stored in the object database.

One or more other example tangible processor-readable storage media of any preceding media are provided, wherein the operation of determining a conflict status includes ascertaining that the ingest timestamp of the received object is more recent than an ingest timestamp for the object ID stored in the object database, determining that the conflict status is that a conflict does not exist between the received object and an existing object in the cloud storage system responsive to the ascertaining, and allowing upload of the received object into the cloud storage system responsive to the determined conflict status.

One or more other example tangible processor-readable storage media of any preceding media are provided, wherein the ascertaining further includes ascertaining that a last cloud upload timestamp for the object ID stored in the object database is more recent than a last cloud modified timestamp for the object ID stored in the object database.

One or more other example tangible processor-readable storage media of any preceding media are provided, wherein the allowing upload of the received object into the cloud storage system after the ascertaining includes replacing, with the data in the received object, data in the cloud storage system associated with the object ID and replacing, with the metadata in the received object, metadata in the database associated with the object ID.

One or more other example tangible processor-readable storage media of any preceding media are provided, wherein the replacing the metadata includes replacing, with the ingest timestamp of the received object, the ingest timestamp for the object ID stored in the object database and replacing, with an entity tag in the received object, an entity tag for the object ID stored in the object database.

The conflict manager may be configured to determine the conflict status by ascertaining that a last storage system modified timestamp for the object ID stored in the storage system is more recent than a last storage system upload timestamp for the object ID stored in the cloud storage system.

The conflict manager may be configured to determine the conflict status by ascertaining that a last storage system upload timestamp for the object ID stored in the storage system is more recent than a last cloud modified timestamp for the object ID stored in the storage system.

Another system for use with a cloud storage system may be provided. The system may include means for receiving, at a cloud upload module from a storage device, an object that includes data and metadata. The metadata includes an object ID and an ingest timestamp corresponding to a time that the data was ingested into the storage device. The method further includes means for determining whether the object ID exists in an object database of objects stored in the cloud storage system and means for determining a conflict status regarding uploading of the received object into the cloud storage system based on the ingest timestamp of the received object, responsive to the object ID being determined to exist in the object database.

Another system may be provided, wherein the means for determining a conflict status includes means for ascertaining that an ingest timestamp for the object ID stored in the object database is more recent than the ingest timestamp of the received object, means for determining that the conflict status is that a conflict exists between the received object and an existing object in the cloud storage system responsive to the ascertaining, and means for disallowing upload of the received object into the cloud storage system responsive to the determined conflict status.

Another system may be provided, wherein the means for ascertaining further includes means for ascertaining that a last cloud modified timestamp for the object ID stored in the object database is more recent than a last cloud upload timestamp for the object ID stored in the object database.

Another system may be provided, wherein the means for determining a conflict status includes means for ascertaining that the ingest timestamp of the received object is more recent than an ingest timestamp for the object ID stored in the object database, means for determining that the conflict status is that a conflict does not exist between the received object and an existing object in the cloud storage system responsive to the ascertaining, and means for allowing upload of the received object into the cloud storage system responsive to the determined conflict status.

Another system may be provided, wherein the means for ascertaining further includes means for ascertaining that a last cloud upload timestamp for the object ID stored in the object database is more recent than a last cloud modified timestamp for the object ID stored in the object database.

Another system may be provided, wherein the means for allowing includes means for replacing, with the data in the received object, data in the cloud storage system associated with the object ID and means for replacing, with the metadata in the received object, metadata in the database associated with the object ID.

Another system may be provided, wherein the means for replacing the metadata includes means for replacing, with the ingest timestamp of the received object, the ingest timestamp for the object ID stored in the object database and replacing, with an entity tag in the received object, an entity tag for the object ID stored in the object database.

Another system may further include means for allowing upload of at least a portion of the received object into the cloud storage system responsive to the a) object ID being determined to not exist in the object database or b) the object ID being determined to exist in the object database and an entity tag for the object ID stored in the object database matching an entity tag of the received object.

Some implementations may comprise an article of manufacture. An article of manufacture may comprise a tangible storage medium to store logic. Examples of a storage medium may include one or more types of computer-readable storage media capable of storing electronic data, including volatile memory or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writeable or rewriteable memory, and so forth. Examples of the logic may include various software elements, such as software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, operation segments, methods, procedures, software interfaces, application program interfaces (API), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. In one implementation, for example, an article of manufacture may store executable computer program instructions that, when executed by a computer, cause the computer to perform methods and/or operations in accordance with the described embodiments. The executable computer program instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, and the like. The executable computer program instructions may be implemented according to a predefined computer language, manner or syntax, for instructing a computer to perform a certain operation segment. The instructions may be implemented using any suitable high-level, low-level, object-oriented, visual, compiled and/or interpreted programming language.

Claim 1:
A method (<NUM>) for use with a cloud storage system (<NUM>), the method (<NUM>) comprising:
receiving (<NUM>), at a cloud upload module (<NUM>) from a storage device (<NUM>, <NUM>), an object (<NUM>) that includes data and metadata, the metadata including an object ID (<NUM>) and an ingest timestamp (<NUM>), the object ID (<NUM>) uniquely identifying the data, the ingest timestamp (<NUM>) corresponding to a time that the data was ingested into the storage device (<NUM>, <NUM>);
determining (<NUM>) whether the object ID (<NUM>) exists in an object database of objects (<NUM>) stored in the cloud storage system (<NUM>); the method being characterized in that it comprises:
determining (<NUM>) a conflict status regarding uploading of the received object (<NUM>) into the cloud storage system (<NUM>) based on the ingest timestamp (<NUM>) of the received object (<NUM>), responsive to the object ID (<NUM>) being determined to exist in the object database;
wherein the operation of determining a conflict status includes:
ascertaining (<NUM>) that an ingest timestamp (<NUM>) for the object ID (<NUM>) stored in the object database is more recent than the ingest timestamp (<NUM>) of the received object (<NUM>),
determining that the conflict status is that a conflict exists between the received object (<NUM>) and an existing object (<NUM>) in the cloud storage system (<NUM>) responsive to the ascertaining, and
disallowing (<NUM>) upload of the received object (<NUM>) into the cloud storage system (<NUM>) responsive to the determined conflict status;
and
wherein the operation of determining a conflict status includes:
ascertaining (<NUM>) that the ingest timestamp (<NUM>) of the received object (<NUM>) is more recent than an ingest timestamp (<NUM>) for the object ID (<NUM>) stored in the object database,
determining that the conflict status is that a conflict does not exist between the received object (<NUM>) and an existing object (<NUM>) in the cloud storage system (<NUM>) responsive to the ascertaining, and
allowing (<NUM>) upload of the received object (<NUM>) into the cloud storage system (<NUM>) responsive to the determined conflict status.