A file/dataset/snapshot might be in cache, it might be in transit, or it might be in the cloud. Inside of the CloudArray appliance, files are broken into encrypted chunks as they're initially written, then as the cache fills, they're sent to providers, first-in/first-out. As things move back and forth, tabulation is stored in the CloudArray portal. We could look things up to see what was where.
There are ways of predicting where any specific file, folder or snapshot of information might be, and we used this as a comparative method for speed of restoration, as speed of backup is what one might expect of an iSCSI interface or CIFS share -- captive to the speed of the local connection pathway. In our case, the pathway was Gigabit Ethernet as piped through our host. The CloudArray portal keeps track of what's where, allowing a replacement CloudArray appliance to be brought online remotely should a primary appliance become unavailable.
We saved configuration information, killed the appliance, and it restored into a newly created appliance correctly. Although we could lose a bit if information if we crashed the appliance, the cloud services provider used retained intact information. Backup session typically ran at 5MBps. Restorations where we knew we were pulling the data from the cloud, were typically retrieved at less than half that speed. Our circuit-speed, however, will be different than your circuit-speed.
In the use case where the appliance is used for high-availability/disaster recovery, there is danger of having a large local cache set in the appliance, which might become unavailable for whatever reasons. Local cache, although forwarded to the cloud service provider somewhat quickly, is still an unknown synchronization point; the last completed job is what's now available to restore into a hot-site or another CloudArray appliance on a network -- the survivor, we'll call it. More cache means potentially more data in a transient state that can't be restored, so we suggest using smaller datasets rather than large ones with large cache if HA/DR is of concern. The bigger the chunk of data in cache you store locally, the more you can lose locally and cannot subsequently restore.
The appliance is a closed host and is shutdown from external examination. We can tell what's inside the appliance by poking it, but you can't get a shell to go inside and fix something. We could download plentiful logs, but could not go inside and fix things. This may or may not have security implications for organizations.
It's possible to have an accumulation of dead files in the cloud service provider's storage, because deletion of objects from CloudArray doesn't necessarily walk up the circuit to the provider's store and delete them or purge them. We were told that external utilities must be used to delete from iSCSI stores, but CIFS stores should be deleted immediately and we verified this.
Sign up for Computerworld eNewsletters.