Difference between revisions of "Disaster Recovery"
(→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.