Vault Best Practices
Understanding Salesforce Backup and Recovery: Challenges, Best Practices, and Effective Strategies
Introduction
Salesforce, a highly customizable and dynamic CRM platform, presents unique challenges in data backup and recovery. Unlike traditional SQL databases, Salesforce does not offer straightforward methods to export and restore entire datasets, making full recovery of data nearly impossible under current constraints. This document aims to elucidate the challenges, best practices, and effective strategies for Salesforce data backup and recovery.
Shared Responsibility for Data Security
Salesforce operates on a shared responsibility model, where users must take active steps to ensure data safety. The platform provides minimal tools to prevent data loss and facilitate restoration, requiring users to leverage external solutions and strategies to manage backups effectively.
Challenges in Salesforce Data Backup and Recovery
Governor Limits: Salesforce imposes strict governor limits, including maximum API callouts and batch processing constraints. These limits significantly impact the ability to perform comprehensive backups and restores, often requiring careful planning and execution to avoid hitting these thresholds. For example, an enterprise attempting to back up or restore a large volume of data may find that they quickly exhaust their daily API call limits, leading to incomplete backups.
Lack of Full Data Export Options: Unlike traditional databases, Salesforce does not allow users to easily export and re-import entire datasets. This limitation complicates full data recovery, as incremental and selective backups become necessary. Organizations often need to develop custom scripts or use third-party tools to extract data, which can be both time-consuming and error-prone.
Customization and Complexity: Salesforce's flexibility allows extensive customization, resulting in unique environments for each organization. This diversity makes it challenging to implement a one-size-fits-all backup and recovery solution. Custom scripts and tailored approaches are often needed to accommodate specific organizational needs. For instance, a company with highly customized Salesforce objects and workflows may find that generic backup solutions fail to capture all necessary data and metadata.
Triggers and Other Process Automation: Salesforce allows many kinds of process automation to occur when records are inserted, deleted, or updated in Salesforce. This process automation takes time to run. That time may be insignificant for individual record updates but can cause substantial delays when writing large volumes of data. It is critical for customers to architect their applications in such a way that this automation does not execute when doing large data loads such as restores or replications.
Constraints of Managed Packages: Managed packages within Salesforce come with their own set of limitations, further complicating backup and recovery processes. Operations within these packages can be slow and cumbersome, adding another layer of complexity to data management. For example, attempting to back up data from a managed package that has stringent data access controls can lead to incomplete or failed backups.
Best Practices for Salesforce Disaster Recovery Using Vault
Salesforce is a mission-critical system for many organizations, making disaster recovery a top priority. Establishing a clear Recovery Time Objective (RTO) and Recovery Point Objective (RPO) is essential to ensure business continuity in case of data corruption or system downtime. This guide outlines best practices for designing a disaster recovery strategy using AutoRABIT Vault, drawing on real-world experience with Salesforce environments.
Challenges in Salesforce Restores
When organizations attempt a full restore of Salesforce data to assess RTO and RPO, they often face the following challenges:
Salesforce Validations: Standard Salesforce validations may trigger errors during the restore, causing the process to fail.
Governor Limits: Full restores can run into Salesforce’s governor limits or max API call restrictions, making it difficult to complete the operation.
Data Complexity: The variety of data types in Salesforce adds complexity, as not all types can be restored easily or in the expected format.
Infrastructure Overload: Excessive resource consumption on Vault’s infrastructure may slow down the process, causing jobs to stall or fail.
These challenges can hinder the success of a comprehensive disaster recovery strategy. However, by following a few key best practices, organizations can mitigate these risks and run smooth recovery exercises.
Best Practices for Salesforce Disaster Recovery
Identify Critical Salesforce Objects Start by identifying the Salesforce objects that are critical to maintaining business operations. Not all data needs to be restored immediately in a disaster scenario. Work with internal teams to prioritize objects based on their business impact.
Recommendation: Collaborate with stakeholders to define which objects are crucial for "business-as-usual" operations in case Salesforce is unavailable or the data is corrupted.
Prioritize Data Within Objects Within each critical object, not all data carries the same importance. You can improve recovery efficiency by restoring high-priority data first. For instance, you may prioritize records based on when they were created, the accounts they are related to, or other business-specific factors.
Recommendation: Establish a data hierarchy for each object, based on criteria like creation date or key relationships, to streamline the restore process.
Adopt a Phased Recovery Approach Rather than restoring all Salesforce data at once, which can lead to long-running jobs and infrastructure bottlenecks, consider a phased recovery approach. Begin by restoring essential data and then proceed with the rest, minimizing pressure on system resources.
Recommendation: Plan for a staggered restoration where the most critical data is restored first, reducing the likelihood of job failures and governor limits.
Optimize Resource Usage To prevent Vault’s infrastructure from becoming overloaded during a restore, monitor the resources used by the restore process and adjust accordingly. This will help ensure that jobs complete successfully without stalling.
Recommendation: Set resource usage thresholds and plan restores during off-peak hours when system load is lower.
Test Recovery Processes Regularly Regularly test your Salesforce recovery process to validate that RTO and RPO goals are being met. This ensures that your disaster recovery plan remains effective and that any new Salesforce changes are accounted for.
Recommendation: Schedule quarterly recovery tests to stay prepared for disaster scenarios and ensure the RTO and RPO align with organizational requirements.
Conclusion
By adopting a strategic, phased approach to Salesforce restores and focusing on critical objects and high-priority data, organizations can reduce the risk of restore failures and minimize downtime. Following these best practices will help ensure that your organization’s disaster recovery process is efficient, reliable, and meets RTO and RPO targets.
AutoRABIT Vault, when paired with a thoughtful recovery strategy, can provide the confidence needed to handle Salesforce data recovery and ensure business continuity even during unexpected disruptions.
Techniques and Best Practices for Effective Backup and Recovery
Identify Critical Data and Objects: AutoRABIT works with customers to determine the critical objects and data essential for business continuity. Establish Recovery Point Objectives (RPO) and Recovery Time Objectives (RTO) around these critical elements to ensure prioritized recovery in case of data loss. For example, a financial services company might prioritize backing up customer account data and transaction histories to ensure minimal disruption in case of data loss.
Incremental Testing: For large datasets, test recovery processes using smaller data chunks before scaling up. This approach helps identify potential issues early and ensures a smoother recovery process when dealing with full datasets. A practical application might involve a retail company testing the recovery of sales data for a single store before attempting to recover data for all locations.
Regular Customization Reviews: Periodically review and assess the ongoing customizations in the Salesforce environment and their impact on the backup and recovery times. This practice helps identify changes that might complicate the 'restore' process, allowing for timely adjustments to recovery strategies and ensuring RTOs are met. For instance, a healthcare provider could regularly review custom patient data fields to ensure they are included in backup procedures and monitor for the inclusion of a rich text field in such objects, leading to increased time to recover.
Leverage Automated Solutions: Utilize automated backup and recovery strategies to minimize manual intervention and reduce the risk of human error. For example, scheduling automated daily backups and performing regular automated recovery tests can help ensure that backups are up-to-date and reliable.
Best Practices for Salesforce Backup and Recovery Using Vault
Salesforce Limitations
Metadata API can deploy and retrieve up to 10,000 files or 400 MB at one time. If either of these limits is exceeded, the deployment or retrieval will fail.
Email Messages Attachment Limitation
Salesforce has a limitation where files can only be added to Email Messages in the draft state. This presents a challenge when replicating data between organizations (Orgs). We address this issue by implementing the following steps during the replication process:
Draft State Conversion
All Email Messages are replicated in a draft state in the destination Org.
This allows for file attachments to be added to the Email Messages.
Email Messages Replication
All existing Email Messages with attachments in the destination Org must be deleted if they are already available in the destination without attachments.
Email Messages from the source Org or backup are then replicated to the destination Org.
File Attachment
During the replication process, while the Email Messages are in the draft state, any available files are attached to the Email Messages.
Email Messages are changed to the same state as in the backup or source Org, ensuring the data replication is completed successfully.
This structured approach ensures files are properly attached to Email Messages during the data replication process between Orgs using AutoRABIT.
Backup Best Practices
Configure your full backup, which includes all the Objects (standard and custom) in Salesforce org. The recommended frequency is weekly, preferably on the weekend.
Configure backup for Special objects like history, system, audit logs, and KAV objects every week. Can be set to a daily basis, if needed.
Configure incremental backups to include all the objects in Salesforce. The recommended frequency for this backup is daily.
Configure the scheduled time for full and incremental backups with enough of a time gap between them to avoid any bottlenecks in Salesforce, which may be caused due to queries being executed on the same objects in parallel.
Create backup schedules that are in sync with your production deployment schedules. Backup your entire production instance or relevant instance data before deploying to a production instance.
Identify a set of business-critical objects. Configure a backup specifically to include these objects to run at higher frequency levels (recommended frequency is multiple times a day) depending on RPO and RTO requirements.
Use the option to exclude formula fields in case of objects with a large number of fields, without which Salesforce queries may be errored out or give results slowly.
Configure email addresses of users who need to be notified upon completion or failure of backups. (By default, the user who configured the backup will be notified automatically).
Go through logs and results of backups every week to ensure that automated backups are happening as expected.
Adjust frequency and scheduled time of backup configurations based on API call limit and API call consumption by other systems.
A Salesforce user with which an org is registered on Vault should have admin-level permissions in the org. The recommendation is to create an admin user separately for Vault.
Blob Data Backup Best Practices
AutoRABIT Vault provides a reliable backup solution for Blob data (files and attachments) in Salesforce. Customers may observe a spike in API call consumption during the initial full backup of blob objects. To optimize backup efficiency and minimize business disruptions, follow these best practices:
1. Understanding Blob Data Backup
Blob objects (attachments and content versions) are typically backed up only once during the first full backup.
Subsequent backups will reference these objects without requiring additional API calls.
A spike in API call consumption is expected when performing a full backup for a newly added Salesforce org, but this occurs only once.
2. API Call Consumption
Blob objects consume API calls as follows:
Worst Case: One API call per file.
Best Case: One API call for every five files.
The total API call usage depends on the number of blob files being backed up for the first time.
3. Optimizing Backup Strategy
Since blob data is backed up only once in the first full backup, subsequent backups will not cause a similar spike in API calls.
Plan for the initial backup to handle the expected API load efficiently.
4. Scheduling the Initial Full Backup
Recommended Timing: Run the first full backup over the weekend or during non-peak business hours.
This approach helps avoid potential business disruptions due to increased API call consumption.
Monitor API call usage to ensure Salesforce API limits are not exceeded.
5. Monitoring and Adjustments
Regularly review API consumption trends during and after the initial backup.
Ensure that backup schedules align with Salesforce API limits to prevent disruptions.
Consider breaking down large backups into smaller batches if necessary.
By following these best practices, organizations can efficiently back up blob data while optimizing API call usage and minimizing the impact on business operations.
Configuration Best Practices
In this segment, we will go over some important points to note while configuring in Vault.
First Incremental Backup: It is crucial to note that the first incremental backup you perform will be a full backup. This means that during the initial incremental backup, the entire dataset will be backed up.
Avoid Deleting Configurations: It is highly recommended not to delete any configurations that you have set up. Deleting a configuration will result in the corresponding backup or archival jobs associated with it becoming inaccessible from Vault.
Limit on Users and Salesforce Orgs: By default, the total number of users and Salesforce Orgs that you can register in AutoRABIT Vault is set to 10.
Number of Configurations: AutoRABIT Vault allows you to create a maximum of 20 configurations, including both backup and archival configurations.
Increasing Configuration Count: If you require more than the default count of 20 configurations, you have the option to contact AutoRABIT. They can assist you in increasing the configuration count to accommodate your specific requirements.
Restore/ Replicate Best Practices
Active validation rules, triggers, process builder, and workflow may lead to restore/replicate failures of certain data or metadata. Make sure to disable these before performing restore/replicate operations.
Metadata API can deploy and retrieve up to 10,000 files or 400 MB at one time. If either of these limits is exceeded, the deployment or retrieval will fail. Make sure the metadata size is less than 400MB for a single job. You can split the metadata into multiple jobs to achieve restore/replicate if metadata is larger than 400 MB.
Define batch size based on the size of metadata or data you want to perform jobs on.
Archival Best Practices
Archiving parent objects will result in the deletion of all the child objects related through mandatory lookups and master-detail relationships recursively as it is an expected behavior of Salesforce. For the children related through a lookup (which is not mandatory), the reference to the parent will be removed from the child object before performing deletion of the parent.
Ensure that only one object is chosen for archival at a time in an org to avoid issues with row locks and interdependencies during the deletion of the records from Salesforce.
Always select the option to ‘Notify before deleting data from Salesforce’ to avoid auto-deletion of the records without consent and review of the records that are going to be deleted as part of the job.
Use limit and offset or an auto-increment field on the object to chunk the data for deletion into smaller batches to help understand the impact and strategize the deletion of subsequent batches based on the errors experienced in the initial batches.
Provide a smaller Bulk API batch size when triggering the archival to avoid errors arising out of Salesforce processing capabilities.
Run the archival job in serial mode to avoid errors like row locks or any other issues arising out of parallel processing in Salesforce. This is recommended only if you experience errors due to parallel mode as running the job in serial mode will impact the time it takes to execute the job.
Ensure that options to disable workflows, validation rules, and triggers are enabled during the initiation of the archive job to ensure the deletion of records won’t result in reaching Salesforce processing limitations and allocations.
Unsupported Components with Metadata API
The following components cannot be retrieved or deployed with Metadata API, and changes to them must be made manually in each of your organizations:
Account Teams
Activity Button Overrides
Auto-number on Customizable Standard Fields
Calendars
Campaign Influences
Case Contact Roles
Case Feed Layouts
Case Team Roles
Console Layouts
Currency Exchange Rates
Data Category Visibility Settings
Delegated Administration
Divisions
File Upload and Download Security Settings
Mail Merge Templates
Multiline layout fields for contract line items
Multiline layout fields for opportunity teams
Offline Briefcase Configurations
Omni-Channel Queues and Omni-Channel Skills routing types for the LiveChatButton object
Opportunity Big Deal Alerts
Opportunity Update Reminders
Organization Wide Email Addresses
Partner Management
Picklists: IdeaTheme.Categories, Opportunity.ForecastCategoryName, and Question.Origin. All other standard picklists are supported.
Predefined Case Teams
Quote Templates
Salesforce to Salesforce
Self-Service Portal Font and Colors
Self-Service Portal Users
Self-Service Public Solutions
Self-Service Web-to-Case
Service report templates
Social Business Rules
SoftPhone Layout
Solution Categories
Solution Settings
Standard fields that are not customizable, such as auto-number fields or system fields
Web Links on Person Account Page Layouts
Web-to-Lead
Managed Package Limitations
For any operation, the extent of a successful backup, restore, or replicate job depends on the permissions associated with the managed package. There is a possibility of failures of a few metadata components for which the package does not provide access. This is a limitation of the managed package and can be addressed by contacting the third-party vendor for required access.
Last updated
Was this helpful?