Salesforceのプロジェクトでしばしば課題として挙げられる、バックアップとリストア（データのリカバリ）について、Salesforce公式が推奨する方法を踏まえ、どのような対応方針があるのかを説明していきたいと思います。
RPF（提案依頼書）などでも、バックアップとリカバリについて提案することを求められる場合もあるため、本記事を参考に対応方針をご検討ください。
データバックアップの必要性について
Salesforceなどのクラウドサービスに限らず、各種システムでは様々な理由（H/W障害、災害、人的ミスなど）によりデータを損失する可能性があります。データの損失によりビジネスや業務に与える影響は非常に大きいものとなります。
そのため、これらのリスクを回避するためにこれらの事象が発生した場合に、データを損失する前の状態に戻すためにバックアップを取得しておくことが必要となります。
Salesforceのトランザクションは、地理的に異なるデータセンターに対してリアルタイムで複製されているため、ある地域で災害が発生しても、業務が継続できるような仕組みが用意されています。
しかし、ディザスタリカバリー以外の原因（操作ミスなど人的原因）により、データを削除・変更してしまった場合に元に戻すための方法はユーザ自身が用意する必要があります。
誤って一時的にレコードを削除してしまった場合については、ごみ箱の機能で復元するという方法もありますが、ごみ箱はいくつか制限もあるため、全体のバックアップとリカバリーとしては利用できません。
ごみ箱を使ったデータの復元について
Salesforceではレコードを削除した場合には、一時的に「ごみ箱」に格納され、15日間以内であれば「ごみ箱」から復元することができます。
しかし、ごみ箱の利用については、制約事項もあるため、以下の内容は理解しておく必要があります。
ごみ箱利用のポイント
- ごみ箱のレコードは、組織のストレージ使用量には含まれない
- ごみ箱は、組織のMB単位のストレージ容量の25倍をレコードとして格納可能（例：組織ストレージが2GBの場合、2,000MB＊25=5万レコード）が格納可能
- レコードが削除されてから15日間まで保存される（ただし、上記ストレージの制限によりレコード件数が格納可能数を超過する場合は、古いレコードから永久削除される）
- Apexプログラムなどのメタデータは削除しても「ごみ箱」には格納されない
Salesforce Classic と Lightning Experienceで異なります。詳細な内容を確認したい場合は、以下の公式サイトよりご確認ください。
Salesforce公式HELPサイト「Lightning Experience でのごみ箱の管理」
Salesforce公式HELPサイト「Salesforce Classic のごみ箱の表示、復元、管理
データ損失防止について
データを損失してしまう最大の原因は、人的ミスによるものです。Salesforceではデフォルトのシステム管理者では、全てのデータを編集したり削除する権限があります。運用で誤って、データを更新・削除してしまったりすることもあります。
また一般ユーザであっても、例えばデータのインポート処理で誤ったデータを一括で取り込んでしまい復元が不可能な状態となってしまったような事例があります。これらを抑止するための仕組みもSalesforceでは用意されています。データのバックアップと合わせて、対策を講じるとよいでしょう。
データ損失防止策（例）
- プロファイルによるデータアクセス制御：カスタムのシステムプロファイルを用意し、必要以上にデータの編集や削除ができないように権限を剝奪する。
- 一般ユーザも項目を編集させたくない場合には、項目レベルセキュリティを使って、「参照のみ」の権限に制限する
- 完全に更新させたくないオブジェクトに関しては、権限制御以外にもノーコードでできる対策として、入力規則等を使い更新できないように制御する
- 項目数が少ないオブジェクトに関しては、項目変更履歴をすべて設定しておくことで誤って更新した場合にも履歴の内容を参照して元の値に戻す（ただし全ての値が保存されるわけではないので注意が必要）
バックアップ対象と方式
バックアップ対象は、大きく以下の２種類があります。
Salesforceのバックアップ対象
- メタデータ（オブジェクト定義、カスタム項目、ページレイアウト、カスタムレポート、ダッシュボード、Apex などのカスタムコード、ワークフローなど）
- レコード（標準オブジェクト・カスタムオブジェクトのレコード）
Salesforceは、ノーコード（またはローコード）での開発が可能なサービスであり、メタデータ駆動型の開発モデルが採用されています。
オブジェクトや項目も画面上から設定だけで作成されますが、これらはメタデータとしてサーバ上に保存されています。Apexプログラムなどもメタデータとして保存されます。
そのため、これらのメタデータについても、レコードと同様にバックアップ管理対象とする必要があります。
※メタデータ駆動型の開開発について知りたい方は、以下、公式サイトを参照ください。
Salesforce公式HELPサイト「コーディング不要の開発」
バックアップ方式
Salesforceでは、バックアップ方式として以下の方式が提供されています。
| バックアップ対象 | 方式 | 利用方法 | 制限 |
| レコード | データエクスポート機能 | 画面上から毎週または毎月のスケジュールを設定し、データをCSV形式で定期的にエクスポートする。※ファイルも可能 | データ量が多いと時間がかかる。エクスポート後、24時間以内にダウンロードする必要がある。 |
| Dataloader（データローダ） | JavaアプリケーションのDataloaderをPC端末にインストールし、GUI上からデータのエクスポートを行う | Dataloaderのインストールが必要。手動での運用が必要（自動化は開発が必要） | |
| レポート | レポートを作成し、レポートのエクスポート機能を使ってCVSまたはExcel形式でダウンロードする | レポートの項目数の制限あり | |
| メタデータおよびレコード | Sandboxを作成 | 本番環境をコピーしてSandboxを作成することで実行日時点の断面のバックアップを作成することが可能 | レコードのバックアップについては、Full Sandboxが必要。また契約状況により利用可能なSandboxの種類や数量は異なるため注意 |
| メタデータ | Salesforce CLIを利用 | Salesforce CLI をインストールして利用することで、メタデータを取得する（Salesforce CLI 設定ガイド） | メタデータの最新版しか保存できないため、世代管理する場合には、Gitなどのバージョン管理システムを合わせて利用する必要がある。※メタデータの制限あり |
| Visual Studio Codeの拡張ツール | Salesforce CLI Integrationなどの拡張機能をインストールすることで、Salesforce組織認証を行い、最新のメタデータを取得する | メタデータの最新版しか保存できないため、世代管理する場合には、Gitなどのバージョン管理システムを合わせて利用する必要がある。※メタデータの制限あり | |
| workbenchの利用 | ワークベンチを利用して、本番組織からメタデータを取得してダウンロードする（REST API開発者ガイド） | ||
| 変更セット | リリースでも利用することが多い、変更セットを利用したバックアップ（バックアップ対象のメタデータを変更セットに格納する） | 変更セットに格納できないメタデータもあるため注意が必要 |
上記のほかには、ETLツールを使ってデータやメタデータを取得するような開発を行うことも可能です。
扱うデータの重要度や複雑性、またはバックアップ処理にかけられるコストなどを鑑みて、どの方法を採用するべきか検討するのがよいでしょう。
データのリストア（リカバリー）
データのリカバリーについては、少し複雑な手順が必要となります。
１．レコードの復元
レコードを復元する際には、以下の事項を理解しておく必要があります。
ポイント
- Salesforceではレコードを復元のために新規登録すると新しいSalesforceIDが設定されるため、元のSalesforceIDを使って復元することはできない。※IDを使っての上書き更新は可能
- 復元対象のオブジェクトのレコードに対して自動処理を行うトリガーや入力規則などが設定されている場合には、影響を考慮して、必要があれば復元時には無効化する。
- 他のオブジェクトとのリレーション（主従・参照関係）がある場合には、先に親オブジェクトを登録し、新規採番された親オブジェクトのSalesforce IDを利用して、子オブジェクトの紐づけを行う必要がある。
- レコードを復元する際、所有者を指定しないとデータ復元を行う作業者のIDになってしまうので注意。
- レコードの監査項目（作成日、作成者、最終更新日、最終更新者）の指定が必要な場合は「監査項目の作成」を有効化しておく必要がある。
標準機能を使ってレコードを復元する場合には、データインポートウィザード、もしくはDataloaderを利用する方法があります。
どちらの場合も、復元のためのCSVファイルを用意しておき、インポートをしてデータの復元を行います。
ただし、リレーションオブジェクトの場合には、先に親オブジェクトを登録して、登録時に採番されたSalesforce IDを使って、子オブジェクトのリレーションIDを変更しておく必要があります。
以下の図を使って説明します。
まず、取引先と取引先責任者のレコードをそれぞれCSVファイルにエクスポートしておきます。
※復元対象のデータは誤って削除されてしまったという前提（シナリオ）とします。
次に、Dataloader等を使って、親オブジェクトである取引先（Account）のレコードをインポートします。※新規登録する場合は、新しいSalesforceIDが採番されるため、SalesforceIDには既存のレコードのIDをマッピングすることはできません。
取引先のレコードを復元のため再度インポートすると新しいSalesforceIdが採番されます。
（旧ID）0015h00000Ue04LAAR → （新ID）0015h00000Ue04LXXX
つづいては、子オブジェクトのインポートとなりますが、その前に、親レコードのリレーションを再構築する必要があります。
エクスポートした取引先責任者（Contact）のCVSファイルを編集して、元のAccountIDから新しいAccountIDへ振り替えを行います。
※紐づけにはVlookup関数などを利用して紐づけを特定するため、検索キーとなる項目については必ず一意になる値とする必要があります。
重複する値がある項目を利用しないように注意しましょう。
新しい親レコードへのリレーションへ振り替えが完了したら、編集したCVSファイルを使ってインポート処理を行います。
外部IDを使ったインポート
親オブジェクトに外部ID項目を設定しておき、SalesforceIDを旧IDとして保存しておくことで、子オブジェクトから外部IDをキーにした参照関係を構築することができます。
以下のように親オブジェクト（取引先Account）に外部IDの項目を用意しておくことで、子オブジェクトは元のAccountIDを使ってそのまま紐づけをすることができます。
この方式を利用する場合には、あらかじめ外部ID項目を使って、レコード作成時にSalesforceIDを項目にセットするような項目自動更新などを合わせて設定しておく必要があります。
２．メタデータの復元
メタデータの復元は、以下のように行います。
- 変更セットを利用してバックアップを作成している場合は、変更セットを本番環境へリリースする。
- VisualStudioCodeやCLIでバックアップしている場合には、最新のバックアップファイルを使って、本番環境へメタデータをデプロイする。
本番リリース作業手順書などに、障害発生時の切り戻し手順など記載する場合には、メタデータの復元方法についても記述しておきましょう。
バックアップ・リカバリに関する公式サイトの情報
Salesforce公式HELPサイト「Salesforce データのバックアップのベストプラクティス」
まとめ
セールスフォースのデータバックアップとリストアについてご理解いただけましたでしょうか。
具体的な設定や作業手順なども今後記事にしていく予定です。
