We continually get inquiries from our Customers and Partners as to how solutions from Syntergy can assist them in the areas of Disaster Recovery (DR), High Availability (HA) and Continuity of Operations (COOP) for their On-Premise or IaaS-based (OpenText Cloud, Azure, Amazon, etc.) Content Server environments. The common themes we see in our customer’s Content Server deployments include: As a result, the business users of Content Server are now defining Service Level Agreements (SLAs) with IT departments that require: RTO = Recovery Time Objective The recovery time objective (RTO) is the duration of time and a service level within which a business process must be restored after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity. RPO = Recover Point Objective A recovery point objective (RPO) is defined by business continuity planning. It is the maximum tolerable period in which data might be lost from an IT service due to a major incident. The RPO gives systems designers a limit to work to. For instance, if the RPO is set to four hours, then in practice, offsite mirrored backups must be continuously maintained and a daily offsite backup on tape will not suffice. Care must be taken to avoid two common mistakes around the use and definition of RPO. Historically for the earlier implementations of Content Server, for unplanned outages, the RPO (amount of data loss) time has been 24 hours and a range of 24 to 72 hours for RTO (how long it will take to recover Content Server). For planned Content Server outages e.g. rolling system software upgrades to Windows, SQL Server, Content Server and software integration the RTO historically has been anything from 12-24 hours. This is now a dilemma for IT departments and many organizations are not meeting their defined SLAs and COOP requirements. This is impacting the organization’s business from a cost perspective – loss of revenue, compliance, risk management issues and time consuming or failed DR Audit exercises. Industry “experts” continue to recommend the traditional out-of-the-box (OOTB) methods or “Active/Passive” solutions which are either Windows Server or database based (e.g. SQL Server) and not Content Server based. There are limitations with these approaches and they are not meeting most organizations Content Server SLAs. In our opinion, with traditional OOTB methods, VM replication is the best way to keep a clone of your Content Server. However, there are limitations with the traditional OOTB solutions: Syntergy Recommendations for a Complete Continuity of Operations Environment Content Server operates at distinct layers, each with their own operational requirements. When planning for a complete DR/HA strategy for your Content Server environment, our recommendations would be to have redundancy built in your production system as a first line of defense (e.g. multiple WFE’s, RAID etc.). Also have a redundant database as part of this architecture where you can have two SQL servers and multiple WFE’s all ready and waiting to be used in case a layer fails. WFE’s are also easy to point to a different database. Because of the limitations inherent in Content Server high availability options, IT Departments are now demanding and implementing application-layer replication technologies such as the Syntergy Replicator to achieve their Content Server SLAs. These technologies operate at the Content Server application program interface (API) level to provide a complete Content Server view and better capabilities to simplify the recovery process – looking for new documents and content within a Content Server library, and then sending that content to another active server in a different location. Every time a document is added or modified in Content Server, a copy of that document is then replicated to the multiple servers within the organization. As these technologies replicate at the application level, there is no risk of corrupting your secondary servers. Application based replication such as Syntergy Replicator work on individual content and have the advantage that the standby Content Server is continuously in recovery mode, so in case of a planned or un-planned outage it is very easy and fast to enable the standby Content Server as the new primary. Once your primary is back up and running, all the incremental changes in your secondary server are automatically queued back to the primary server. Our customers who deploy the Syntergy Replicator to meet their SLAs have the following goals: