1. Best Practices for Alfresco Replication, Backup and Disaster Recovery Richard McKnight Principal Consultant Brian Long Principal Consultant

2. Agenda  About the Problem Space  Target Clients and Use Cases  Overview of Functionality  About our Implementation At the end of this presentation you should have enough information to make an informed decision about BC/DR and Global Replication

3. The Problem Space Moving data around the globe to support distributed teams and Business Continuity and Disaster Recovery (BC/DR)

4. What Problems are We Solving? BC/DR Ensuring continued operations after loss of use of a data center Resume operations as quickly as possible Have minimal loss of content when back up operations resume. Global Replication Global distribution of content around the globe Global collaboration around content. Control over where content is replicated These two distinct requirements come up often with larger customers.

5. Global Replication Challenges Global Replication ≠ WAN level HA Clustering  During outages trade-offs must be made between consistency and availability.  In global read/write use cases conflict resolution functionality must be implemented

6. BC/DR Requirements  Recovery Point Objective The time period for which missing data could be tolerated  Recovery Time Objective The length of time that the organization could tolerate a service interruption.

7. Common BC/DR #Fail #TransactionDBFile 1Add 10 filesCompletely Transferred10 files Transferred 2Add 100 more FilesCompletely Transferred99 Files transferred 3Update 20 ObjectsCompletely TransferredAll updates complete 4Delete 20 FilesCompletely TransferredN/A 5Add 10 more filesPartially Transferred7 Files transferred Quite often the initial instinct is to implement BC/DR as a continuous back up to a remote region. Transaction #5 would always be thrown out because the database would not commit a partial transaction. Because transaction #2 would be incomplete (due to missing files), it and all subsequent transactions would need to be discarded.

8. Who is Asking For This and Why? Reviewing types of customers asking for this and how they intend to use this.

9. Financial Services

10. Oil and Gas

11. General Disaster Recovery

12. Large Multi-national Corporations A couple of clients/prospects have asked about global collaboration  Multiple data centers around the globe (more than 10).  Specific replication policies for different collections of content.  Read write collaboration across the globe.  Control over how aggressively replication occurs between various regions

13. Functional Overview So what exactly have we created

14. Functional Requirements  A set of federated repositories.  The ability to create “distributed objects” that are replicated across a selected set of those repositories.  The ability to know the replication state of any object.  Repository specific access control.

15. Non Functional Requirements  Efficient Replication  Ability to control the progress of replication.  Resilience in the face of outages.  Cluster aware  The ability to add/delete new repositories in the federation

16. About our Implementation

17. Business Continuity

18. High Availability + BC

19. Disaster Recovery + HA/BC

20. Flexibility / Configurability Wide Range of Business Requirements Wide Range of Technical Requirements Segmented Multi-Stage Replication

21. Node Segments & Events Stub Property/Properties (non-content) Association(s) Access Control(s) Content(s) Etc… DeleteNode MoveNode DeleteAssociation InvalidateProperties InvalidateContents Etc…

22. Scheduling Options Synchronous Asynchronous Batch Including Previously Failed Actions On-Demand Typically for Content Never Typically for Invalidate Events

23. What is Distributable? Folders declared as Distribution Roots Configured by an Administrator All Children of Distribution Roots Ignored Aspects Renditions Thumbnails Etc…

24. Journal

25. Transport

26. Conflict Resolution Simple/Smart Merging by Default Supports Custom Implementations Spring Pluggable

27. Contact Information Richard McKnight richard.mcknight@alfresco.com @rmknightstar Brian Long brian.long@alfresco.com