SAP Operations

SAPシステムコピーとリフレッシュの基本概念と安全な運用手順

SAP本番環境を検証・開発環境へコピーするシステムコピーとリフレッシュについて、目的の違い、事前確認、データ匿名化、接続先の分離、完了後の検証を実務の流れに沿って解説します。

SAPシステムコピーとリフレッシュの運用フロー計画からコピー後検証までの主要な管理ポイントを示すSAPシステムコピーとリフレッシュの運用フロー計画からコピー後検証までの主要な管理ポイントを示す承認済み範囲復元済みシステム安全なコピー先テスト準備完了対象範囲を決めるコピー元・先、停止時間、デ…バックアップと復元バックアップの利用可能性…接続を分離す利用開始前に外部宛先を変…機密データを保護するテスト利用開始前にデータ…運用を検証すデータベース、アプリケーシ…CertPas オリジナル図解
対象範囲の決定から運用検証までを示すSAPシステムコピー・リフレッシュの流れ
目次
  1. システムコピーとリフレッシュの違い
  2. コピー前に確定する対象範囲
  3. バックアップと復元の計画
  4. コピー後の接続分離
  5. 論理システムと環境情報の再設定
  6. 機密情報の匿名化と削除
  7. 完了後の検証チェック
  8. 運用に組み込むための判断基準

本番のSAPシステムを検証環境や開発環境へ複製すると、障害再現、回帰テスト、性能検証、移行準備を本番データに近い条件で実施できます。一方で、コピー先が本番と同じ接続先やジョブ設定を持つと、意図しない伝票登録、メール送信、外部連携が発生します。作業の中心はデータを複製することではなく、複製後に安全な環境として再構成することです。

この記事では、SAP ERPやSAP S/4HANAのアプリケーション層と、SAP HANA on-premiseを含むデータベース層を対象に、計画から検証までの実務上の要点を整理します。

システムコピーとリフレッシュの違い

システムコピーは、あるSAPシステムを別のシステムとして新しい環境へ複製する作業です。コピー先には新しいシステムID、ホスト名、論理システム名、接続先、ユーザー管理方針を設定します。新規の検証環境を作る場合や、既存環境を別用途へ展開する場合に適しています。

リフレッシュは、既存の検証・開発環境へ本番または別の基準システムのデータを再投入し、内容を更新する運用です。環境の役割や基本構成は維持しながら、データを新しい状態へ置き換えます。テストサイクルごとに同じ環境を更新する場合は、リフレッシュとして計画すると関係者の合意を得やすくなります。

両者に共通する作業は、停止時間の確保、バックアップ、データベース復元、接続先の切り替え、ジョブとインターフェースの制御、アクセス権確認です。呼び方よりも、コピー後にどの設定を引き継ぎ、どの設定を変更するかを作業計画に明記することが重要です。

システムコピーとリフレッシュの比較それぞれの運用パターンを使う場面を整理するシステムコピーとリフレッシュの比較それぞれの運用パターンを使う場面を整理する必要必要システムコピー固有の識別情報と接続先を…リフレッシュ既存の非本番環境のデータ…共通の管理双方でバックアップ、接続…CertPas オリジナル図解
システムコピーとリフレッシュ、および共通する運用管理を比較する図

コピー前に確定する対象範囲

最初に、コピー元、コピー先、実施日時、停止時間、対象クライアント、保存期間、責任者を決めます。コピー対象には、データベースだけでなくアプリケーションサーバー、共有ファイル、インターフェース定義、ジョブ設定、プリンタ設定、証明書、暗号鍵の扱いも含めます。

SAP HANA on-premiseをデータベースとして使用する場合は、SAP HANA cockpitまたはSAP HANA database explorerでデータベースの状態、バックアップ履歴、容量、アラートを確認します。SAP HANAのバックアップと復旧については、SAP HANAバックアップとリカバリの基本も参照できます。

次の情報を一覧化すると、抜け漏れを減らせます。

  • コピー元とコピー先のシステムID、インスタンス、ホスト
  • SAP HANAデータベースのバックアップ取得時刻と復元ポイント
  • RFC宛先、HTTP接続、メール、EDI、外部APIなどの通信先
  • バックグラウンドジョブ、イベント、出力制御、プリンタ
  • ユーザー、ロール、技術ユーザー、証明書、秘密情報
  • 本番データを扱う担当者と、コピー先へのアクセス承認
  • コピー後に実行する匿名化、マスキング、削除処理

本番データをコピー先へ持ち込む場合は、個人情報、取引先情報、価格、銀行情報、認証情報を扱う範囲を事前に承認します。テストに不要なデータは、コピー前の抽出条件やコピー後の削除処理で対象外にします。

コピー後の安全確認コピー後に優先すべきリスク確認を案内するコピー後の安全確認コピー後に優先すべきリスク確認を案内する次に次に次に承認後データベース稼働SAP HANA cockpitとdatab…外部通信を制RFC、HTTP、ファイル、メ…ジョブを確認コピー先に必要なジョブだ…機密データを保護匿名化、マスキング、削除…テスト利用を開始技術・業務検証の結果を記…CertPas オリジナル図解
データベース、接続、ジョブ、機密データ、テスト開始を確認するコピー後の安全確認フロー

バックアップと復元の計画

コピー元では、データベースの完全バックアップ、必要なログバックアップ、ファイルシステム上の設定バックアップを取得します。バックアップが完了した時刻、保存先、保持期間、復元テストの結果を記録し、復元に必要な暗号鍵やパスワードを担当者だけが参照できる状態にします。

SAP HANAのバックアップを扱う場合は、バックアップの成功表示だけでなく、復旧可能性を確認します。SAP HANA cockpitのバックアップ画面やSAP HANA database explorerで、対象データベース、バックアップ種別、開始・終了時刻、保存先を確認します。ログバックアップの運用は、SAP HANAログバックアップの確認ポイントに整理されています。

暗号化を使用している場合、データボリューム暗号化、ログボリューム暗号化、バックアップ暗号化はそれぞれ別に管理します。ルートキーは必ずバックアップし、設定変更後は再度バックアップします。変更後のバックアップがないルートキーではバックアップを復旧できず、復旧不能につながります。

コピー先に復元する前に、必要な容量、ファイルシステム、権限、マウント、名前解決、時刻同期を確認します。復元処理の開始条件と、容量不足やバックアップ破損が発生した場合の中止条件も決めておきます。

コピー後の接続分離

復元直後のシステムは、本番と同じ接続情報やスケジュールを保持している可能性があります。アプリケーションを通常稼働させる前に、外部通信を停止または検証用の宛先へ変更します。

特に確認する対象は、RFC宛先、Webサービス、メールサーバー、ファイル転送、銀行・決済連携、EDI、監視通知、チケット連携です。検証環境から本番へ向かう通信は、ネットワーク制御とアプリケーション設定の両方で遮断または置換します。

バックグラウンドジョブは、コピー直後に一括で有効化せず、ジョブごとに用途と宛先を確認します。本番専用の請求、支払、出荷、在庫連携、メール送信ジョブは停止し、検証用に必要なジョブだけをスケジュールします。ジョブ監視の観点は、SAPバックグラウンドジョブ監視の実務で確認できます。

SAP HANA on-premiseの環境では、SAP HANA cockpitの登録対象、通知先、監視ユーザーも確認します。コピー元とコピー先が同じ監視対象名を使うと、アラートの誤認や担当者への重複通知が起きるため、表示名と通知ルールを環境ごとに分けます。

論理システムと環境情報の再設定

SAPシステムを別環境として使用するには、論理システム名、システムID、ホスト名、プロファイル、インスタンス情報をコピー先の実体に合わせます。論理システム名が重複した状態で連携を開始すると、IDocやRFCの宛先を誤る可能性があります。

コピー後は、次の順序で環境情報を確認します。

  1. OS、ホスト名、名前解決、時刻同期を確認する
  2. SAPインスタンスとSAP HANAデータベースの稼働状態を確認する
  3. システムID、論理システム名、クライアント設定を確認する
  4. RFC、HTTP、ファイル、メールの接続先を検証用に変更する
  5. ジョブ、出力、プリンタ、監視通知を環境別に調整する
  6. 接続テストを実施し、通信ログとアプリケーションログを確認する

SAP HANAの起動・停止を含む作業では、システム全体とテナント単位の操作を区別します。SAP HANA 2.0は、システムデータベースとテナントデータベースで構成されるマルチテナントシステムです。コピー先のデータベース構成を確認する場合は、SAP HANA cockpitまたはSAP HANA database explorerを使用します。

機密情報の匿名化と削除

本番データを検証へ持ち込む場合、コピー後すぐに機密情報の保護処理を実施します。対象は、氏名、住所、電話番号、メールアドレス、銀行口座、税番号、取引先担当者、価格条件、認証情報、アクセストークンなどです。

匿名化では、テストで必要な形式や桁数を維持しながら、実在の人物や企業を特定できない値へ置換します。関連テーブル間のキーや参照関係を壊すとテストが成立しないため、同じ対象には一貫した置換規則を適用します。ランダム化、固定値置換、部分マスキング、削除のどれを採用するかは、項目ごとに決めます。

匿名化処理の前後で、次の検証を行います。

  • 直接識別子と組み合わせによる再識別リスク
  • テストに必要な件数、日付範囲、ステータスの維持
  • IDoc、帳票、RFC、ファイル出力に残る機密情報
  • ログ、トレース、バックアップ、添付ファイル内の情報
  • 技術ユーザーのパスワード、証明書、トークンの再発行

本番と同じパスワードや秘密鍵をコピー先で使い続けないことも重要です。コピー先の管理者、開発者、テスターに付与する権限は、用途に必要な範囲へ限定します。

完了後の検証チェック

コピー作業の完了は、データベースが起動した時点ではなく、業務処理と安全制御を確認した時点と定義します。担当者、確認日時、結果、証跡をチェックリストへ残します。

技術検証では、SAP HANA cockpitでデータベースの状態、容量、アラート、バックアップを確認し、SAP HANA database explorerで接続と基本的な参照を確認します。アプリケーション側ではログオン、主要トランザクション、バッチ、印刷、ファイル出力、RFC疎通を検証します。

業務検証では、代表的な受注、購買、在庫、請求、会計、承認のシナリオを、実際のテストデータで実行します。外部システムへ送信されないこと、検証用のメールやファイルへ出力されること、ロールに応じたアクセス制御が働くことを確認します。

本番稼働への影響を抑えるため、作業後に次の記録を保存します。

  • 使用したバックアップと復元時刻
  • 変更したホスト名、システムID、論理システム名、接続先
  • 停止・再開したジョブとインターフェース
  • 匿名化・削除の対象、処理結果、検証者
  • ルートキーと秘密情報のバックアップ確認
  • 未解決の警告、既知の制限、次回リフレッシュへの申し送り

運用に組み込むための判断基準

単発のシステムコピーとして扱うか、定期リフレッシュとして扱うかは、環境の目的と更新頻度で判断します。定期的に本番データを取り込む環境では、実施申請、データ保護承認、バックアップ、匿名化、接続確認、利用開始承認を一つのワークフローにまとめます。

リフレッシュのたびに手作業で設定を戻すと、漏れや環境差分が蓄積します。接続先、ジョブ、出力、監視、ユーザー、匿名化規則を管理台帳に登録し、変更履歴を残します。SAPのバージョンや保守状況を確認する作業は、SAPバージョン確認の実務手順と組み合わせると、前提条件を整理しやすくなります。

保守作業やアップデートと同時期にリフレッシュする場合は、順序と責任範囲を分けます。保守パッケージ適用の計画は、SAPサポートパッケージ適用の進め方を参照し、コピー元とコピー先でソフトウェア状態が一致しているかを記録します。

システムコピーは、バックアップを復元する技術作業だけではありません。データ保護、外部通信の遮断、論理システムの再設定、ジョブ制御、権限管理、業務検証を一体として実施することで、検証環境を安全に利用できます。

ブログ一覧へ戻る