> 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/default-composite-vs-default-composite-and-sync-back.md). # システム定義のデフォルト複合バックアップとデフォルト複合＆同期バックアップの比較 ## 概要 この記事では、次の違いについて説明します **デフォルトのコンポジットバックアップ** と **デフォルトのコンポジット＆同期バックアップ** Flosum Backup & Archive アプリにおいて、各 Salesforce 組織には 2 つの **システム定義の** スケジュールされたバックアップジョブがあります: * **デフォルトのコンポジット** **バックアップ** * **デフォルトのコンポジット＆同期削除バックアップ**. これらのジョブはシステムによって管理され、削除できませんが、実行タイミングは制御できます。各方式は、組織データの包括的で復元可能なスナップショットを維持するために、特定の目的を果たします。以下のセクションでは、各デフォルトバックアップの動作とそれらの違いを説明し、どの方式を使用するかの判断、削除されたレコードのフラグ付け方法の理解、Salesforce 環境におけるバックアップ頻度の最適化に役立てます。 {% hint style="info" %} ユーザー定義のコンポジットバックアップを使用すると、Salesforce データを必要なときにいつでもバックアップできます。たとえば、大きな変更の前や、複数のユーザーによる重要なレコード更新の後などです。詳細については、ユーザー定義のコンポジットバックアップに関する次の記事を参照してください。 * [ユーザー定義の複合バックアップの作成](/backup-and-archive/backup-and-archive-docs-ja/backup-and-archive/bakkuappu/creating-a-user-defined-composite-backup.md) {% endhint %} ### **デフォルトのコンポジットバックアップ**: デフォルトのコンポジットバックアップは、Salesforce 組織全体の変更を毎日追跡する軽量なプロセスです。最初のフルコンポジットバックアップが作成された後は、新規、変更済み、またはソフト削除（ごみ箱）されたレコードを保存します。既定では、このシステムバックアップは毎日実行され、ユーザー定義のコンポジットバックアップの代替として使用できます。 * 新規および更新されたレコードを追跡します。 * 削除され、ごみ箱に送られたレコードにフラグを付けます。 * 日次実行に最適化されています。 {% hint style="info" %} **推奨頻度** 実行 **毎日** システム性能に影響を与えずに継続的なバックアップ対象を確保するために。 {% endhint %} ### **デフォルトのコンポジット＆同期バックアップ**: デフォルトのコンポジット＆同期バックアップは、稼働中の Salesforce 組織の各レコードを Flosum のバックアップリポジトリに保存されているレコードと比較する、より高負荷な方式です。完全に削除されたレコードまで検出し、完全性を確保します。既定では、このシステムバックアップは毎月実行され、消去されたレコードを検出してバックアップの完全性を確保します。月次バックアップスケジュールが推奨されますが、このバックアップを週次で実行するよう変更することもできます。 * 全レコード比較を実行します。 * Salesforce から存在しなくなった完全削除レコードにフラグを付けます。 * 組織とバックアップの不一致を特定します。 {% hint style="info" %} **推奨頻度** 実行 **毎月** 消去されたレコードを検出し、バックアップの完全性を確保するために。（任意）組織のサイズと性能要件に応じて、毎週実行することもできます。 {% endhint %} {% hint style="info" %} **コンポジット＆同期バックアップを毎日実行すべきでない理由** コンポジット＆同期は全レコード比較を実行するため、より多くのコンピュートリソースを消費します。これを毎日実行すると、大規模な組織ではパフォーマンスが低下する可能性があります。コンポジットバックアップは、日次利用向けのより軽量な代替手段でありながら、ほとんどの削除を追跡できます。 {% endhint %} ### 簡易比較
機能コンポジットバックアップコンポジット＆同期バックアップ
頻度毎日毎月
新規/変更レコードを取得
ソフト削除されたレコード（ごみ箱）を取得
完全削除されたレコードを取得
全レコード比較を実行
システム性能への影響低い高い
### 削除レコードのフラグ付け方法 | バックアップ方式 | 削除としてフラグ付けするもの | | ------------------------- | --------------------------------------------------------- | | **デフォルトのコンポジットバックアップ** | Salesforce のごみ箱に移動されたレコード。 | | **デフォルトのコンポジット＆同期バックアップ** | Salesforce には存在しないが、Flosum Backup & Archive にはまだ存在するレコード。 | ### 削除レコードの復元 削除レコードの復元は、バックアップがそのレコードを削除済みとしてフラグ付けしているかどうかに基づきます。復元手順は次のとおりです: 1. 削除前後のバックアップを特定します。 2. Flosum Backup & Archive がフラグ付けされたレコードを検出します。 3. 削除されたレコードを Salesforce に直接復元します。 {% hint style="info" %} **例** ある取引先責任者が削除され、消去されます。次回のコンポジット＆同期バックアップで欠落したレコードにフラグが付けられ、復旧時に復元できるようになります。 {% endhint %} レコードの復元方法については、次の記事を参照してください: * [復元の概要](/backup-and-archive/backup-and-archive-docs-ja/fu-yuan/overview-of-backup-and-archive-restore.md) {% hint style="success" %} **まとめ** 2 種類のバックアップを戦略的に使い分けます: * **デフォルトのコンポジットバックアップ** 迅速で軽量なバックアップのために毎日 * **デフォルトのコンポジット＆同期バックアップ** 完全削除を検出するために毎月 このハイブリッド戦略により、両方が確保されます **カバー率とパフォーマンス** Salesforce データ保護において {% endhint %} --- # 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/default-composite-vs-default-composite-and-sync-back.md?ask=&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.