はじめに
この記事はUiPathブログ発信チャレンジ2022サマーの14日目の記事です。
昨日は@kou12092さんの記事、明日は@hjmkzkさんと@myoshidanの記事です。
Orchestratorを使用する際、便利なCloud版を使用することもできますが、何らかの制約でオンプレミス環境で構築するケースもあります。
オンプレミス環境で構築した場合、運用設計を諸々考える必要があります。
今回は運用設計の内、バックアップについてまとめます。
その他の記事
監視編
メンテナンス編
前提
- On-Prem Orchestrator 2021.4
構成は冗長化（Active-Standby）したもの仮定します。
※シングル構成で仮定してもOKです。HA構成（Active-Active）だと構成要素が変わるため（Redisのクラスター構成が追加）、本記事より運用も複雑になります。
1. バックアップの基本的な考え方
バックアップの設計では、まず RPO（目標復旧地点）を決定することが重要です。RPOを決定することで、復旧モデルやバックアップ手法を検討できます。頻繁にバックアップを取ることで、RPOを短くすることが可能ですが、運用作業・リストアの複雑化や、必要なディスクサイズが大きくなったりし、コストが増大します。業務の重要性などに応じて、RPOを適切に決める必要があります。経験上、RPAの場合、障害時は何らかの代替手段（人でリカバリするなど）が存在するので、RPOは比較的に長めに取ることが多いと思います（最大24時間とか）。
2. APサーバのバックアップ
APサーバの場合、以下のファイル、フォルダをバックアップします。
AWS（EC2）などを使用している場合は、インスタンスのスナップショットやAMIの取得となります。
設定ファイル
C:¥Program Files (x86)¥UiPath¥Orchestrator¥Web.config
C:¥Program Files (x86)¥UiPath¥Orchestrator¥UiPath.Orchestrator.dll.config
パッケージ（ライブラリ）やストレージバケット ※デフォルトの設定の場合
C:¥Program Files (x86)¥UiPath¥Orchestrator¥Storage
C:¥Program Files (x86)¥UiPath¥Orchestrator¥NuGetPackages （旧verからアップデートした場合に存在します）
※設定を変更することでAWSやAzureのストレージにファイルを保存することができます。その場合のバックアップは保存先のクラウドサービスの機能を使います。
3. DBサーバのバックアップ
DBサーバの場合、一般的なSQL Serverのバックアップの考え方に準じます。
AWS（RDS）を使用している場合は、自動スナップショット機能に任すことができます（RPOは最大5分）。
3-1. バックアップの種類
SQL Serverのバックアップの種類は以下の通りです。
完全バックアップ
データベースのデータ全体をバックアップする方法です。バックアップの取得には時間がかかる場合があります。
差分バックアップ
完全バックアップとの差分のみをバックアップをする方法です。差分バックアップを独立で実施することはできません。差分バックアップを取る前に完全バックアップを取る必要があります。
トランザクションログのバックアップ
トランザクションログは、最終バックアップ以降にデータベースに対して実行された全トランザクションの記録です。トランザクションログのバックアップを使い、データベースを特定の時間にリストアすることが可能です。トランザクションログのバックアップは、完全復旧モデルの場合に実行できます。
3-2. 復旧モデル
SQL Serverの復旧モデルは以下の通りです。一括ログ復旧モデルは割愛しています。
単純復旧モデル
バックアップの完了時点の状態のみに復旧させることが可能な復旧モデルです。トランザクションログをバックアップしないため、ログ肥大化の発生を抑えられます。RPOは前回のバックアップの実行時点となります（毎日業務終了後にバックアップしている場合、リストアすると前日の業務終了の時点に戻る）。バックアップ以降に発生したトランザクションは失われます。特定の時点に復旧することはできません。
完全復旧モデル
トランザクションログのバックアップを利用したリストアが可能となり、特定の時点の状態にデータベースをリストアおよび、障害発生直前の時点の状態にデータベースを回復させることが可能です。RPOを小さくする必要がある場合は、完全復旧モデルが必須です。また、冗長構成（AlwaysOn可用性グループ）を利用する場合は、完全復旧モデルが前提です。トランザクションログの切り捨てを行わないと、ログが肥大化し、ディスクの空き容量を圧迫します。ディスクが枯渇した場合、一切DBの更新（DML）ができません。
3-3. DBサーバのバックアップの例
以下は、週次で完全バックアップ、日次で差分バックアップを取る例です。復旧モデルは完全復旧モデルとなります。
4. リストア時における注意点
APサーバまたは、DBサーバをリストアする場合は、各サーバのRPOに注意し、整合性が取れるように確実にリストアします。
例えば、以下の例の場合のように、APサーバとDBサーバのRPOがそれぞれ異なっている場合、パッケージ（ライブラリ）やストレージバケットなどの実ファイルがロスする可能性があります（ファイルをAPサーバ上で保存する設定とした場合）。
おわりに
個人的にAWSでの構築経験が多くて、バックアップはAWSの機能に任せてしまうので、真面目に（細かく）考えることは多くないのですが、オンプレでシステムを構築すると面倒な事が多いですよね。
Cloudが使えるなら、Cloudにした方がいいと私は思います（もちろん、Cloudにもデメリットはありますが）。
次回は、監視とメンテナンスについて書きます。
参考
以下、リンク先はv2019.10を対象としたドキュメントとなりますが、v2022.4でも十分参考になります。
※v2019.10以降更新がありませんが、もう最新版はリリースしないのでしょうか。。。残念