Whether your organization manufactures trucks, clothing, energy, or ideas, you are almost certainly a digital organization. You send specifications to manufacturing plants, advice to your clients, and financial data to your shareholders. Even small businesses (maybe especially small businesses!) rely upon the data they create and store. If historical, current, and planning information is suddenly unavailable, what’s the impact?
The answer depends on how you use technology to provide outcomes—how has data backup planning changed for you in the era of the cloud?—but consequences of data inaccessibility generally range from significant to severe.
If your organization cannot do business without access to its data, then you need backups. But should your organization perform its own backups? When should you consider procuring backup as a service (BaaS), and what do BaaS providers even offer?
How should you create a backup plan?
The 3-2-1 practice for data backup is a common method that suits most types of organizations. 3-2-1 is a mnemonic to abbreviate the number of copies, number of media, and a reminder that not all data should be stored in the same place.
The breakdown to remember for this rule is as follows:
- 3: Keep three copies of your current data. Your original data counts as the first copy, and you should always make two backups. Often, the original data is production data, currently being used to run your business and service your clients. However, if you have expansive test data sets, you might consider those worth backing up, too.
- 2: Your two backup copies should each be written on different media. This used to communicate different types of physical backups such as DVD or tape drives, but we can safely expand the rule to include virtualization. For instance, you satisfy the requirements of *two media* with one backup stored on a hard drive and one stored on a virtual machine. If that virtual machine is in a cloud, it can satisfy the requirement for a backup offsite. This allows for failure or destruction of a backup on one type of media in addition to potentially corrupted data in production.
- 1: One of those backup copies should definitely be offsite. Offsite does not just mean outside of your own premises. It means away from the production and your other backup copy. Businesses fully in the cloud should approach this rule the same way: If you host your data in a major cloud provider or SaaS, none of your backups should be hosted with them.
Why choose 3-2-1 as a practice?
3-2-1 is historically a practical choice. Backups were highly manual when information technology started gaining ground in business. Before cloud services were available, technical services and backups all originated in the same location; backup administrators would create several copies of each backup and send one copy to a safe, offsite location.
This was a smart practice to guard against physical or technological threats. Most IT disasters were not likely to happen in both locations simultaneously. Therefore, at least one usable backup was safe in case critical data had to be restored.
The same holds true in modern-day business, even when backups are digital. 3-2-1 ensures that one event on its own can’t render all your data irretrievable.
Why would you not choose 3-2-1?
3-2-1 loses some utility in an era where small and medium businesses (SMBs) depend on software as a service (SaaS). Information technology has become more democratic, no longer requiring in-house IT hosting and development to support technology functions.
Organizations can create beautiful web stores from templates, add products with a few keystrokes, and automatically expand processing during sales booms. Even better, they pay only for the resources used. This flexible investment allows businesses to dedicate limited resources to their specialty.
But it may also leave them without employees and tech to effectively manage their own backups.
What about SaaS provider backups?
Cloud providers (including SaaS providers) rely upon the Shared Responsibility Model for some aspects of their services. In shared responsibility, the SaaS provider has some guarantees for service, security, or data availability. The customer handles any other arrangements to ensure their own business works.
For example, the provider should guarantee that they will not lose your data due to their own errors. But they do not guarantee that a customer’s administrator will not accidentally delete the customer’s sales records or product database.
Providers perform platform-level backups. A platform-level backup has data from multiple customers. Using a platform backup to restore for one customer means losing other customers’ changes since that point. This fulfills the cloud provider’s responsibility to maintain customer data, but it makes their backups unsuitable to restore data only for one customer.
In the shared responsibility model, the customer must ensure they have backups suitable for their own needs. They must understand how they could lose or corrupt data, and what information would be needed to restore services. For instance, what if you accidentally delete an account, or a whole list of products? Not only would you lose the information deleted, but there might be missing relationships between the lost information and the data still in place. Those relationships would also have to be recreated or restored.
SaaS providers offer options to ensure customers can meet their own backup needs, with varied levels of technical skill needed. The provider may offer any or all the following:
- Automatic backups of the whole account. This is a solid choice for account-level recovery. If someone accidentally or maliciously deleted the entire SaaS service account, for instance, this is the type of backup to save the day.
- Manual web interface or API to initiate backups from the customer side. Like automatic backups, this is useful to restore all or part of your account in one go.
- Large-scale import and export. This is usually more of a convenient method to create new products or download data for reports.
What could go wrong?
Any of the options above is better than no customer-side backup, but they each have innate limitations. The lack of automation to restore from these backups is a barrier if you don’t have highly technical staff. There may be costs for backups—GitHub offers backup for ten code repositories on their free plan, but any additional backups have a cost.
And Shopify backs up their data, yes, but only at the platform level. (System backups don’t equal user backups). That basically means Shopify can withstand something going massively wrong on their end that could result in users losing data, but if you lose data on your own, you need to have an alternative method in place to restore an account-level backup.
While ensuring that you have access to your data is a good and necessary step, it’s not the entire answer. Simply having the backups does not guarantee that you can efficiently return to a running state. Do you know how backups are uploaded, restored, and tested for useability in your SaaS applications?
3-2-1 covers only backup creation and protection. It does not make up a data recovery plan on its own.
You need a recovery plan
The largest issue with using your SaaS provider for backups of data from that provider is restoring the backups. Simply downloading your repos, product files, tickets, etc., is great, but how will you put that data back into your SaaS platform in case of an emergency?
A recovery plan is start-to-finish written instructions for getting from data loss back to business as usual. It should include exact instructions for finding the data and reimporting it in the right format and with the right permissions.
If there is related data that cannot be saved and properly imported, then you need to recreate it. For example, if you save your Jira data into a JSON file, the backup is technically performed. However, the resulting JSON file is difficult to read and difficult to reimport into Jira. This increases time to recovery after a data loss event, and it’s not something you want to figure out on the fly.
Your recovery plan should be practiced on a regular basis, to ensure that it works and can be done with minimal downtime.
Commercial services for recovery
If recovery planning for your cloud and SaaS applications is not a match for your core skills, reputable vendors offer outsourced recovery. Vendors offer everything from black-box storage to server and database backups to SaaS application account-level recovery. Unlike provider backups, backups as a service gather only data belonging to the individual client—you.
If you decide to go with a BaaS, look for vendors that match your cloud or SaaS application usage. For instance, if you need a combination of business and technical SaaS apps, you could go with [Rewind](https://rewind.com/products/backups/github/). They have prebuilt backup integrations for a wide set of cloud service providers, and you would only need to learn one BaaS product to cover their spread.
Organizations with low tolerance for downtime should consider commercial backup providers. They provide recovery on a strict time frame and with a high degree of assurance. They have a lower capital outlay than investing in your own backup storage and software, and their business model depends on successfully managing data restore on behalf of each customer individually.
A commercial BaaS can either be the main solution or can replace part of your own 3-2-1 practice. The only right answer is one that fits your budget, technical skill availability, and recovery time needs.
Don’t assume that your SaaS vendors include backups that suit your needs. Ensure that you understand their data recovery options, then evaluate the gaps between their offering and your needs. Most organizations will need additional backups and a plan to restore the backed-up data into their SaaS applications. Using a multiple-copy, multiple-location plan such as 3-2-1 provides more assurance that the data will be available when needed.
But remember that creating a recovery plan is more than having multiple backups. Ensure that responsible parties in your organization know how to access and restore backups, including recreation of data that wasn’t copied and stored.
If your enterprise does not have the expertise or a desire for the capital outlay, a BaaS provider may be the answer. If you choose a BaaS, look for a solution that covers as many of your SaaS providers and critical applications as possible.