ServiceNowのインスタンスをクローンする際、ソースインスタンスのデータでターゲットインスタンスのデータを上書きしたくないという時があると思います。
私が過去に体験したケースでは、本番環境から開発環境へクローンを実施したところ、API連携先の設定も本番環境の内容で上書きされてしまうということがありました。
その結果、開発環境で動作確認を行った際に、誤って連携先システムの本番環境へアクセスしてしまう事象が発生しました。。
このような事象を防ぐために、「Clone Data Preservers（データ保存）」や「Clone Exclude Tables（除外テーブル）」を設定している方も多いのではないでしょうか。
本記事では、クローン時の除外テーブルとデータ保存の違い、および両者をどのように使い分けるべきかを解説します。
クローン時に発生するデータの上書き
本番環境から開発環境へクローンを実施すると、基本的には本番環境のデータが開発環境へコピーされます。
そのため、DEV環境で独自に作成していたレコードや設定が本番環境に存在しない場合、本番環境のデータで上書きされてしまったり、失われてしまう可能性があります。
特に以下のようなデータは、環境ごとに異なる内容を保持したいケースが多くあります。
- DEV環境専用の設定データ
- テスト用のマスタデータ
- 開発用の接続先情報
このようなデータを保護するために利用されるのが、「除外テーブル」と「データ保存」です。
除外テーブル（Clone Exclude Tables）とは
除外テーブルは、指定したテーブルをクローン対象から除外する機能です。
例えば、あるテーブルを除外テーブルに設定すると、本番環境のデータはクローン時にコピーされません。
一見するとこれだけで問題ないように思えますが、実際には注意点があります。
クローン対象から除外されるということは、「本番環境のデータをコピーしない」だけであり、クローン処理によって失われたデータを元に戻してくれるわけではありません。
そのため、「除外テーブルを設定したからDEV環境のデータも保持される」と考えていると、想定どおりの結果にならない場合があります。
データ保存（Clone Data Preservers）とは
一方で、データ保存は、クローン前に対象レコードをバックアップし、クローン後に復元する機能です。
クローン前に DEV環境のデータを保持しておき、クローン完了後にそのデータを書き戻すため、環境固有のデータを維持することができます。
つまり、DEV環境で保持しておきたいレコードがある場合は、データ保存を設定することで、クローン後もそのまま利用できます。
除外テーブルだけでは不十分なケース
例えば、DEV環境で独自に管理している設定テーブルがあるとします。
このテーブルに対して除外テーブルのみを設定した場合、本番環境のデータはコピーされません。
しかし、DEV環境のデータを確実に保持したいのであれば、データ保存も設定しておく必要があります。
データ保存を設定しておくことで、クローン前の状態がバックアップされ、クローン後に復元されるため、環境固有のデータを維持できます。
使い分けのポイント
除外テーブルとデータ保存は、どちらか一方を設定すればよいというものではありません。
環境固有のデータを保護したい場合は、それぞれの役割を理解したうえで設定することが重要です。
| 機能 | 役割 |
|---|---|
| Clone Data Exclusion | 指定したテーブルをクローン対象から除外する |
| Clone Data Preservers | クローン前のデータをバックアップし、クローン後に復元する |
特に、「クローン後も開発環境のデータをそのまま残したい」という要件がある場合は、データ保存の設定も忘れずに確認しましょう。
まとめ
クローン時のデータ保護というと「除外テーブル」を思い浮かべる方が多いかもしれません。
しかし、環境固有のデータを維持したい場合は、除外テーブルだけでは十分ではなく、データ保存（Clone Data Preservers）もあわせて設定することが重要です。
クローンの目的や保持したいデータに応じて、除外テーブルとデータ保存を適切に使い分けることで、クローン後の想定外のデータ消失を防ぐことができます。
是非参考にしてみてください。