Difference between revisions of "Disaster Recovery"

From LogicalDOC Community Wiki
Jump to navigationJump to search
(External procedure with Amazon S3)
(External procedure with Amazon S3)
Line 6: Line 6:
 
We try to develop a mirror procedure that takes care of put LogicalDOC resources to a specific Amazon S3 bucket using Java and the AWS SDK.
 
We try to develop a mirror procedure that takes care of put LogicalDOC resources to a specific Amazon S3 bucket using Java and the AWS SDK.
 
Here below there is a rough description of some important issues to understand when inspecting a single resource:
 
Here below there is a rough description of some important issues to understand when inspecting a single resource:
 +
 
1) If the resource is locally new, simply execute a PUT
 
1) If the resource is locally new, simply execute a PUT
 
   For each inspected folder a special cache file is created storing file name and MD5 hash
 
   For each inspected folder a special cache file is created storing file name and MD5 hash

Revision as of 21:19, 9 March 2011

The Aim: Mirroring LogicalDOC resources

As a DMS, LogicalDOC has to handle large amount of sensible and reserverd documents, from the user's perspective it is important to guarantee information resilience even after a server failure or in general a disaster that may involve the building or the geographical area. We also need a tool to quickly restore the data once the runtime environment becomes available after de fault. It is important to note that what is described here is NOT a backup, it just describes a mirroring system to be used to fast restore documents after a disaster.

External procedure with Amazon S3

We try to develop a mirror procedure that takes care of put LogicalDOC resources to a specific Amazon S3 bucket using Java and the AWS SDK. Here below there is a rough description of some important issues to understand when inspecting a single resource:

1) If the resource is locally new, simply execute a PUT

  For each inspected folder a special cache file is created storing file name and MD5 hash

2) If the resource was locally modified, execute a DELETE followed by a PUT (we don't want to handle versions)

  To check if a resource is modified it is enough to check the MD5 against the one in the cache file

3) If the resource was locally deleted, execute a DELETE

  To detect deletions we could use a special file in each folder enlisting the deleted resources. 
  If the deleted resource is a folder, all remote   elements inside this folder have to be deleted. 


The procedure will take all the configuration parameters from central context.properties and additional properties files.