Ransomware is the leading cyber threat most businesses face today. If compromised, a business is left with 2 options: Pay the ransom and hope the attacker provides a decryption key or eradicate the attacker and recover from a backup. Unfortunately, many businesses find out too late that their backup strategy wasn’t sufficient to restore their data in a timely manner, and in some cases, at all.
Things to consider when designing your backup strategy
What needs to be backed up?
This is the most important thing to decide, and while “everything” is the easy answer, not all data is created equal and different types of data should be handled according to their importance to the business.
Depending on your environment, you may need software capable of backing up more advanced applications like SQL databases where a common “file-based” backup may not be sufficient. Similarly, if your goal is to be able to restore your full environment quickly, you may have to back up things like server system states, and not just your company’s data.
And don’t forget, backups aren’t just limited to your servers. Workstations, mobile devices, and network hardware configurations may all need backups as well.
Question to ask your IT staff/provider: Does our existing backup technology properly account for the kinds of data we have?
Backup Frequency / Recovery Point Objective:
Your backup frequency or RPO is effectively a threshold for how much data your business can afford to lose in terms of changes over time. For example, does enough data change in 15 minutes to warrant the cost of backing up every 15 minutes? Are hourly or even daily backups frequent enough?
Question to ask your IT staff/provider: How frequently is our data backed up, and how do we re-create the data that is lost in between the backup intervals in the event of a disaster?
Recovery Time Objective:
Other than not having backups at all, this is where most businesses get in trouble. Recovery Time Objective (RTO) is the duration of time that functionality must be restored to avoid unacceptable consequences for the business. If your business works in a time-sensitive industry, having a backup solution that takes multiple days to recover information may not sufficiently reduce the risk to your organization.
Question to ask your IT staff/provider: How long will it take to restore critical systems (including their dependencies) in the event of a disaster? In which order to do we restore systems?
Backup Retention:
How long you need to keep backups for is the next major piece of the puzzle. Compliance, contractual, or regulatory standards often impact data retention policies of businesses and have requirements that need to be followed. But beyond those, it is up to the business to decide how long data should be kept to meet the business needs.
Question to ask your IT staff/provider: How long do we keep our backups, and do we consolidate their frequency over time? (Example, are daily backups consolidated down to a single weekly backup after X days?)
Additional Considerations
Backups v. Redundancy:
An area that gets confused often is the difference between two similar concepts: Backups and Redundancy.
Backups are when you have one or multiple copies of your data saved to a separate location (ideally offsite and not in the same building as the original) on a recurring basis so in the event of a problem, you can copy the data back, and continue to use it.
Redundancy is when you have your data actively replicating in close to real-time to a second (or multiple) location so if your primary location fails/goes offline, you can begin accessing it from an alternate location with very little or potentially no downtime.
The main difference between the two is that backups are intended to store versions of the data over time, so you can choose to copy it back to the original location if you need to. If something corrupts that information, you will have an uncorrupted copy to recover from. Redundancy is meant to make your systems more resilient to service interruptions, but because the data is actively syncing if something corrupts your live data that corruption is almost immediately replicated to the redundant location.
Examples of redundancy include RAID arrays in server storage that replicate data between 2 or more disks in the same server or redundant server sites similar to the redundant server locations used in cloud platforms like AWS or Azure.
Redundancy serves a very critical business need but is not a replacement for backups.
Backups v. Disaster Recovery:
A second concept that is often confused is the difference between having backups and having a disaster recovery or business continuity plan.
Having a backup means that if your information is lost, you can restore it. Having a disaster recovery plan means that not only can your restore the data, but you also have a plan that includes being able to restore access to that data after a disaster that might cause physical damage to your existing infrastructure (fire, flood, hurricane, etc.). A disaster recovery plan needs to include how to replace hardware or having plans for an alternative recovery location (like a remote datacenter or cloud provider), as well as plans on getting staff connected to that new location to access the data.
With this information, hopefully, you can better understand and develop your backup and disaster recovery strategy.
Let CBTS | Hawaiian Telcom take care of your IT needs so you can focus on building relationships and expanding your business. Our team of experts provides solutions on Cyber Security, Cloud Applications, Managed IT , and more. Call us at 808-777-6027 or visit our website for more information.
