Salesforceのバックアップは必要？重要性や方法を解説！

はじめに

顧客リストはもちろんのこと、自社の製品やサービスに関する各種営業データは、企業にとって重要な資産といえます。自社管理している場合はもちろん、クラウド上のサーバなどに保存している場合でも、万が一のデータ損失に備えてバックアップを取っておくことが重要です。あらゆるビジネス関連データを入力・更新し続けているSalesforceにおいても、データのバックアップは重要課題の1つです。そこで今回は、Salesforceにおけるバックアップの重要性やバックアップの方法について解説します。社内のシステム担当者は必読です。
 
また、システム担当者の方はこちらの資料「システム管理者必見！数式項目の留意点　よくある数式の活用例」もご活用ください。

Salesforceのバックアップの必要性

重要な業務関連データを損失する理由は、大きく3つあります。1つ目は、自然災害などによる自社、またはデータを預けているデータセンターやクラウドサーバ運営会社のシステム損壊です。日本の場合、2011年3月に発生した東日本大震災の影響で自社システムを失い、BCP（事業継続計画）が困難になった企業が複数発生しました。
損失理由の2つ目は、システムそのもののエラーやサイバー攻撃によるデータ消失です。オンプレミスであれSaaS形式のクラウドサービスであれ、データを管理・保存しているシステムに重大なトラブルの発生や、サイバー攻撃による被害で、データの一部あるいは全部を損失するリスクは否定できません。
事実、近年は、ハッカー集団によるランサムウェア攻撃で、関西エリアの基幹病院が全ての診療データを暗号化され、診療業務がストップしてしまった事例が各種メディアで報じられました。
そして3つ目が、内部の人的ミスです。社員が悪意を持ってデータを消す事例もまれにありますが、意外に多いのが、誤操作によるデータ削除です。Salesforceの場合はとくに、デフォルト状態ではシステム管理者が全データを削除する権限をもっており、データ削除権限をもたない一般ユーザでも、データのインポート処理で誤ったデータを一括で取り込み・上書きし、復元が不可能になる場合もあります。
Salesforceのトランザクションは、地理的に異なるデータセンター間（東京・神戸など）でリアルタイム同期されているため、一方のデータセンターが自然災害やシステムエラーでデータを損失しても、もう一方のセンターのデータで業務を継続できる冗長性が整えられています。しかし人間の誤操作をシステム的に抑止するのは困難です。以前は、Salesforceのバックアップサービスが展開されていましたが、諸般の事情から、2020年7月で同サービスが取り止めとなりました。
レコードを削除した場合は一時的にゴミ箱に格納され、15日以内であれば復元可能です。しかし、Apexプログラムなどのメタデータは、削除してもゴミ箱には格納されないほか、ごみ箱に格納可能なレコードは組織のMB単位のストレージ容量×25で、レコード件数がそれを越えた場合は古いレコードから永久削除される…などの制約事項があるため、注意が必要です。
いずれにせよ、操作するのが人間である以上、誤操作を100％抑止することは不可能です。Salesforceは統合型のCRM（顧客関係管理）システムのため、バックアップを取っておらずデータを正常な状態に戻せなければ、ビジネス戦略に多大な悪影響をもたらすことになります。Salesforceのデータバックアップの必要性について再認識し、万が一のトラブルに備えておきましょう。

Salesforceのバックアップ対象について

Salesforceはマルチテナント・アーキテクチャ（1つのシステムの中に複数企業のサービスを同居させ、リソースや運用コストを大幅に低減する方式）を採用しています。そして、ノーコードあるいはローコードでの自社専用アプリが開発できるよう、メタデータ駆動型アーキテクチャが採用されています。
つまり、各ユーザのあらゆるレコード（データ）を、データの説明書であるメタデータで管理するシステムのため、膨大な情報を整理しやすいわけです。Salesforceのバックアップ準備に向けて、データとメタデータとの違いについて確認しておきましょう。

データとメタデータの違い

データ
データとは、取引先、取引先責任者、リード、商談、ケース、契約書、他のレコードなど、ユーザのすべてのレコードを意味します。カスタムオブジェクトレコード、ファイル、コンテンツ、Chatter も、データに含まれます。

メタデータ
メタデータとは、カスタム項目、ページレイアウト、カスタムレポート、ダッシュボード、Apex や Visualforce のようなカスタムコードなど、設定情報を示します。

画面上からの設定で作成されるオブジェクトや項目、Apexプログラムなども、メタデータとしてサーバ上に保存されています。そのため、人的ミスによるデータ損失に備えるためには、データ、メタデータともにバックアップが必要です。

データ・メタデータのバックアップ方法について

Salesforceのバックアップの基本は、データをCSVファイルなどとして定期的にエクスポートし、保存するやり方です。
データ（レコード）、メタデータのバックアップのために、Salesforceにはデータローダをはじめとする様々な機能が標準で準備されていますので、それぞれ解説します。

データ（レコード）のバックアップ

データエクスポート機能
設定画面から、毎週または毎月のエクスポートをスケジュールできて、データはCSV形式で出力されます。ファイルもエクスポート可能ですが、データ量が多い場合は時間がかかります。また、エクスポート完了後、24時間以内にダウンロードする必要があります。

＜データのエクスポート＞

データローダ
Javaアプリケーションであるデータローダをパソコンにインストールし、エクスポートするやり方です。Soap APIやBulk APIの使用制限があり、定期実行するには自社での開発が必要です。また、オブジェクトごとのエクスポートが必要です。

＜データローダ＞

レポートのエクスポート
レポートを作成し、結果をエクスポートするやり方で、定期実行はできません。また、項目数などレポートの制限が適用されます。

＜レポートのエクスポート＞

フルSandbox
Unlimited Editionの契約、あるいはフルSandboxを購入し、本番環境の（データ・メタデータなどを含む）コピーを作成するやり方です。更新できるのは29日ごとです。

メタデータのバックアップ

変更セット
設定画面から、バックアップ対象のコンポーネントを変更セットに追加・送信することで、本番組織のメタデータがSandboxに送信されます。ただしコンポーネントによっては、変更セットに追加できないものがあります。

＜変更セット＞

Visual Studio Codeの拡張ツール
Salesforce CLI Integrationなどの拡張機能をインストールすることでSalesforce組織認証を行い、最新のメタデータを取得する方法です。メタデータの最新版しか保存できないため、世代管理する場合にはGitなどのバージョン管理システムを合わせて利用する必要があります。

Workbench（ワークベンチ）の利用
Workbench（ワークベンチ）を利用して、本番組織からメタデータを取得してダウンロードするやり方です。

バックアップしたデータのリストア方法

バックアップと同様、バックアップデータをリストア（リカバリー）する場合も、データとメタデータそれぞれのやり方があります。
ただし、レコード（データ）のリストア時には注意しておくべき点がいくつかありますので、以下を参照ください。

メタデータのリストア方法
Sandboxの作成や更新でバックアップしたメタデータをリストアする場合は、変更セットを使用します。あるいは、Visual Studio Codeを使用して一旦ローカルディレクトリにダウンロードした後、そのメタデータを本番環境へアップロードします。

レコード（データ）のリストア方法
レコードのリストアは、まずリストア用のCSVファイルを準備し、インポートしてから行います。Salesforceの標準機能であるデータインポートウィザード、またはデータローダを利用する方法がありますが、以下の点に注意が必要です。

データをリストアする際の注意点

• ・レコードのリストア時、元のSalesforce IDを指定することはできません
• ・他レコードとのリレーションがあるデータをリストアする場合、主から従の順番で復元します
• ・レコードのリストア時に監査項目（作成日、作成者、最終更新日、最終更新者）を指定する場合、「監査項目の作成」を有効化することで実施できる場合があります
• ・履歴情報などリストアできないデータもあります
• ・APIを使用してリストアする場合、24時間あたりのAPI コール数の上限があります
• ・レコード作成時に設定された自動処理（プロセスビルダー、トリガー、入力規則など）がある場合は無効にします
• ・リストア時、他システムとのインテグレーションに影響はないか事前に確認しておきましょう

リレーションオブジェクトをリストアする方法

他レコードとのリレーションがあるデータをリストアする場合は、主から従の順番で行う必要があります。主オブジェクトを先に登録し、そこで採番されたIDを使って従オブジェクトのリレーションIDを変更します。たとえば、主オブジェクトが「取引先」、従オブジェクトが「取引先責任者」だった場合、以下の手順で進めます。

（1）「取引先」と「取引先責任者」のレコードを、それぞれCSVファイルとしてエクスポートします。

＜「取引先」と「取引先責任者」のレコードを、それぞれCSVファイルとしてエクスポート＞

（2）データローダ等を使用し、主オブジェクトである「取引先」のレコードをインポート。新規登録の際に新しいSalesforce IDが採番されるので、レコードの既存IDをマッピングすることはできません。

＜主オブジェクトである「取引先」のレコードをインポート＞

（3）従オブジェクト「取引先責任者」をインポートする前に、エクスポートしておいた従オブジェクトのCSVファイルを編集し、新しいIDへ振り替えを行って主レコードのリレーションを再構築します。

＜エクスポートしておいた従オブジェクトのCSVファイルを編集＞

（4）新しい主レコードへの振り替えが完了したら、編集したCSVファイルをインポートします。

なお、外部IDを使ったインポートも可能です。主オブジェクトに外部ID項目を設定しておき、Salesforce IDを旧IDとして保存しておくことで、従オブジェクトから外部IDをキーにした参照関係を構築できます。
この方法を利用する場合、あらかじめ外部ID項目を使用し、レコード作成時にSalesforce IDを項目にセットするような項目自動更新などを、同時に設定しておく必要があります。

＜編集したCSVファイルをインポート＞

まとめ

今回は、Salesforceのバックアップの概要や方法について紹介しました。CRMツールに保存されている顧客との営業関連データは、企業にとって資産の1つです。万が一に備え、定期的なバックアップが必要不可欠といえるでしょう。
それでも難しい、やり方がわからない…といった困りごとがありましたら、ご相談ください。当社には300名（23年5月時点）を超える専門コンサルタントが在籍し、お客様側の視点からSalesforceのサポートサービスを行っています。効率的なSalesforceの活用を、当社のカスタマーサクセスチームがサポートいたしますので、お気軽に無料相談からお問い合わせください。