> 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-docs-pt-br/backup-e-arquivo/backups/entendendo-os-limites-de-backup-de-dados-binarios.md).

# Entendendo os limites de backup de dados binários

## Visão geral

Este artigo explica o **Limite de Backup de Dados Binários** recurso, que é aplicado durante o primeiro backup completo composto de uma organização recém-conectada. O recurso limita o número de registros de dados binários (ContentVersions, Anexos etc.) processados por execução durante a fase inicial de backup. Por padrão, até **5,000** registros de dados binários são copiados por execução. O backup continua automaticamente ao longo de várias execuções até que cada registro de dados binários tenha sido copiado ao menos uma vez. Depois disso, o limite é removido, e os backups passam a ser executados normalmente, processando apenas registros novos e modificados.

{% hint style="info" %}

#### Limitação do Salesforce

O Salesforce trata as chamadas de API para registros de dados binários de forma diferente dos registros padrão, o que cria uma restrição real para organizações grandes:

* **Limitação da API do Salesforce:** Os dados binários (ContentVersion, Anexos) são preparados e entregues por registro, e não em lote. Em organizações com grandes volumes de dados binários, isso pode fazer com que os jobs de backup sejam executados por horas ou fiquem sem პასუხividade.
* **Não existe solução alternativa:** Esta é uma restrição da plataforma Salesforce, e o Salesforce não fornece nenhuma configuração de API nem alterações de infraestrutura para corrigir isso.
* **Padrão do setor:** Todos os principais fornecedores de backup impõem um limite semelhante. O OwnBackup, por exemplo, usa como padrão 2.000 registros por execução. Nosso padrão é 5.000, oferecendo cobertura mais rápida para a maioria das organizações.
* **Melhor experiência na primeira execução:** Sem um limite, um backup inicial em uma organização grande pode demorar tanto que o produto parece estar com problema. Com o limite, o primeiro backup é concluído rapidamente e continua de forma incremental, para que os clientes possam começar a usar o app imediatamente.
  {% endhint %}

## Como funciona

O limite é configurável nas configurações da organização e se aplica apenas ao primeiro Composite Backup completo de uma organização. Ele não se aplica ao Template Backup, ao Template Archive ou aos Import Backups/Archives.

* **Valor padrão (mínimo):** 5.000 registros por execução
* **Valor máximo:** 999.999 registros por execução

Todos os registros de dados não binários (objetos padrão, objetos personalizados, metadados) são sempre copiados integralmente em cada execução. O limite se aplica apenas aos registros de dados binários durante a fase inicial de backup. Assim que a quantidade por execução é atingida, o job é concluído normalmente, e a próxima execução agendada continua de onde parou. Esse processo continua automaticamente até que todos os registros de dados binários tenham sido copiados ao menos uma vez. Depois disso, o limite não se aplica mais, e os backups compostos são executados normalmente.

## Escolhendo o limite certo

O limite certo de Backup de Dados Binários depende do tamanho e do tipo dos arquivos na sua organização. Use as seguintes orientações ao alterar o limite.

* **Muitos registros pequenos**: Use um limite mais alto de Backup de Dados Binários para acelerar o backup inicial e reduzir o número de execuções necessárias.
* **Arquivos grandes (centenas de MB ou 1–2 GB por registro)**: Use o limite padrão (5.000) para evitar operações longas e possíveis timeouts.

### Exemplo

Neste exemplo, uma organização com 80.000 registros de dados binários tem um Limite de Backup de Dados Binários definido como 20.000 registros. A tabela abaixo mostra o que acontece em cada execução do backup completo composto.

| **Execução**                 | **Registros de dados não binários** | **Registros de dados binários copiados** |
| ---------------------------- | ----------------------------------- | ---------------------------------------- |
| Execução 1 (backup completo) | Copiados completamente              | Registros 1 – 20.000                     |
| Execução 2 (composto)        | Registros novos e alterados         | Registros 20.001 – 40.000                |
| Execução 3 (composto)        | Registros novos e alterados         | Registros 40.001 – 60.000                |
| Execução 4 (composto)        | Registros novos e alterados         | Registros 60.001 – 80.000                |
| Execução 5+ (composto)       | Registros novos e alterados         | *Sem limite — modo normal*               |

O limite se aplica nas Execuções 1–4 até que todos os 80.000 registros de arquivos tenham sido copiados ao menos uma vez. A partir da Execução 5, o limite é removido, e o job é executado em modo normal.


---

# 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-docs-pt-br/backup-e-arquivo/backups/entendendo-os-limites-de-backup-de-dados-binarios.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.
