June 11, 2015 at 9:25 am
Hi All,
We are under process to setup a BCDR solution for a .and trying to figureout various options like SQL server alwayson, and Zerto. Please provide your experience if any body used Zerto Virtual replication for their SQL Server. We came to know that By using this ,we can achiever point in time recovery for last five days.
Also For BCDR , zerto replication solution more viable then SQL server always as this reduces the SQL server licensing cost.
June 12, 2015 at 2:30 pm
The company I'm at has been using Zerto for over two years and we're protecting over 20TB of SQL data with Zerto replication. Taking change rates and bandwidth into consideration, Zerto is an excellent solution. The only time I've run into an issue is when we had a server with 150GB of changed data to replicate over a 100Mbps connection. We've done multiple DR tests and 1 actual fail over and recovered SQL servers with no database restores required. Zerto replication is incredibly easy to setup and manage so I highly encourage you to setup and evaluation and give it a look.
June 13, 2015 at 1:15 am
We're also using Zerto to protect a number of SQL Databases (and application servers).
It's easy to setup, easy to monitor, and easy to test.
Also storage agnostic, so no need to have same hardware in Prod and DR.
Andrew
June 18, 2015 at 2:23 pm
We have been successfully protecting a number of SQL servers with Zerto for a couple of years now. It never misses a beat and is always available and recoverable so I would highly recommend it.
July 29, 2015 at 8:46 am
Zerto will help you recover entire VM with all instances inside it.
Just, take in mind that consistency is a high level process, so, a pre-checkpoint script will be needed to ensure App and Data level consistency.
This script is sent by Zerto automatically to SQL VM.
August 2, 2015 at 9:15 pm
We use Zerto to protect to production SQL servers. We have done recovery testing and found no issues and the sql data was current as of 15 seconds before starting the test failover. The product is solid and you do not have to worry about the test data mixing with your production data.
September 11, 2015 at 8:36 am
Just looking at using Zerto, as its disk block level based it concerns me a little.
How does Zerto manage ACID properties?
What does it do to remain Transactionally consistent ?
September 28, 2015 at 1:47 am
If you place all VMs in an app stack into a Zerto VPG (virtual protection group) it will ensure write order fidelity across all VMs. This of course means you probably need to have a SQL DB server dedicated to that app only. It doesn't replicate memory though - the only way to truly deal with complete consistency is to actually shut down your VMs, and then back them up, and not many of us can do that. Zerto at least gives you lots of PIT capabilities and one of those is pretty certain to be consistent.
September 28, 2015 at 1:48 am
......one thing I'd like to know, is whether those on this post that protect SQL with Zerto....
1. .... use AAG or share disk clusters?
2. .... if you use AAG, do you protect all VMs in the group, or just the primary?
Thanks
October 5, 2015 at 7:38 am
Hi Mike,
just wondered if you replicate one or both SQL AAG VMs with Zerto?
Thanks
October 5, 2015 at 10:44 am
I noticed that all the people posting their experience with Zerto were very new users to this site. It would be good if some of the long-standing users of this site who have also used Zerto could give their experience, as it would give more depth to the discussion.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
October 5, 2015 at 11:17 am
Regarding SQL AGs, it is SQL Server that replicates data between servers, so no additional software is needed. They also give near-instantaneous failover.
Other solutions that do the replication for you and give near-instantaneous failover are database mirroring and replication (especially P2P replication).
Any solution that needs the SQL databases to be brought online during failover will have a measurable failover time, caused by SQL Server having to perform consistency checking on the database. For large databases (over, say, 100GB) this can be many minutes.
Choosing a DR solution is not purely a technical challenge. You need to know what the business expects and is willing to pay for regarding Recovery Time Objective (RTO) and Recovery Point (RPO), or how up-to-date is the recovered data and how quickly will it be available. When you know these then some options can be quickly discarded as they do not meet RTO or RPO or exceed desired cost, leaving the technologist to look at the costs, risks, and manageability of the remaining options.
A big challenge for new products that help in DR is business risk. Vendors need a track record of a few major releases to mitigate the risk they will have ceased trading in a year or so. Vendors also need a track record of reference customers who are willing to share their experience, to mitigate the risk the product cannot deal with common problems such as network disconnect and power loss, etc. New products drive the market forward by challenging orthodoxy and cost models, but becoming an established success is not easy for a vendor to achieve.
When you have your DR strategy it needs to be regularly tested. An organisation I worked for up to 2007 failed over between London and New York on a weekly basis. Once a week may be more than you need, but less than once every 4 months means you are not taking DR seriously - staff will be stale on each DR and normal code churn will mean each DR will show up new problems. When you get problems every failover this results in management being scared to authorise a failover because of the business risk, ending up with you having no working DR.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
December 29, 2020 at 11:52 pm
We are a mature organization with many AlwaysOn AGs and many standalone instances. We are trying Zerto to migrate SQL Servers to a new data center. Of the six lower-tier servers that we have tried so far, two had data corruption. When I asked our sysadmins to open a ticket with Zerto, they expressed reservations. They said hat Zerto tech support has beenless than stellar.
At this point it looks like we will be leveraging AlwaysOn to migrate the AGs and VMotion to move the standalone servers.
January 10, 2021 at 8:14 am
I am not familiar with the ZERTO product. I would agree "ALWAYS-ON" is a proven/effective replication technique. There is also transactional replication w/o log shipping. If you have small/medium size database, always-on may be too much.
DBASupport
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply