ネットワーク機器のコンフィグバックアップや変更履歴を管理するUnimusでは、取得したコンフィグバックアップ、バックアップ履歴、ジョブの実行履歴など、運用に関わるさまざまな情報をデータベースに保存します。
Unimusは標準の内蔵DBとしてHSQLDBを利用できますが、管理対象が100台を超えるような環境では、PostgreSQLなどの外部DBを利用する構成が推奨されています。
そのため、外部DB構成でUnimusを運用する場合は、データベースのバックアップや復元手順についても、あらかじめ確認しておくことが重要です。
本記事では、外部PostgreSQL構成におけるDB接続設定、バックアップ取得、復元検証、Unimusからの参照確認、そして元DBへの切り戻し確認までを実際に検証します。
Unimusの運用でDBバックアップが必要になる場面
Unimusを運用していると、DBバックアップが必要になる場面はいくつかあります。
代表的なのは、Unimus自体をアップデートする場合です。公式wikiの「How do I update Unimus?」でも案内されているように、アップデート作業では事前にDBバックアップを取得することが推奨されています。
特に外部PostgreSQL構成では、Unimusの設定情報、デバイス情報、取得したコンフィグバックアップ、バックアップ履歴などがDBに保存されます。そのため、DBバックアップは、Unimusの運用データを守るための重要な作業です。
アップデート以外にも、以下のような場面では、事前にDBバックアップを取得しておくと安心です。
- PostgreSQLサーバーやOSをメンテナンスする前
- PostgreSQLのバージョンアップや移行を行う前
- DBサーバーを別環境へ移行する前
- Unimusの接続先DB設定を変更する前
- 障害対応や切り戻し作業に備える場合
- 定期的な災害対策、復旧訓練、リストアテストを行う場合
このような場面では、単にバックアップファイルを取得するだけでなく、「そのバックアップから復元できるか」「復元したDBをUnimusから参照できるか」「必要に応じて元のDBへ戻せるか」まで確認しておくことが大切です。
補足：ライセンスキー変更を伴う場合の注意
なお、Unimusでは、ゾーンやデバイス情報がライセンスキーに紐づく仕様があります。
今回の検証は、同一環境・同一ライセンスキーを前提としたDBバックアップ／復元確認であり、ライセンスキー変更を伴う移行作業は対象としていません。
ライセンスキーを変更する場合は、ゾーン、デバイス、バックアップ情報の扱いに影響が出る可能性があります。事前に公式wikiの「License key change」などを確認し、検証環境で影響範囲を確認してから作業することをおすすめします。
今回の検証環境
今回の検証環境の構成は以下のイメージです。
Windows Server上のUnimus Serverから、Linux Server上のPostgreSQL検証環境へ 5432/TCP で接続します。
PostgreSQL検証環境は、検証を短時間で再現するためにDockerコンテナ上へ一時的に構築しました。DBとしては、通常運用を想定したバックアップ元DB unimus_prod と、復元検証用DB unimus_restore を用意しています。
| 項目 | 内容 |
|---|---|
| Unimus Server | Windows Server上で稼働 |
| Unimus設定ファイル | C:\ProgramData\Unimus\unimus.properties |
| DB接続 | Windows ServerからPostgreSQL検証環境へ 5432/TCP で接続 |
| PostgreSQL検証環境 | Linux Server上のDockerコンテナで構築 |
| DBユーザー | unimus |
| バックアップ元DB | unimus_prod |
| 復元検証用DB | unimus_restore |
| バックアップ方式 | pg_dump -Fc |
| 復元方式 | pg_restore |
| 確認方法 | Unimus Web画面、PostgreSQLの pg_stat_activity |
検証では、まず unimus_prod をバックアップし、そのバックアップファイルを unimus_restore へリストアしました。その後、Unimusの接続先DBを一時的に unimus_restore へ変更し、Unimus Web画面とPostgreSQL側の両方から復元データを参照できることを確認しています。
最後に、接続先DBを unimus_prod へ戻し、切り戻し後も正常に接続できることを確認しました。
補足：Docker構成について
今回のPostgreSQLは、検証環境を短時間で再現するためにDockerコンテナ上へ構築しています。
PostgreSQLをコンテナ上で本番運用するケース自体はありますが、その場合は永続化ストレージ、バックアップ、監視、復旧、アップデート、セキュリティ、可用性などを含めた運用基盤の設計が前提になります。
本記事のDocker構成は、バックアップ、復元、切り戻しの流れを検証するためのものであり、Unimusの本番DB構成としてDocker上のPostgreSQLを推奨するものではありません。
本番環境では、専用DBサーバー、仮想マシン、クラウドDB、社内DB基盤、または各社で標準化されたコンテナ基盤など、組織のDB運用方針に沿った構成を選択してください。
検証の全体像
今回の検証では、外部PostgreSQL構成でUnimusを利用する前提として、DB作成からバックアップ取得、復元先DBでの確認、元DBへの切り戻しまでを一連の流れで確認しました。
大きな流れは以下の4段階です。
| フェーズ | 確認内容 |
|---|---|
| 1. PostgreSQL側の準備 | Unimus接続用ユーザー、バックアップ元DB unimus_prod、復元検証用DB unimus_restore を作成 |
| 2. Unimus側の接続設定 | セットアップウィザードまたは unimus.properties で、Unimusの接続先DBを unimus_prod に設定し、UIから通常接続を確認 |
| 3. バックアップ・復元検証 | pg_dump -Fc で unimus_prod をバックアップし、pg_restore で unimus_restore へリストア |
| 4. 復元先DB確認と切り戻し | Unimusの接続先を unimus_restore に変更してUI表示を確認し、その後 unimus_prod へ戻して切り戻しを確認 |
今回の検証では、バックアップ取得、復元検証用DBへのリストア、Unimus UIからの参照、pg_stat_activity による接続確認、元DBへの切り戻しまで問題なく確認できました。
ポイントは、DBバックアップを取得して終わりにするのではなく、復元先DBをUnimusから実際に参照できること、さらに元のDBへ戻せることまで確認した点です。
補足：手動手順と本番運用での自動化について
なお、本記事では、各手順を理解しやすいように手動コマンドで説明しています。
実際の本番運用では、DBバックアップの定期実行、バックアップファイルの外部保管、世代管理、監視通知などを自動化するケースが一般的です。
一方で、復元検証や切り戻し確認は、自動化されたバックアップ運用が正しく機能しているかを確認するうえでも重要です。
そのため、まずは検証環境で手動手順を確認し、その内容をもとに、各社の運用ルールに合わせて自動化・定型化することをおすすめします。
PostgreSQL側でUnimus用DBを準備する
外部PostgreSQL構成でUnimusを利用する場合は、まずPostgreSQL側にUnimus用のDBと接続ユーザーを用意します。
Unimus公式Wikiでは、PostgreSQLを含む外部DB構成について記載されています。また、PostgreSQLの推奨設定として、文字コードは utf8、照合順序は C（POSIX 相当）が案内されています。詳細な対応DBや推奨設定については、Unimus公式Wikiの「Database requirements」を確認してください。
今回の検証では、PostgreSQL側に以下を作成しました。
| 項目 | 内容 |
|---|---|
| DBユーザー | unimus |
| バックアップ元DB | unimus_prod |
| 復元検証用DB | unimus_restore |
| 文字コード | UTF8 |
| 照合順序 | C |
まず、PostgreSQLに管理者権限を持つユーザーで接続します。Dockerコンテナ上のPostgreSQLを利用している場合は、以下のようにコンテナ内の psql を実行します。
docker exec -it <PostgreSQLコンテナ名> psql -U postgres次に、Unimusから接続するためのDBユーザーを作成します。
CREATE USER unimus WITH PASSWORD '<任意のパスワード>';続いて、バックアップ元DBである unimus_prod を作成します。
CREATE DATABASE unimus_prod
OWNER unimus
ENCODING 'UTF8'
LC_COLLATE 'C'
LC_CTYPE 'C'
TEMPLATE template0;OWNER unimus を指定することで、作成した unimus ユーザーをこのDBの所有者にします。これにより、Unimusが自身のDB内で必要なテーブル作成やデータ更新を行えるようになります。
あわせて、復元検証用DBである unimus_restore も作成しておきます。
CREATE DATABASE unimus_restore
OWNER unimus
ENCODING 'UTF8'
LC_COLLATE 'C'
LC_CTYPE 'C'
TEMPLATE template0;作成したDBは、以下のSQLで確認できます。
SELECT datname, pg_encoding_to_char(encoding) AS encoding, datcollate, datctype
FROM pg_database
WHERE datname IN ('unimus_prod', 'unimus_restore');確認結果で、unimus_prod と unimus_restore が作成され、文字コードや照合順序が想定どおりになっていれば、PostgreSQL側の基本準備は完了です。
なお、ここで示したコマンドは検証環境での例です。本番環境では、DB名、ユーザー名、パスワード、権限設計、バックアップ方式、監視方法などを、各社のDB運用方針やDBAの方針に合わせて決定してください。
Unimus側で外部PostgreSQLへの接続を設定する
セットアップウィザードで外部PostgreSQLを指定する
PostgreSQL側でUnimus用DBを作成したら、Unimus Server側で外部DBへの接続設定を行います。
Unimusの初回セットアップ時には、セットアップウィザード上で使用するデータベースを指定します。外部PostgreSQLを利用する場合は、データベース種別としてPostgreSQLを選択し、PostgreSQLサーバーの接続情報を入力します。
今回の検証では、以下のような接続情報を指定しました。
| 項目 | 設定例 |
|---|---|
| Database type | PostgreSQL |
| Host | PostgreSQLサーバーのホスト名またはIPアドレス |
| Port | 5432 |
| Database name | unimus_prod |
| Username | unimus |
| Password | DBユーザーのパスワード |
ここで指定する Database name は、通常運用時にUnimusが接続するDBです。今回の検証では、バックアップ元DBとして作成した unimus_prod を指定しました。
入力内容に問題がなければ、Unimus Serverは指定したPostgreSQL DBへ接続し、以後のデバイス情報、バックアップ履歴、ジョブ履歴などを外部DB上で管理します。
DB接続設定をunimus.propertiesで確認する
セットアップウィザードで指定したDB接続情報は、Unimusの設定ファイルにも反映されます。
Windows環境でインストーラー版のUnimus Serverを利用している場合、設定ファイルは通常以下の場所にあります。
C:\ProgramData\Unimus\unimus.propertiesLinux環境の場合は、通常以下の場所にあります。
/etc/unimus/unimus.properties代表的なDB接続設定は以下のような形式です。
database.type=POSTGRESQL
database.host=
database.port=5432
database.name=unimus_prod
database.user=unimus
database.password=初回セットアップではウィザードで設定できますが、復元検証や切り戻しの際には、この database.name を確認することで、UnimusがどのDBへ接続しているかを把握しやすくなります。
バックアップ・復元検証を行う
本番想定DBをバックアップする
PostgreSQL側に unimus_prod を作成し、Unimus Serverから外部DBとして接続できることを確認したら、次に unimus_prod のバックアップを取得します。
Unimus公式Wikiでは、アップデート前のDBバックアップが推奨されています。また、MySQLまたはPostgreSQLを使用している場合は、各DBのネイティブな管理ツールでDBダンプを取得する旨が記載されています。
今回の検証では、PostgreSQLの pg_dump を使用し、カスタム形式でバックアップを取得しました。
PostgreSQLをDockerコンテナ上で動作させている場合は、PostgreSQLコンテナ内、またはPostgreSQLに接続できる環境からコマンドを実行します。たとえば、コンテナ内で作業する場合は以下のように接続します。
docker exec -it <PostgreSQLコンテナ名> bashその後、コンテナ内で pg_dump を実行します。
pg_dump -U postgres -d unimus_prod -Fc -f /backup/unimus_prod_YYYYMMDD.dump-Fc は、PostgreSQLのカスタム形式でバックアップを取得するオプションです。カスタム形式で取得しておくと、後続の pg_restore による復元検証が行いやすくなります。
unimus_prod を pg_dump -Fc でバックアップした例実運用では、バックアップファイル名に取得日や環境名を含めておくと管理しやすくなります。また、バックアップファイルの保管先、世代管理、暗号化、アクセス権限、復元テストの頻度などもあわせて検討する必要があります。
今回のようにDockerコンテナ内へバックアップファイルを出力する場合は、コンテナ内だけでなく、ホスト側や外部のバックアップ保管先へ退避できることも確認しておくと安心です。
なお、DBバックアップを取得する際は、バックアップ中にUnimus側でデータ更新が発生しないよう、Unimusサービスを停止してから取得する方法が安全です。Unimus公式Wikiでも、アップデート前のDBバックアップでは、事前にアプリケーションサービスを停止することが推奨されています。
本番環境では、停止可能な時間帯やバックアップ方式が企業ごとに異なるため、メンテナンス時間、DB運用ルール、DBAやインフラ担当者の方針も踏まえて手順を決めることをおすすめします。
復元先DBを用意してリストアする
次に、取得したバックアップファイルを復元検証用DBである unimus_restore へリストアします。
今回の検証では、前回の復元データや不要な情報が残らないようにするため、unimus_restore をいったん削除し、再作成してからリストアしました。これにより、unimus_prod から取得したバックアップファイルだけで復元できるかを確認しやすくなります。
なお、以下は今回の検証環境で使用したコマンド例です。DBを削除する操作を含むため、本番DBに対して実行するコマンドではありません。実環境で復元検証を行う場合は、対象DB名、接続ユーザー、権限、既存接続の有無を確認してください。
dropdb -U postgres unimus_restore
createdb -U postgres unimus_restore
pg_restore -U postgres -d unimus_restore /backup/unimus_prod_YYYYMMDD.dump
今回の検証では、unimus_prod から取得したバックアップファイルを unimus_restore に復元しました。
pg_restore 後に、復元先DBである unimus_restore のサイズを確認した例ここで重要なのは、いきなり本番想定DBへ戻すのではなく、復元検証用DBを用意して確認している点です。
バックアップ運用では、バックアップファイルの取得に加えて、復元確認まで行っておくと安心です。復元したDBをUnimusから参照し、デバイス情報やバックアップ履歴が想定どおり表示されることを確認しておくことで、実際のメンテナンスや障害対応時にも対応しやすくなります。
Unimusの接続先DBを復元検証用DBへ変更する
unimus_restore へのリストアが完了したら、Windows Server上の unimus.properties を編集し、接続先DBを一時的に unimus_restore へ切り替えます。
通常運用時は、以下のように unimus_prod を指定しています。
database.name=unimus_prod復元検証時は、この値を以下のように変更します。
database.name=unimus_restore今回のように同じPostgreSQLサーバー内の別DBへ切り替える場合は、主に database.name の変更で確認できます。一方、別のPostgreSQLサーバーへ切り替える場合は、database.host や database.port などもあわせて確認します。
設定ファイルを編集したら、Unimus Server サービスを再起動します。
Restart-Service -DisplayName "Unimus Server"再起動後、UnimusのWeb画面へログインし、復元先DBのデータを参照できるか確認します。
Web画面上で復元データを確認する
Unimusの接続先を unimus_restore に変更した状態で、UnimusのWeb画面へログインします。
今回の検証では、以下の内容を確認しました。
- Unimus へログインできること
- デバイス一覧が表示されること
- バックアップ履歴が参照できること
- 復元前のデータが想定どおり表示されること
この確認により、単にPostgreSQL上でDBを復元できただけでなく、Unimusアプリケーションから復元データを参照できることを確認できました。
復元先DBの確認と元DBへの切り戻し
PostgreSQL側で実際の接続先DBを確認する
Web画面上で表示確認を行った後、PostgreSQL側でも接続状況を確認しました。
今回は pg_stat_activity を使用し、Unimusが実際に unimus_restore へ接続していることを確認しています。
pg_stat_activity は、PostgreSQLに現在接続しているクライアントや接続先DBを確認できるビューです。今回は、Unimus Serverからの接続が復元検証用DBである unimus_restore に向いているかを確認するために使用しました。
PostgreSQLコンテナ内で確認する場合は、以下のように psql を起動します。
docker exec -it <PostgreSQLコンテナ名> psql -U postgres -d postgres
その後、以下のSQLを実行します。
SELECT datname, usename, client_addr, state
FROM pg_stat_activity
WHERE datname = 'unimus_restore';
pg_stat_activity でUnimusが unimus_restore へ接続していることを確認UI上でデータが見えているだけでなく、DB側からも接続先を確認することで、「今UnimusがどのDBを参照しているのか」を明確にできます。
復元検証や切り戻し確認では、このようにアプリケーション側とDB側の両方から確認することが重要です。
元の本番想定DBへ切り戻す
復元検証が完了したら、Unimusの接続先DBを元の unimus_prod へ戻します。
Windows Server上の unimus.properties を再度編集し、接続先DB名を以下のように戻します。
database.name=unimus_prod
設定を保存したら、Unimus Server サービスを再起動します。
Restart-Service -DisplayName "Unimus Server"
その後、Unimus UIでログインできること、デバイス一覧やバックアップ履歴が通常どおり表示されることを確認します。
さらにPostgreSQL側でも、pg_stat_activity を確認し、Unimusが unimus_prod へ接続していることを確認しました。
SELECT datname, usename, client_addr, state
FROM pg_stat_activity
WHERE datname = 'unimus_prod';
この確認により、復元先DBへの接続確認だけでなく、元のDBへ切り戻せることも確認できました。
本番運用では、復元確認だけでなく、切り戻し手順も事前に確認しておくことが重要です。特にメンテナンス作業や障害対応では、想定どおりに戻せるかどうかが運用上の安心材料になります。
今回の検証結果
今回の検証では、外部PostgreSQL構成におけるDBバックアップ取得、復元検証用DBへのリストア、Unimus Web画面での確認、PostgreSQL側での接続確認、元DBへの切り戻しまでを一連の流れで確認しました。
| 確認項目 | 結果 |
|---|---|
unimus_prod のバックアップ取得 | 成功 |
unimus_restore への復元 | 成功 |
| Unimus Web画面でのログイン確認 | 成功 |
| デバイス一覧・バックアップ履歴の確認 | 成功 |
pg_stat_activity による復元先DB接続確認 | 成功 |
unimus_prod への切り戻し | 成功 |
これにより、バックアップファイルの取得だけでなく、復元したDBをUnimusから参照できること、さらに元のDBへ戻せることまで確認できました。
実運用では、今回のような確認内容を手順書やチェックリストとして整理し、バックアップ運用、メンテナンス作業、復旧訓練などに組み込んでおくと安心です。
まとめ
今回の検証では、UnimusのPostgreSQL外部DB構成において、unimus_prod のバックアップ取得、unimus_restore へのリストア、Unimus Web画面からの参照確認、PostgreSQL側での接続確認、そして元DBへの切り戻しまでを一連の流れとして確認しました。
外部DB構成でUnimusを運用する場合は、DBバックアップを取得するだけでなく、復元したDBをUnimusから参照できること、必要に応じて元のDBへ戻せることまで確認しておくと安心です。
本番環境で運用を始める場合は、事前にUnimus公式Wikiでハードウェア要件、対応DB、利用ポートを確認し、各社のDB運用方針に沿って構成を整理しておくことが重要です。
あわせて、バックアップ取得タイミング、保管先、世代管理、復元確認、切り戻し手順なども運用設計に含めておくとよいでしょう。
今回のブログ記事とも連動したPostgreSQL構成・運用確認ガイドもあわせてご参照ください。
Unimusの機能や評価版の利用方法については、製品紹介ページおよびダウンロードページでご案内しています。外部DB構成での運用や、自社環境での導入イメージについて確認したい点がございましたら、お気軽にお問い合わせください。
