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.
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.
Using Trigger Handlers or Other Means to Disable Automation: It is important to prevent automated jobs from executing when you are performing restore and replication jobs. While Vault has the ability to disable Triggers and Workflow rules, this is not an efficient way to disable automation since it requires a deployment to the org, which can require test execution, and will disable this automation for ALL users. By contrast, Trigger handlers allow this automation to be disabled only for the user performing the restore jobs. See this article for more information.
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
General Guidelines on 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.
See Vault Archival Best Practices below.
Email Messages Attachment Limitation
Issue 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).
AutoRABIT Solution 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 on a weekly basis. 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 on a weekly basis 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.
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.
We strongly urge everyone to implement frameworks such as Trigger Handlers that allow you to disable automation (Triggers, Flows, Workflow Rules, etc.) for certain users or at certain times. Salesforce offers brief guidance on this on Trailhead, and there are multiple Trigger Handler patterns available such as the Apex Trigger Actions Framework. Data restore jobs generally do not need to re-process that business automation. By bypassing this automation you can reduce time to write data to Salesforce by 10x or more.
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.
Make sure record owners are active on Salesforce, as Restore/Replicate will fail for inactive owners. If activating owners is not an option, you can enable ‘Set Audit Fields and Update Records with Inactive Owners’ on Salesforce.
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
Reference: https://developer.salesforce.com/docs/atlas.en- us.api_meta.meta/api_meta/meta_unsupported_types.htm#:~:text=Some%20things%20yo u%20can%20customize,Account%20Teams
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