ServiceNowで業務データや開発物をうっかり消してしまったことはないでしょうか。そんな場合に復元する方法を説明します。
うっかりデータ・レコードを消してしまった時に行うこと・行ってはいけないこと
行うこと① ほとんどの場合復元方法はあるので、まず落ち着く
うっかりデータを消してしまい、慌てて復元方法を探してこの記事にたどり着いた方がいるかもしれません。その場合、あなたデータを消してしまってから1週間以内であればほぼ間違いなく戻す方法は存在しますし、1週間以上たっていても戻す方法があるかもしれないので、まずは落ち着いて次の項目を確認し、不用意なオペレーションによる二次被害を起こさないようにしましょう。
行うこと② 業務影響の確認と影響を受けるステークホルダへの連絡
これはあらゆるミスに共通して言えることですが、うっかりデータ・レコードを消してしまった場合は、まずは業務影響、つまり誰が困るか・誰に迷惑がかかるかを確認します。
業務影響の確認を行う観点としては次のようなものが考えられます。
- そのデータ・レコードを利用している人、機能がないか
- そのデータ・レコードに依存する/そのデータ・レコードを参照するデータを利用している人、機能がないか
業務影響の確認が終わったら、影響を受けるステークホルダへ連絡します。影響の確認が長引きそうな場合は、必要に応じて概要レベルを中間報告するなども検討します。
事態を何事もなく収めるために、黙って解決しようとするのはやめた方がよいです。データに不整合が起こっている場合、ユーザが業務継続し新たなデータが作成されることで影響が拡大したり、復旧が困難になる可能性があります。
行うこと③ （必要に応じて）復元前の状態の保存、復元すべきデータ・レコードの洗い出し
これからデータ・レコードを復元するわけなのですが、復元がきちんとされたことを検証するためには、復元前がどんな状態で、復元すべきデータ・レコードは何なのかを明確にしておく必要があるでしょう。
特に、本番環境でデータ・レコードを消してしまった場合は、復元の検証をするためにも、その証跡を残すためにも必要になると思われます。
行ってはいけないこと④ Update Setをいじる
これは開発者・運用者向けですが、うっかり開発物を消してしまったからと言ってUpdate Setをいじってはいけません。Update Setに含まれる削除履歴を消しても削除自体はなかったことになりません。さらに悪いことに、基本的にUpdateレコードは1つのオブジェクトに対して1つ作られ、削除も含めそれが更新されていくため、削除履歴を表すUpdateレコードを消してしまうと、そのオブジェクトを作った・更新したという履歴もまとめて消してしまうことになる可能性があります。
削除データ・レコードの復元方法
エンドユーザである場合は運用者に連絡する
あなたがServiceNowのエンドユーザである場合（ServiceNowを使ってインシデントや各種タスクを受け付けて処理していたり、申請や申請を行っていたりする場合）は、データ・レコードを復元するために十分な権限を与えられていない可能性が高く、自力で復元する方法は基本的にありません。そのため、運用者に連絡してください。
（運用者向け）トランザクショナル（業務）データの復元方法
Rollback & Recovery > Rollback Contexts（ロールバックおよび復旧 > ロールバックコンテキスト）メニューから復元する
ユーザからデータ復元の依頼を受けた、または何らかの運用作業時にデータを消してしまった場合には、Rollback & Recovery > Rollback Contexts（ロールバックおよび復旧 > ロールバックコンテキスト）メニューより、データの復元を行うことができます。
復元手順
- Rollback & Recovery > Rollback Contexts（ロールバックおよび復旧 > ロールバックコンテキスト）メニューにアクセスする
- 削除時間などから、該当するRollback Contextレコードを探して開く
- 復元したいデータが含まれているかを確認する
- 関連リンク”Rollback”をクリックする
復元の具体例
下図の、1つの子インシデントを持つインシデントレコードをを削除してしまった場合に復元する例を示します。
このインシデントレコードを削除すると、下図のように子インシデント側にも更新が行われ、親インシデントが空になります。
Rollback & Recovery > Rollback Contexts（ロールバックおよび復旧 > ロールバックコンテキスト）メニューにアクセスし、削除時間等から該当するRollback Contextレコードを探します。
Rollback Contextレコードの関連リスト”Rollback Records”には、削除されたレコードと、それに伴い更新されたレコードが記載されています。復元対象に間違いないことを確認し、関連リンク”Rollback”を押下して復元を行います。警告が表示されるので、メッセージに従い”yes”を入力し、”OK”ボタンを押下します。
以上で、無事親のインシデントレコードおよび子インシデントレコード側の参照が復元されます。
Rollback & Recovery > Rollback Contextsメニュー、Rollback & Recovery > Delete Recoveryメニュー、System Definition > Deleted Recordメニューでできることは同じ
ServiceNowのデータの復元について調べると、次の3つのメニューから復元する手順が見つかるかもしれません。
- Rollback & Recovery > Rollback Contexts
- Rollback & Recovery > Delete Recovery
- System Definition > Deleted Record
結論としては、どれも結局はRollback Sequence [sys_rollback_sequence]に繋がっており、機能に違いは無いため、Rollback & Recovery > Rollback Contextsだけ覚えておけばOKです。
（開発者向け）開発物（アプリケーションファイル）の復元方法
Deleted Application File[sys_metadata_delete]レコードから復元する
ServiceNowにおける開発物（アプリケーションファイル）、つまりUIポリシーや通知（Notification）、ビジネスルール（Business Rule）など、Application File[sys_metadata]を継承しているテーブルのレコードを削除してしまった場合は、Deleted Application File[sys_metadata_delete]レコードから復元することができます。記事執筆時点のTokyoバージョン現在はこのテーブルにアクセスするためのメニューが用意されていないので、アプリケーションナビゲータから”sys_metadata_delete.list”と打ち込み、直接アクセスする必要があります。
復元手順
復元手順としては次の通りです。
- アプリケーションナビゲータから”sys_metadata_delete.list”と打ち込みDeleted Application File[sys_metadata_delete]テーブルのリストにアクセスする（下図参照）
- 削除した開発物（アプリケーションファイル）を選択する
※ 紐づく複数の開発物を同時に削除した場合は、削除を行った親のレコードを選択する - 復元したい開発物が含まれているかを確認する
- “Restore File”ボタンを押下する
復元の具体例
下図の、1つのUI Policy Actionが紐づくUI Policyを削除してしまった場合に復元する例を示します。
このUI Policyを削除すると、そのUI Plicyに紐づくUI Policy Actionも同時に削除されます。
Deleted Application File[sys_metadata_delete]テーブルのリストを確認すると、削除された2つのアプリケーションファイルを確認できます。
UI Policy（親）側の削除レコードを開くと、UI Policyと、同時に削除されたUI Plicy Actionが表示されます。
復元対象に間違いないことを確認し、画面上部の”Restore File”ボタンを押下して復元を行います。この際、同時に削除された関連ファイルごとまとめて復元する必要があるため、必ず親レコードから復元を行うようにします。
以上で、無事親のインシデントレコードおよび子インシデントレコード側の参照が復元されます。
Rollback & Recoveryメニューからは復元できない
なお、ログや開発物（アプリケーションファイル）などのシステム管理情報が格納されている”sys_”から始まるテーブルは、Rollback & Recoveryで復元できるAudit関連テーブルに削除履歴が保存されないため、復元できません。（参考: Use the Deleted Records module to restore a deleted record）
ただし、sys_userなど、”sys_”から始まるものでもトランザクショナル（業務）データが格納されるテーブルについては、システムプロパティ”glide.ui.audit_deleted_tables”によって、例外的に削除履歴を保存する設定になっており、これらのテーブルのレコードはRollback & Recoveryから復元します。（参考: Enable auditing for a system table）
最終手段: ServiceNow社にリカバリを依頼する
基本的には上述の手順でデータ・レコードを復元することができますが、トランザクショナル（業務）データ削除から一週間以上経過していた場合や、削除履歴を保存しない設定になっていた場合、復元することができません。その場合は、最終手段として、ServiceNow社にリカバリを依頼するという手があります。
バックアップリストア
ServiceNowのインスタンスは週次でフルバックアップが、日次で差分バックアップが取得されており、週次バックアップは4世代=28日分、差分バックアップは6世代=6日分（週次フルバックアップと合わせて1週間前までは一日単位でのリストアが可能）されています。そして、NowSupport（ServiceNowのカスタマサポートサイト）からバックアップのリストアを依頼することができます。（参考: Instance Backup and Recovery）
なお、バックアップのリストアを行うと、インスタンスのあらゆるデータがバックアップ取得時点まで戻ってしまうことに注意が必要です。そのため、上記ドキュメントにも”最後の手段(last resort)”と記載されています。
リカバリ後の対応
リカバリの検証
リカバリ後は、事前に取得していた影響範囲やリカバリ対象データと突き合わせながら、正しくリカバリが行われているかを確認します。
影響を受けていたステークホルダへの周知
こちらも当然ですが、影響を受けていた人への周知を行いましょう。業務ユーザ（エンドユーザ）への周知を忘れることはないと思いますが、開発者同士などでも忘れないようにしましょう。
以上です。
コメント