Which Backup and Recovery solution is providing the best Copy Data Management (CDM)/virtual copy of a database?

Testing your disaster recovery plan is crucial to ensure that your organization is prepared to minimize downtime in the event of a disaster. Here are some steps you can take to test your disaster recovery plan: Define Test Scenarios: Define test scenarios that simulate real-world disaster scenarios. These scenarios should be designed to test specific aspects of your disaster recovery plan, such as data recovery, network failover, and application availability. Involve All Relevant Parties: Involve all relevant parties in the testing process, including IT staff, business unit leaders, and third-party vendors. This will help to ensure that everyone is on the same page and understands their role in the event of a disaster. Document Test Results: Document the results of each test scenario, including any issues or areas for improvement. This will help you to refine your disaster recovery plan and ensure that it's as effective as possible. Test Regularly: Test your disaster recovery plan on a regular basis, such as quarterly or bi-annually. This will help to ensure that your plan remains up-to-date and effective in the face of evolving threats and technologies. Automate Where Possible: Automate as much of the testing process as possible, such as data replication, failover, and recovery. This will help to minimize the risk of human error and improve the overall efficiency of your disaster recovery plan. By following these steps, you can test your disaster recovery plan to work on minimizing downtime and ensure that your organization is prepared to quickly recover from a disaster.

The key to recovery from a Ransomware attack is the boy scout motto "Be Prepared".  In our case, not only did we have backups at the DR site but both the Production site and DR site each had a NAS on a different subnet with different Admin passwords that had backup copies, so 4 total backups. We also were using iSCSI connections to our SAN which the ransomware was not able to cross when they polluted the connection file. This was an unexpected bonus. We were basically back up and running in 4 hours after wiping and restoring files. Lessons learned were to separate as much as possible so if one part of the domain/forest gets corrupted it cannot travel to the other areas. We now use Veeam for Hyper-V windows VMs and Zerto for VMware VMs, another separation of business functions with different admin passwords. Nothing is foolproof but by making it as difficult as possible then makes more time to catch and stop the attack sooner.

@Chris Childerhose, @PraveenKambhampati, @Deena Nouril, @Shibu Babuchandran and @reviewer1925439, Thank you for contributing your articles and sharing your professional knowledge with 618K PeerSpot community members around the globe as well as with a much bigger readers audience!