[FAQ] バックアップ＆アーカイブ – よくある質問
概要
概要このFAQは、Flosum Backup & Archiveに関連する一般的な質問に対処しており、さまざまなクラウドプラットフォームでのアーキテクチャ、セキュリティ、運用動作、および復元機能を含みます。
アーキテクチャとインフラストラクチャ
アーキテクチャとインフラストラクチャAWS上のFlosum Backup & Archiveのアーキテクチャの構成はどうなっていますか？
Flosum Backup & ArchiveはAmazon EC2インスタンス上で実行され、外部でSalesforce SaaSに接続します。
Nginxがプロキシリクエストを処理し、SSLを有効にします。
User Pool Serviceはアクセス制御を管理します。
MySQLはアプリの構成設定を保存します。
ローカルストレージのオプションには以下が含まれます：
SSD（gp2またはgp3）
S3オブジェクトストレージ
Google Cloud Platform（GCP）のアーキテクチャの構成はどうなっていますか？
GCPの仮想マシン内で実行され、外部でSalesforce SaaSに接続します。
プロキシ/SSL用のNginx
アクセス制御のためのGoogle Identity Platform
構成保存のためのMySQL
SSD上のローカルCSVストレージ
Azureのアーキテクチャの構成はどうなっていますか？
Azure VM内で実行され、Salesforce SaaSにアクセスします。
プロキシ/SSL用のNginx
アクセス制御のためのAzure Active Directory
アプリ設定のためのMySQL
ストレージオプション：
SSD（gp2またはgp3）
S3互換ストレージ
セキュリティとストレージ
セキュリティとストレージグローバル設定とローカルストレージの役割は何ですか？
グローバル はSalesforce接続を管理し、AWS Cognito（またはそれぞれのIDプロバイダー）でユーザーアクセスを制御します。
ローカルストレージ は処理中の一時的なデータ保存として機能します。
バックアップと復元の動作
バックアップと復元の動作なぜデータを復元するのに 2 つのバックアップ（破損ポイントと復旧ポイント）が必要なのですか？
推測を最小限に抑え、影響を受けたデータのみを復元するためです。Flosum は次の間の変更を比較します：
バックアップ 前 データ損失（復旧ポイント）
バックアップ 後 インシデント（既知の破損ポイント）
のみ 変更されたレコード が復元され、精度と速度が確保されます。
スケジュールされたバックアップが実行中のジョブと重複した場合はどうなりますか？
重複するバックアップは スキップされます。次の未使用のスロットで見逃した変更がキャプチャされます。複合バックアップは再開され、最後の正常な実行以降のすべての差分を取得します。
なぜ History オブジェクトは復元されないのですか？
Salesforce では、History オブジェクトには 挿入/更新 の権限がありません。これは Flosum の制限ではなく、Salesforce プラットフォームレベルの制約です。
バックアップジョブのレコード数はどのように機能しますか？
完了したバックアップジョブを確認すると、アプリはバックアップに保存されているレコード数とそのジョブで処理されたレコード数を表示します。
合計：特定のオブジェクト（例：取引先、取引先責任者）について、Backup & Archive アプリに現在保存されているすべてのレコードの数。
オブジェクト行をクリックすると、 レコードテーブルが開き、次を表示します：
すべて ＝ 追加 + 変更 + 削除
追加 ＝ このジョブでキャプチャされた新規レコード
変更 ＝ 更新された既存のレコード
削除 ＝ 最後のバックアップ以降に削除されたレコード
例：
例えば、昨日新しいバックアップが作成され、組織から 40 件のケースレコードをキャプチャしました。合計は 40 件のケースレコードを示します。本日、10 件の新しいケースを追加し、既存のケースを 5 件更新しました。
本日のバックアップは次のように表示されます：
合計
50（元の 40 + 新規 10）
追加
10
変更
5
削除
0
すべて
15（10追加 + 5変更）
概要：
合計 = すべてのレコードが保存されました
すべて / 追加 / 変更 / 削除 = この特定のバックアップジョブでの変更
バックアップ＆アーカイブアプリの「子オブジェクトを追加」画面のアイコンやチップは何を示していますか？
「子オブジェクトを追加」画面のアイコンと表示は、特にアーカイブ中の削除時に、親オブジェクトと子オブジェクト間の重要な関係を伝えます：
黄色の警告三角（カスケード削除）
子オブジェクトは親に対して依存（カスケード削除）関係を持っています。
これらは次のように見なされます 依存オブジェクト Salesforce内で。
アーカイブに含めるかは任意です アーカイブに。
除外した場合、親がアーカイブおよび削除されると子レコードは削除されます。
これはSalesforceのネイティブのカスケード動作を反映しています。
赤い鍵アイコン（制限付き削除）
子オブジェクトは親オブジェクトと 制限付き削除の関係を持っています 親オブジェクトと。
これらのオブジェクトは 自動的に含まれます アーカイブテンプレートに含まれ、 除外することはできません。
Salesforceでは、制限付き削除の関係により、関連する子レコードが先に削除されない限り親レコードを削除できなくなります。
エラーを防ぐためにアーカイブに必須です。
リストア中にOrderオブジェクトのRecordTypeIdフィールドでINVALID_CROSS_REFERENCE_KEYエラーが発生するのはなぜですか？
このエラーは、アーカイブされたデータのRecordTypeIdが現在の組織に存在しないかアクセス不可能な場合に発生します。
根本原因：
アーカイブされたレコードには暗黙的に割り当てられたRecordTypeIdがあり、次のいずれかです：
現在の組織にもう存在しない。
リストア実行ユーザー（実行ユーザー）からは表示/アクセスできない。
過去の設定やマネージドパッケージに紐づいていた。
解決策：
リストア時にRecordTypeIdフィールドを除外してください。
Salesforceはデフォルトのレコードタイプを自動割り当てします。
クロスリファレンスエラーを防ぎ、リストアを完了させます。
FromAddressを持つEmailMessageレコードをリストアするとINVALID_OR_NULL_FOR_RESTRICTED_PICKLISTエラーが発生するのはなぜですか？
これはFromAddressがあなたのSalesforce組織で認識されていないか検証されていない場合に発生します。
Salesforceが許可するのは次のみです：
組織全体のメールアドレス（Organization-Wide Email Addresses）
Email-to-Caseのルーティングアドレス
有効なユーザーのメールアドレス
バックアップのFromAddress（例：[email protected]）が検証されていない場合、Salesforceは以下を返します：
INVALID_OR_NULL_FOR_RESTRICTED_PICKLIST
INVALID_FIELD_VALUE
このエラーは、SalesforceがFromAddressに対して制限を強制しているために発生します。 FromAddress フィールドの EmailMessage オブジェクト。エラーは～を指しています ValidatedFromAddress、しかし問題は～の値にあります FromAddress フィールドで、その値はSalesforceで検証および承認されている必要があります。
内部的に、Salesforceは～という名前のフィールドを使用します ValidatedFromAddress が承認済み送信者の一覧に含まれていることを確認するために。 FromAddress このエラーを復元や挿入時に回避するには、EmailMessageレコードの復元リクエストから～フィールドを除外してください。 ValidatedFromAddress フィールドを復元リクエストから除外してください。
Backup & Archiveアプリを使用するユーザーに「Query All Files」権限をいつ付与すべきで、付与されないと何が起こりますか？
この 「Query All Files」 権限は機微な権限であり、信頼できるシステムまたは統合ユーザーのみに割り当てるべきです。
必要な場合：
ユーザーと明示的に共有されていないファイルをバックアップまたは復元する場合。
付与されていない場合：
共有されたファイルのみがバックアップされます。
レコードアクセス経由で表示される一部のファイルはスキップされる可能性があります。
復元時にキャプチャされていなかったファイル添付が見落とされる可能性があります。
影響：
ファイルのバックアップおよび復元が不完全になります。
共有または協働環境でデータの欠落が発生するリスク。
最終更新
役に立ちましたか？