Sify’s Synchronous Protect solutions offer a time tested, cost effective & reliable IT recovery solution with ‘Near Zero’ data loss that helps in responding with speed and agility while minimizing exposure during the downtime. The solutions are designed for core application with a custom recovery time.
This solution enables recovery of even the last transaction, in case of any disaster or disruption and comprises of business continuity consulting and IT disaster recovery custom solutions, designed with geographically distant (near and far) DR sites. Sify’s Synchronous Protect Solutions enables resumption of the business operations within the pre-determined period.
The Synchronous Protect Solutions are custom built by our recovery architects on cloudInfinit or dedicated setups, which results in protecting critical data and minimize the loss, due to disruption.
|Continuity of Critical systems||Custom solutions with ‘Near zero’ data loss due to an unplanned disruption: the solution enables a recovery of the critical applications as per the business objectives|
|Comprehensive proposition||Strong integrated comprehensive proposition with synchronous & asynchronous replication along with hosting, server infrastructure, storage infrastructure network, OS, DB, applications managed services, BCP consulting to build a strong DR plan|
|Multi tier Integrated Scalable Infrastructure||Near site DR – ready to deploy, pay as you use infrastructure. Far site DR - ready to use, scalable, customizable integrated architectures across compute, storage, network, security and connectivity for deploying multi-tier applications on a virtual or dedicated server|
|Custom Solutions||Comprehensive custom solutions covering hosting, infrastructure, BCP consulting, network & managed services, providing an end to end integrated solution - application recovery, Infrastructure recovery and an end user access, using tools from VMware, Sanovi and Symantec|
|On demand DR compute & storage resources||Custom deployment on either reserved DR instance or provisioned DR instance with minimal resources during NON DR time, scalable to handle full load at the time of the disaster, resulting in a lower TCO Pay for storage only for the data capacity which you currently have & increase as and when the data grows|
|Reporting||Monthly reporting of data replicated, infrastructure utilized, network reports, RPO / RTO status, alerts and notifications|
|Right Sized Solutions||Right sized custom solutions on Enterprise Cloud / Dedicated Infrastructure, with best in class components, meeting business requirements|
Sify’s Synchronous Protect solution offers a custom built, cost effective, timely Tested, comprehensive solutions for your core applications across Hosting, Infrastructure, Operating systems, Database, Applications, Network services & managed services, with an RPO of near Zero and Customized RTO as per the business objectives.
The solutions are offered on our enterprise cloud platform or on a dedicated environment at our Tier III+ datacenters in Mumbai and Bangalore DC.
To know more about the prices, please click on “Have us call you” or email us at firstname.lastname@example.org
Sify Synchronous Protect service offers a custom built, cost effective, timely tested, comprehensive solutions for critical applications with RPO of near zero and custom RTO as per your Business needs in Sify DC at Mumbai and Bangalore. The service is Custom built and integrated across the entire chain – infrastructure, hosting, network, OS, DB, applications etc. The solutions enable you to have
Synchronous Protect solution enables setting up a synchronous protect infrastructure and negates financial impacts due to downtime, protects your critical data and improves the employee productivity, Sify works with the customers in devising a Synchronous Protect plan with the detailed task list as below:
If the primary site fails, the DR site needs to take over. However, the DR site may be behind the primary. That is, there may be some writes that are completed to the application but that have not reached the DR site data volumes; these writes are stored in the replicator Log on the near DR Site.
To recover from a disaster on the Primary, you can use the REPLICATION LOG on the near DR site to update the far DR site. You activate the near DR Site, which converts it to the primary role, and then the near DR site can replay the pending writes from the near DR Site REPLICATION LOG to the far DR site.
The procedure is similar whether the near DR site setup uses the IP protocol or uses direct storage near DR site replication enables you to balance the Recovery Point Objective (RPO) with the Recovery Time Objective (RTO) depending on your needs. In the case of a disaster, completely replaying the Near DR Site REPLICATION LOG to the DR site provides zero RPO.
However, the RTO depends on the time required to replicate pending writes from the near DR site REPLICATION LOG to the DR site. If the DR site is far behind the primary at the time of the disaster, the RTO could be large.
After all of the pending writes are transferred to the far DR site, the DR site is as up-to-date as the primary. In normal circumstances, if the entire REPLICATION LOG is replayed, the Far DR site can take over the role of the primary with no data loss. However, in certain failure conditions, the Near DR Site might not be able to bring the DR site exactly up-to-date with the primary. For example, if the LINK between the primary and the near DR Site was disconnected prior to the failure at the primary.
Near DR Site replication enables you to balance the Recovery Point Objective (RPO) with the Recovery Time Objective (RTO) depending on your needs. In the case of a disaster, completely replaying the Near DR Site REPLICATOR LOG to the DR site provides zero RPO. However, the RTO depends on the time required to replicate pending writes from the Near DR Site REPLICATOR LOG to the DR site. If the Far DR site is far behind the Primary at the time of the disaster, the RTO could be large.
Using Near DR Site replication, you can stop the replay after a period of time to recover as much data as possible within a target RTO. For example, if your DR site is 2 hours behind the Primary, you can replay the full Near DR Site REPLICATOR LOG to achieve zero RPO but the RTO would then be about 2 hours. If your target RTO is 1 hour, you could begin Near DR Site replay and then stop the replay after 1 hour.
If you need the application to be immediately available (RTO is zero), you can perform a normal DR site takeover, without replaying the Near DR Site at all. However, in this case, the pending writes in the Near DR site REPLICATOR LOG are lost. In order to use the Near DR Site REPLICATOR LOG to update the DR site, you must replay the Near DR Site before performing takeover on the Far DR site.
The Near DR Site can act in the DR site role, to receive updates from the Primary, or it can act in the Primary role, to send updates to the DR site during replay. However, it cannot perform both roles at the same time and therefore does not serve as a relay between a Primary and another DR site.
After the DR site has been updated (either the Near DR Site replay has completed or the target RTO is reached and the Near DR Site replay has been stopped), the DR site can take over the role of the original Primary. The Near DR Site for the original Primary cannot be used as a Near DR Site for the original DR site. Therefore, another suitable host near the new Primary can be configured as a Near DR Site for the new Primary
|Event||Primary Site: What Happens||Near DR Site: What Happens||Far DR Site: What Happens|
|Server Failure at Primary Site||The Cluster software fails over the application to the clustered server and the data replication continues||No action on Near DR Site. Data replication resumes once the cluster failover has been completed||No Action on the Far DR Site. Data replication resumes once the cluster failover has been completed|
|Storage Failure at Primary Site||The application is stopped at Primary Site||Near DR Site sends incremental data to Far DR site to bring Far DR site to zero RPO state||Application is started at Far DR site and once the original Primary comeback , a fast failback mechanism is used to sent incremental data back to Primary Site|
|Storage failure at Near DRSite Site||No replication to Near DR Site and application remains online without any outage||Once the storage is back in service again, it incrementally refreshes the data from Primary Site. The refresh of data copies only the data which has got changed at Primary Site||No impact. Data replication continues from Primary Site|
|Storage Failure at DR Site||No action, External tools can store data as Log files||No impact||Once the storage is back in service again, it incrementally refreshes the data from the Primary site|
|Link Failure between Primary and Near DR Site||Stops the replication to Near DR Site and application remains online without any outage||Once the network is back in service again, it incrementally refreshes the data from Primary Site. The refresh of data copies only the data which has got changed at Primary Site||No impact. Data replication continues from Primary Site|
|Link Failure between Primary and DR Site||Replication to Near DR Site continues without interruption. External tools store data as Log files||No impact||Once the network is back in service again, it incrementally refreshes the data from the primary site Log files. External tools automate the resynchronization|
|Failure of Entire Primary Site||Site is unavailable||Differential data is sent from Near DR Site to Far DR site to ensure zero RPO at DR Site||Application can be started from the DR Site and once the original Primary comeback, a fast failback mechanism is used to sent incremental data back to Primary Site|
|Failure of Entire Near DR Site||The replication to Near DR Site is stopped and application remains online without any outage. Once the Near DR Site is back in service only incremental data is refreshed.||Site is unavailable||No impact. Data replication continues from Primary Site|
|Failure of Entire DR Site||Replication to the DR site is stopped. External tools store the data as Log files.||No impact||Once the network is back in service again, it incrementally refreshes the data from the primary site Log files. External tools automate the resynchronization|
Sify’s Synchronous Protect Solution enables setting up a Synchronous Protect infrastructure and negates financial impacts due to downtime, protects your critical data and improves the employee productivity, Sify works with the customers in devising a Synchronous Protect plan with the detailed task list as below:
The ongoing support specific to synchronous Protect managed service would comprise of the below support.
To explore more on plan & packages for subscription or for trial of services – Login to cloudinfinit portal now