Key concepts needed to build a data recovery plan

Tom LaRock, SolarWinds Head Geek says that World Backup Day is more than just about backing up your data and highlights major points to prepare an effective data recovery plan on the occasion

Every year, we celebrate World Backup Day, a day created to raise awareness of the importance of backing up your data. The holiday was created in 2011 by a group of Reddit users tired of replying to Reddit threads from users posting, “I deleted my database, and I have no backups, please help.” But World Backup Day is more than just about backing up your data. It is also meant to promote good data hygiene by encouraging activities such as protecting data at rest, in use, and in transit. Basically, anything which reduces the risk of data loss and improves the chances of data recovery.

Data recovery is the real goal. It’s easy to think, “Hey, I need to have backups.” But more important is a data recovery plan. As a database administrator, I learned long ago that backups are worthless but restores are priceless. Building a data backup plan is a mistake without first building a data recovery plan. And you can’t start building a data recovery plan without understanding some key concepts.

Understanding business requirements
A good recovery plan starts with a solid understanding of the business requirements. You need to understand some common acronyms such as SLA (service-level agreement), RTO (recovery time objective), and RPO (recovery point objective). Start with the RTO, the amount of time allowed for the recovery to be complete, and then RPO, the point in time to which you will recover. These two will combine to help define the SLA. For example, you could have a requirement to recover a database to a point in time fifteen minutes ago (RPO) and be allowed ten minutes for the recovery to be complete (RTO). If the volume of data is such that it could take you an hour to recover to yesterday, and the business thinks the SLA should be fifteen minutes, you can see a disconnect between expectations and reality.

Learn the 3-2-1-1 strategy
Regarding backups, you should consider the following strategy: at least three copies in at least two different formats, one of which must be immutable, and one must be stored offsite. This may seem a bit much for your regular household computer, but for a corporate environment, it is a must. For businesses, regular backups are crucial, as they often deal with confidential data, which can result in serious consequences if lost or stolen. Remember, this is about minimising loss risk and improving your chances of recovery. Taking a backup once a year isn’t as useful as regular backups more frequently, for example. And storing a backup on the same hard drive as your data isn’t as useful as storing it on an external drive, or in the Cloud.

HA != DR
More acronyms for you to know, high-availability (HA) and disaster recovery (DR). I have been in more than one room where someone with letters in their job title has said, “once we have HA in place we won’t need the DR stuff anymore”. This is false and dangerous thinking because HA and DR are two very different things. While it might be easy to think a piece of technology such as data replication allows for you to access data for recovery purposes, the truth is different. The example I always give is this: mistakes get replicated, too. When you drop a table here, it gets dropped there, and the only way to recover is with a backup. HA is for availability, not recovery. And as a DBA, I know I can’t keep my job if I can’t recover.

Test your Recovery Process
There is only one way to verify if a backup is good: by testing your restore process. Having a bunch of backup files is nice, but of little value if they cannot be used for a restore. Some corporations practice DR planning on an annual or semi-annual basis, to make certain in the event of a disaster they have the necessary experience to recover and continue operations. But you don’t need to wait, you can test your backups by doing a small sample at a time. Pick a server, or some databases, and see if you can restore your data, and if the process continues to meet defined SLAs. Data typically only grows larger, not smaller, meaning your RTO and RPO get more difficult to align with SLAs over time. The phrase “too big to failover” comes to mind when I think of data growth.

Data backups are often a tedious process, one which is put off or forgotten about until it is too late. World Backup Day is one way to remind everyone of the importance of having regular backups. It is a chance to make a difference between securing your valuable information and losing it all.

With increasing ransomware and cyber-attacks, a robust database backup strategy is non-negotiable. World Backup Day serves as an opportunity for business and database leaders to think critically about their organisation’s backup strategy and ensure they are employing the best practices. Consider where you store your data in the cloud, on-premises, or across other systems — because location can have a major impact on cost and the overall effectiveness of your recovery process.

Ask any IT professional and they will agree – we get paid for performance, but we keep our jobs with recovery. So, take a few minutes out of your day on March 31 and create backups of your data. You never know when you might need them.