Additional Information

Detailed Architecture ( Hardware and Software)

Legend:   ------------ indicates Bidirectional nature of data flow over the ICT infrastructure ( both in the internal and the external network).

Detailed Backup Architecture (courtesy : http://www.oracle.com)

Figure below details the backup architecture that can be employed to support backup/restore services on multi tenant environments. It also shows how we can support these services on cross platform systems which run different clients like Windows/Linux/Solaris etc. and then store data on TapeDrives etc. This architecture is in essence similar to Figure 2 since it showcases all 3 layers, the vertical slice which runs the backup clients, the middleware services and the network connection and finally the storage which is connected through SAN.

More details about this topic (e.g., different models, definitions, approaches, etc)

Backup:  Persisting critical information not only on the local hard drive, but in the cloud( typically data centers) to ensure data is not lost in the face of anomalies such as lightning strikes or storms etc..

Replicate: Critical data such as Electronic Health Records / Banking Information needs to be replicated across multiple data centers to minimize the risk of a destroyed data center ( basically minimizing the possibility of Byzantine Failures) .To achieve this, blocks of storage should be replicated between data centers as well . Better to hedge the risk rather than putting all the eggs in the same basket.

Restore: In the event of data getting corrupted on the local hard drive / server, the data center could be reached out to restore the data from the cloud. We could have a primitive ‘restore’ which would take a timestamp and provide a list of all changes that have happened since that time, and also provide an updated view of the data for the institution to fall back on.

Billing: Since the ICT infrastructure provider needs to maintain and upgrade hardware (sometimes over tough terrain) it is imperative for the provider to charge the consumer of the backup/restore service some money in exchange. We propose different billing slabs for different types of consumers. Institutional customers would be charged more, whereas individual customers would have a different billing rate and also for NGO’s the rate of billing would be significantly lower.

UI: The service will come with a command line and a UI to enable the user to interact with the service and do activities like bill viewing/payment etc apart from performing the manual backup/restore functionality.

Different Models
 
Automatic Backup (Similar to Time Machine): In use cases where data backup is needed in real-time (Stock Exchange/Trading Data) or the data needs to be backed up at regular intervals( Electronic Health records/ Banking Data) we can tweak the intervals at which the backup service is called and batches of data are backed up. In such a scenario the backup service can run once every hour/day/week etc.

Manual Backup (On Demand Backup): In use cases where the vertical slice does not have mission critical data / data is static but important enough to be backed up ( say visa status/ criminal records ) can be backed up manually by hooking into the web service via a UI and selectively backing up data that the individual or organization or individual wants to replicate. The user could backup the data either through a UI interface/ command line, which would be provided as part of the backup/restore service.

Note: Depending on the size of the backup, either the payload could be embedded in the XML as shown above, else we could transfer the data over the wire in JSON, just to reduce the overhead/verbosity of XML.