> For the complete documentation index, see [llms.txt](https://docs.flosum.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flosum.com/backup-and-archive/backup-and-archive/backups/understanding-binary-data-backup-limits.md).

# 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.

{% hint style="info" %}

#### 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.
  {% endhint %}

## 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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.flosum.com/backup-and-archive/backup-and-archive/backups/understanding-binary-data-backup-limits.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.