\u00a0<\/span><\/li>\n<\/ul>\n <\/p>\n
How to get started with disaster recovery testing<\/strong><\/p>\nIn any disaster recovery plan, the cardinal rule, of course, is to make sure that your backups are taking place and protecting prioritized applications and data in the first place. Once you\u2019ve verified that, focus on the following steps.<\/span>\u00a0<\/span><\/p>\n <\/p>\n
Prioritize system recovery\u00a0<\/strong><\/p>\nAn important part of a disaster recovery plan is figuring out which systems in an organization are the most important to protect and recover. It\u2019s not possible to treat all the systems in your business the same, so you\u2019ll need to classify your systems by importance. The result is a hierarchy of systems, starting with the must-haves necessary for business continuity after a disaster. Then, you organize your testing accordingly.\u00a0<\/span>\u00a0<\/span><\/p>\nFor an online store, that might be the ecommerce site, shopping cart and payment systems. For a company with an elaborate sales organization, it could be the customer relationship management (CRM) application and related databases. Hospitals and health care providers depend heavily on electronic medical records (EMR) and prescription automation.\u00a0<\/span>\u00a0<\/span><\/p>\nAs part of disaster recovery planning, backup administrators will need to establish what to back up, how often to back it up and the number of copies they need (or can afford) to store. And all of that is driven by the question, \u201cWhich systems in my business is it most important to protect and recover?\u201d<\/span>\u00a0<\/span><\/p>\n <\/p>\n
Identify system dependencies\u00a0<\/strong><\/p>\nTo verify their backups, many administrators will individually test the backups of servers, databases and applications. However, that\u2019s not true disaster recovery testing. After a real disaster, you\u2019ll be scrambling to restore entire systems comprised of assets that need to work together. Testing out individual components ignores the interactions and dependencies among systems.\u00a0 Instead of testing components individually, it\u2019s better to test scenarios of restoring all systems and ensuring they function as before.\u00a0<\/span>\u00a0<\/span><\/p>\nFor example, your DHCP server needs to come up and assign IP addresses for dependent devices. Your Active Directory needs the DHCP server, and your front-end servers need your Oracle database.\u00a0<\/span>\u00a0<\/span><\/p>\nYou can restore individual components separately, but if they don\u2019t work properly together, you risk drawing the wrong conclusions. It\u2019s probably not that the backup-restore cycle is corrupted; it\u2019s more likely the fault of a missing dependency.\u00a0<\/span>\u00a0<\/span><\/p>\nSuppose you restore a database, start it up and confirm that you can log in and see the data. You can conclude only so much from that unless you also restore and launch your front-end application, then run some transactions that depend on the database.<\/span>\u00a0<\/span><\/p>\nTesting yields many such takeaways about the required order of operations in a disaster scenario. Designing your disaster recovery testing with purpose and intent makes validating your plan much easier.<\/span>\u00a0<\/span><\/p>\n <\/p>\n
Develop a testing schedule\u00a0<\/strong><\/p>\nA regular disaster recovery testing schedule is crucial to ensure the pieces of your disaster recovery plan are working as expected. When developing a disaster recovery testing schedule, it\u2019s important to list all the things you want to test, to establish a cadence of how often to test them and follow through on testing schedules. Align that with your hierarchy of importance by specifying testing every year, semester, quarter, month and so on. Additionally, spell out the testing methods to be used. Whether it\u2019s a walkthrough, tabletop exercise, parallel or full interruption test, the type of disaster recovery testing exercise allows teams to look for potential gaps.<\/span>
\n<\/span><\/p>\n <\/p>\n
Important takeaways for every organization\u00a0<\/strong><\/p>\nFirst, no IT environment with any level of complexity will nail their disaster recovery testing on the first try. The iterative process is punctuated with takeaways: things to change and improve that will shape disaster recovery testing in the future.<\/span>\u00a0<\/span><\/p>\nOne takeaway that might be uncovered in disaster recovery testing is that some systems and devices are so critical to the business that they are almost never restarted. That means that if something has happened on the system, months or years can elapse before the issue comes to light.\u00a0<\/span>\u00a0<\/span><\/p>\nSuppose, for instance, that you restore a database during disaster recovery testing and are unable to start it. You figure out that it hasn\u2019t been restarted in the past two years, and that it will no longer restart because it needs a system update. If that comes to your attention through disaster recovery testing\u2014rather than during a disaster\u2014it\u2019s a valuable takeaway you can incorporate with your everyday data protection activities.<\/span>\u00a0<\/span><\/p>\n <\/p>\n
The biggest mistakes organizations make with disaster recovery testing<\/strong><\/p>\nThe biggest mistake, of course, is to not have a disaster recovery plan. The second biggest mistake is not regularly testing it, not sticking to a schedule and not making the effort to secure the disaster recovery plan you\u2019ve already determined is necessary for business continuity.<\/span>\u00a0<\/span><\/p>\nAnother mistake is to overlook the less likely scenarios involving infrastructure. For instance, in the scenario of a flood or natural disaster, you may not have data center hardware available for a restoration operation.\u00a0<\/span>\u00a0<\/span><\/p>\nTesting, then, means ensuring you have adequate capacity to fail over to another data center or to spin up cloud services to take the load. And, even if you have enough capacity, will the restore be time-prohibitive? How long will your business be offline while you\u2019re restoring your 6-terabyte database to the cloud?<\/span>\u00a0<\/span><\/p>\nShort of having to survive a real-life outage, only thorough disaster recovery testing can give you the answers to those questions.<\/span>\u00a0<\/span><\/p>\n <\/p>\n
Conclusion\u00a0<\/strong><\/p>\nHaving disaster recovery alone does not solve every IT problem, and organizations often ignore the importance of disaster recovery testing at their own peril. Disaster recovery testing is a valuable tool for building confidence in the quality and availability of backups.<\/span>\u00a0<\/span><\/p>\nBy committing to regular disaster recovery testing according to your company\u2019s hierarchy of systems, you arm yourself against the day when you need to restore for the sake of business continuity. Smart organizations and IT teams follow up on their commitment to data protection when they also commit resources to testing their disaster recovery plans.<\/span>\u00a0<\/span><\/p>\n <\/p>\n
Source:\u00a0https:\/\/blog.quest.com\/disaster-recovery-testing-why-its-critical-and-tips-to-get-started\/<\/a><\/p>\n <\/p>\n
About DT Asia<\/strong><\/p>\nDT Asia began in 2007 with a clear mission to build the market entry for various pioneering IT security solutions from the US, Europe and Israel.<\/p>\n
Today, DT Asia is a regional, value-added distributor of cybersecurity solutions providing cutting-edge technologies to key government organisations and top private sector clients including global banks and Fortune 500 companies. We have offices and partners around the Asia Pacific to better understand the markets and deliver localised solutions.<\/p>\n","protected":false},"excerpt":{"rendered":"
Disaster recovery testing is an IT best practice designed to ensure any organization\u2019s disaster recovery plan actually works across the entire chain of your company\u2019s backup-and-recovery processes. It is a way of verifying that you\u2019re backing up the right data safely and securely. Most importantly, it builds confidence that your data and applications are stored, backed up and can be recovered smoothly and be relied on to maintain business continuity.\u00a0<\/p>","protected":false},"author":11,"featured_media":12879,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[56],"tags":[],"class_list":["post-12878","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-articles"],"_links":{"self":[{"href":"https:\/\/dtasiagroup.com\/vi\/wp-json\/wp\/v2\/posts\/12878","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dtasiagroup.com\/vi\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dtasiagroup.com\/vi\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dtasiagroup.com\/vi\/wp-json\/wp\/v2\/users\/11"}],"replies":[{"embeddable":true,"href":"https:\/\/dtasiagroup.com\/vi\/wp-json\/wp\/v2\/comments?post=12878"}],"version-history":[{"count":0,"href":"https:\/\/dtasiagroup.com\/vi\/wp-json\/wp\/v2\/posts\/12878\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/dtasiagroup.com\/vi\/wp-json\/wp\/v2\/media\/12879"}],"wp:attachment":[{"href":"https:\/\/dtasiagroup.com\/vi\/wp-json\/wp\/v2\/media?parent=12878"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dtasiagroup.com\/vi\/wp-json\/wp\/v2\/categories?post=12878"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dtasiagroup.com\/vi\/wp-json\/wp\/v2\/tags?post=12878"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"\"](\"https:\/\/dtasiagroup.com\/wp-content\/uploads\/2023\/07\/Blog-DisasterRecovery-IM-JY-77368.jpg\")
<\/h2>\n