It’s a new year, full of new beginnings, innovative ideas, and new disasters! They occur every year. Usually when it’s least convenient. Here are some tasks to complete as a self-check of your own disaster recovery (DR) efforts.
Time to double-check to make sure that all your systems are being backed up. This includes the following:
You will also want to check to ensure your backup application supports application-aware backups, and that your current backups are taking advantage of it. These may include Microsoft SQL Server, Exchange, Active Directory, Oracle, SAP, and more. Application-aware backups allow a more in-depth type of backup, usually providing additional information to the backup set, like database archive/transaction logs. This ensures your backup is consistent with what the application expects.
Backups are only as good as the restore. What happens if you can’t restore the data from that location? Things like power outages, network issues, and sudden flash floods are all notable examples of why you want to have your data in two locations.
Backing-up data in multiple locations keeps you protected from a localized disaster and keeps the business running smoothly.
By now, unfortunately, many of us may have had the disastrous experience of having their business attacked and compromised by malware or ransomware. Bad actors look to take advantage of security holes/vulnerabilities in software, hardware, networks, or unsuspecting personnel in their organization. Once infiltrated, that piece of malware penetrates the network, encrypting all the data it can find, including the backups!
BUT, if you keep your backups (or a copy of your backups) on a different type of medium, such as tape, air-gap, or API-based storage (e.g., Catalyst Store on a StoreOnce from HPE) you will be protected from such an attack. By having a backup set on a type of storage that is not accessed through normal means, you can protect your organization from a propagating threat.
You may have gone through every application, every server, and every spec of data. You have it backed-up, replicated to various locations around the world. You may be on the waitlist for that datacenter on the moon to be extra sure. But all of this doesn’t mean a thing if the backups aren’t any good. The backup application may say the backups are sufficient and valid, but we need to be sure. And the only way to be sure is to test the backups.
Virtual environments allow testing to be performed quickly and safely via separate lab networks or clusters. Separating allows one to test in an isolated environment. One can run all of the desire restore tests to verify the data is there, consistent, and working with the end applications, but without worry or consequence of interrupting an actual production workload. Backup applications can assist you with this sort of testing, such as Veeam’s Virtual Labs and Zerto’s Test Failovers. These allow you to spin-up your protected assets in the isolated environment, conduct your testing, then tear it down once your testing is complete.
Physical backups can be a bit more complicated. If possible, you can take your physical backups and P2V (Physical to Virtual conversion) data to your virtual environment (then proceed like a virtual environment). However, that is not always an option. Sometimes, the server must be physical for a number of reasons: application certification, specific hardware requirements (e.g., a graphics card, connectivity to hardware/networks not available to your virtual environment, etc.). It may sound expensive to keep another set of hardware just in case the main one breaks. But consider the loss of business and revenue if that piece of hardware is unavailable.
If you have a lot of servers to check the backups for, it may be too much to do in a single weekend or even a month. Some organizations may set up a rotation to test their backups so that they do just a few each month or quarter. That way, over the course of a year, all servers will be tested for recoverability.
Remember when we looked at where we had our data backed-up and ensured we had our data in multiple locations? We should be testing each copy of the data, too. Having data in a DR site, tape library, or up in the cloud doesn’t do you any good if the backups aren’t acceptable. Make sure you include your remote copies as well in your testing.
Cloud services are very cool, eliminating many headaches due to administrative tasks of running things like email, online collaboration, and file storage, to name a few. The data there is usually secure and available. There is often an interface that will let you restore data, but the devil is in the details, and you will want to make sure the backup is protected per your organization’s requirements.
You will want to check-up on backup retention, recovery points, where it’s backed up, and how you can test your restores. If this sounds remarkably similar to the checkups you do with your on-prem data, it’s because it is. It is still your data at the end of the day. You need to take the steps required to protect your data and recover it from any disaster.
Another concern is access to cloud services. Many of these exist in the public cloud. If something happens that prevents you or your colleagues from accessing the service (e.g., network interruption or vendor outage), what do you do? Do you have a local or separate copy you can restore to another service or on-prem resource?
When disaster hits, company panic will be the biggest enemy you face. If you are responsible for bringing it back, you need to be the pillar of strength. You need to have a plan. With a plan in place, you can bring calmness and order to a stressful and chaotic situation. When drafting up your disaster recovery plan, remember to include the following:
Once the plan is setup, created, and approved, rehearsing the plan is just as important as having one. By having the plan put into practice into live DR tests, the staff will be comfortable with their individual tasks and responsibilities, and they will become more proficient and efficient in doing them. Rehearsing the DR plan means the team will be ready and prepared for when a real disaster strikes.
So, at the start of the new year, take this opportunity to go over your disaster recovery plans to protect your company’s data and services. If you discover gaps in your understanding or confidence in your disaster recovery plan, Anexinet can help. In just three short weeks, our Disaster Recovery Strategy Kickstart takes a deep dive into your organizations’ Disaster Recovery plan and provides a strategy that eliminates gaps and streamlines, automates, and prepares your team so they’re ready when the disaster strikes.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
|cookielawinfo-checbox-analytics||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".|
|cookielawinfo-checbox-functional||11 months||The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".|
|cookielawinfo-checbox-others||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.|
|cookielawinfo-checkbox-necessary||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".|
|cookielawinfo-checkbox-performance||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".|
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Other uncategorized cookies are those that are being analyzed and have not been classified into a category as yet.