> 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-ja/backup-and-archive/bakkuappu/bainaridtanobakkuappunitsuite.md).

# バイナリデータのバックアップ制限について

## 概要

この記事では、 **Binary Data Backup Limit** 機能について説明します。この機能は、新しく接続された組織の最初の完全な複合バックアップ中に適用されます。この機能は、初回バックアップ段階で1回の実行ごとに処理されるバイナリデータレコード（ContentVersions、Attachments など）の数を制限します。既定では、1回の実行につき最大 **5,000** 件のバイナリデータレコードがバックアップされます。バックアップは、すべてのバイナリデータレコードが少なくとも1回バックアップされるまで、複数回の実行にわたって自動的に継続されます。その後は制限が解除され、バックアップは通常どおり実行され、新規および変更されたレコードのみを処理します。

{% hint style="info" %}

#### Salesforce の制約

Salesforce は、バイナリデータレコードへの API 呼び出しを標準レコードとは異なる方法で処理するため、大規模な組織では現実的な制約が生じます。

* **Salesforce API の制限:** バイナリデータ（ContentVersion、Attachments）は、一括ではなくレコードごとに準備・配信されます。バイナリデータ量が多い組織では、これによりバックアップジョブが数時間に及んだり、応答しなくなったりすることがあります。
* **回避策はありません:** これは Salesforce プラットフォームの制約であり、Salesforce はこれを解決するための API 設定やインフラ変更を提供していません。
* **業界標準:** 主要なバックアップベンダーはすべて、同様の制限を設けています。たとえば OwnBackup では、既定で1回の実行あたり2,000件に設定されています。当社の既定値は5,000件で、多くの組織に対してより迅速にカバーできます。
* **初回実行時の体験向上:** 制限がないと、大規模組織での初回バックアップに非常に時間がかかり、製品が壊れているように見えることがあります。制限を設けることで、最初のバックアップはすばやく完了し、その後は増分的に継続されるため、顧客はすぐにアプリを使い始められます。
  {% endhint %}

## 仕組み

この制限は組織設定で構成可能で、組織の最初の完全な Composite Backup にのみ適用されます。Template Backup、Template Archive、Import Backups/Archives には適用されません。

* **既定（最小）値:** 1回の実行あたり5,000件
* **最大値:** 1回の実行あたり999,999件

バイナリ以外のデータレコード（標準オブジェクト、カスタムオブジェクト、メタデータ）は、各実行で常に完全にバックアップされます。この制限は、初回バックアップ段階のバイナリデータレコードにのみ適用されます。1回あたりの件数に達すると、ジョブは正常に完了し、次のスケジュール実行が中断したところから再開します。このプロセスは、すべてのバイナリデータレコードが少なくとも1回バックアップされるまで自動的に継続します。その後は制限が適用されなくなり、複合バックアップは通常どおり実行されます。

## 適切な制限の選び方

適切な Binary Data Backup Limit は、組織内のファイルのサイズと種類によって異なります。制限を変更する際は、以下のガイドラインを参考にしてください。

* **件数の少ない小さなレコードが多い場合**: 初回バックアップを高速化し、必要な実行回数を減らすために、より高い Binary Data Backup の制限を使用します。
* **大きなファイル（1レコードあたり数百 MB または 1〜2 GB）**: 長時間の処理やタイムアウトの可能性を避けるため、既定の制限（5,000）を使用します。

### 例

この例では、80,000 件のバイナリデータレコードを持つ組織で、Binary Data Backup Limit が 20,000 件に設定されています。下の表は、各完全な複合バックアップ実行で何が起こるかを示しています。

| **実行**         | **バイナリ以外のデータレコード** | **バックアップされたバイナリデータレコード** |
| -------------- | ------------------ | ------------------------ |
| 実行 1（フルバックアップ） | 完全にバックアップ済み        | レコード 1〜20,000            |
| 実行 2（複合）       | 新規および変更されたレコード     | レコード 20,001〜40,000       |
| 実行 3（複合）       | 新規および変更されたレコード     | レコード 40,001〜60,000       |
| 実行 4（複合）       | 新規および変更されたレコード     | レコード 60,001〜80,000       |
| 実行 5 以降（複合）    | 新規および変更されたレコード     | *制限なし — 通常モード*           |

この制限は、80,000 件すべてのファイルレコードが少なくとも1回バックアップされるまで、実行 1〜4 にわたって適用されます。実行 5 以降は制限が解除され、ジョブは通常モードで実行されます。


---

# 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-ja/backup-and-archive/bakkuappu/bainaridtanobakkuappunitsuite.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.