Difference between revisions of "Disaster Recovery"

From LogicalDOC Community Wiki
Jump to navigationJump to search
(New page: == 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 i...)
 
(External procedure with Amazon S3)
Line 13: Line 13:
  
 
3) If the resource was locally deleted, execute a DELETE
 
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.  
+
   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.
 
The procedure will take all the configuration parameters from central context.properties and additional properties files.

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.