Understanding Binary Data Backup Limits

Overview

This article explains the Binary Data Backup Limit feature, which is applied during the first full composite backup of a newly connected organization. The feature limits the number of binary data records (ContentVersions, Attachments, etc.) processed per run during the initial backup phase. By default, up to 5,000 binary data records are backed up per run. The backup continues automatically across multiple runs until every binary data record has been backed up at least once. After that, the limit is lifted, and backups run normally, processing only new and modified records.

Salesforce Limitation

Salesforce handles API calls to binary data records differently from standard records, which creates a real-world constraint for large organizations:

• Salesforce API limitation: Binary data (ContentVersion, Attachments) is prepared and delivered per record rather than in bulk. In orgs with large volumes of binary data, this can cause backup jobs to run for hours or become unresponsive.
• No workaround exists: This is a Salesforce platform constraint, and Salesforce does not provide any API configuration or infrastructure changes to fix it.
• Industry standard: All major backup vendors impose a similar limit. OwnBackup, for example, defaults to 2,000 records per run. Our default is 5,000, providing faster coverage for most organizations.
• Better first-run experience: Without a limit, an initial backup in a large org can take so long that the product appears broken. With the limit, the first backup completes quickly and continues incrementally, so customers can start using the app immediately.

How It Works

The limit is configurable in the organization settings and applies only to the first full Composite Backup of an organization. It does not apply to Template Backup, Template Archive, or Import Backups/Archives.

• Default (minimum) value: 5,000 records per run
• Maximum value: 999,999 records per run

All non-binary data records (standard objects, custom objects, metadata) are always backed up fully in every run. The limit applies only to binary data records during the initial backup phase. Once the per-run count is reached, the job completes gracefully, and the next scheduled run picks up where it left off. This process continues automatically until all binary data records have been backed up at least once. After that, the limit no longer applies, and composite backups run normally.

Choosing the Right Limit

The right Binary Data Backup Limit depends on the size and type of files in your organization. Use the following guidelines when changing the limit.

• Many small records: Use a higher Binary Data Backup limit to speed up the initial backup and reduce the number of runs needed.
• Large files (hundreds of MB or 1–2 GB per record): Use the default limit (5,000) to avoid long-running operations and potential timeouts.

Example

In this example, an organization with 80,000 binary data records has a Binary Data Backup Limit set to 20,000 records. The table below shows what happens in each full composite backup run.

Run	Non-Binary Data Records	Binary Data Records Backed Up
Run 1 (Full backup)	Backed up completely	Records 1 – 20,000
Run 2 (Composite)	New and changed records	Records 20,001 – 40,000
Run 3 (Composite)	New and changed records	Records 40,001 – 60,000
Run 4 (Composite)	New and changed records	Records 60,001 – 80,000
Run 5+ (Composite)	New and changed records	No limit — normal mode

The limit applies across Runs 1–4 until all 80,000 file records have been backed up at least once. From Run 5 onward, the limit is lifted, and the job runs in normal mode.