Many IT leaders and Salesforce admins assume (incorrectly) that their data is safe in the cloud. The reality is, organizations using SaaS apps bear higher data protection liability and business risk than ever before. As cloud apps and platforms are adopted, data volume and velocity are growing exponentially, which means errors or corruption can have cascading implications.
Compounding the issue is low-code or no-code technology, which often attracts less experienced developers, who may not fully understand how changes they make may impact the rest of the organization. According to a recent article in SiliconAngle, “poor understanding of the basics of configuring access privileges, combined with misplaced beliefs that cloud providers take care of total security of customer accounts, has contributed to an epidemic of configuration errors.”
That’s why as a key part of business continuity planning, disaster recovery for SaaS applications has been top of mind more than ever before, forcing companies to think about how their operations would fare in the event of a data loss or corruption scenario. For Salesforce customers, It’s especially critical to think about now that the data recovery service is no longer available. Without the data recovery service as your safety net, you’ll need to identify another solution for Salesforce backup and recovery.
As you construct your disaster recovery plan, two important metrics to define are your recovery point objective (RPO) and recovery time objective (RTO).
Suppose human error or one of the many other common causes of loss or corruption impacts your company’s Salesforce data, metadata, or attachments. Regardless of the reason, the business impact is considerable.
The clock starts ticking once you discover the problem, putting your company’s RPO and RTO to the test. Let's examine what those terms mean.
Recovery Point Objective (RPO)
As a measure of the amount of data a company can afford to lose before it begins to impact business operations, RPO is an indicator of how often a company should back up its data. RPO won’t be the same for every company. Typically, companies aim to recover to a point not more than a day ago. Many companies back up data daily, or better yet, multiple times per day for critical data.
For example, suppose your company uses Salesforce’s Weekly Export to back up their data. In this scenario, your current RPO is one week. In other words, if you ran a Weekly Export on Sunday, and then the following Saturday, you had a large data loss, you would only be able to recover data in its state from six days prior. For most organizations, this would be unacceptable.
Another option is to export data via the Salesforce API into a SQL database. Depending on your ETL tool, this may or may not pull daily. It could even run hourly or every 15 minutes. However, be cautious with tools that overwrite previous backups, as this will drastically increase your RPO.
Recovery Time Objective (RTO)
RTO is the timeframe by which you must restore after data loss or corruption has occurred. The goal here is for companies to calculate how fast they need to recover by preparing in advance.
For example, if your company’s RTO objective is 48 hours, it means you must be able to restore data in less than two days. That’s because your disaster recovery plan has determined that if you cannot recover the data within that time frame, the business could suffer irreparable harm.
Keep in mind that recovery time starts when you first become aware of the situation. Recovery time is variable and depends on multiple factors, including your approach to the following recovery tasks.
Now that you understand the importance of these two concepts, what do they mean for your organization?
How To Define Your RPO
1. Figure out how often critical data changes throughout your organization.
For many industries, including healthcare, manufacturing, and financial services companies, losing data is not an option. Consumers trust their data to these organizations. Therefore, not having records available and up-to-date is unacceptable. If the Salesforce org is constantly changing, the frequency of Salesforce backups should match. Backing up often as every hour, for certain objects, may be warranted. It is important to prioritize the protection of the data without which your business cannot function.
2. Determine how much data you are willing to lose.
When setting your RPO, you should factor in how much data you are willing to lose. If your Salesforce backup occurs once a day, then the RPO of this backup solution is equivalent to one day. Therefore, if a data loss were to happen, you could roll back to the last backup representing a loss of up to one day of data. Determining the amount of data you can lose before your company begins to suffer is a crucial facet of the disaster recovery planning process.
3. Identify the required frequency of your backups.
You can calculate RPO by analyzing the time between data backups with the potential data that could be lost should a data loss occur. If your backups are running weekly, your company will potentially lose a week of data. Therefore, it is essential to establish the time that your business can be without specific data before it impacts operations.
How To Define Your RTO
1. Decide how long you could afford to be without the data.
Losing data is one thing, but unscheduled downtime can send your company into chaos. With customers being unable to access your systems and employees sitting around with nothing to do, a strict limit on the amount of time it should take to recover your systems after a user inflicted data loss or corruption is necessary.
2. Estimate the cost of a data loss or corruption.
The cost not only depends on the value of your data but also on the business impact. Increased labor costs, data recovery fees, reputation damage, revenue impact, compliance fines, and a loss in productivity contribute to the cost of data loss and corruption.
3. Test your disaster recovery plan regularly.
Once you’ve outlined a disaster recovery plan, you need to test it to ensure that it works. All personnel involved in the disaster recovery plan need to be present for each test to be aware of responsibilities and roles in the disaster. At a minimum, companies need to test their disaster recovery plan annually and communicate all aspects of the plan to all parties.
An example of a Salesforce disaster recovery test would be a simulation of a data loss (where you delete data) and data corruption (where you incorrectly update data). Then, using the current Salesforce backup you have in place, retrieve the lost and corrupted data, and insert that data back into your org. Make a note of how much information was lost (your RPO) and how long it took to recover your data back into Salesforce (your RTO). Regularly running these tests will ensure that your company is equipped and able to handle different disaster scenarios.
By backing up all of your Salesforce data, metadata, and attachments daily, OwnBackup minimizes the amount of data your organization will lose, or RPO, as well as the time it will take to recover, or RTO. Our High-Frequency Backup feature goes even further by backing up highly-transactional, frequently-changing data as often as every hour.
OwnBackup customers can also set up Smart Alerts, which notifies users when data is changed, deleted, or corrupted, based on their set rules or statistical outliers. Without it, the most common way Salesforce admins will learn about data loss or corruption incidents is from users or management, which could take weeks, months, or even longer.
Another way OwnBackup helps companies lower their RTO is with the help of our Customer Success team. At OwnBackup, we offer 24x7 support, 365 days a year, as part of our Premier package, enabling you and your team to focus on other meaningful priorities within your organization.
OwnBackup customers recover lost or corrupted data in less than one day, compared to non-customers who take an average of seven or more days, according to the 2020 State of Salesforce Data Protection Results.
One of those customers, South Jersey Industries (SJI), was notified by OwnBackup Smart Alerts of a profile and permission set metadata change within their Salesforce platform that affected their energy org. SJI immediately logged into their OwnBackup account to identify the issues and restore the profiles and permission sets to their proper values. The OwnBackup data protection solution proved to be incredibly efficient and reliable during small and large scale data recovery scenarios.
With the retirement of Salesforce’s Data Recovery service, now is the perfect opportunity to take a step back and put a comprehensive Salesforce backup and recovery plan in place to ensure that your org has the same level of protection as your other critical systems.