このページの目次
バックアップと復元
このトピックでは、Paragon Automationで使用できるバックアップおよびリストア機能について説明します。Paragon AutomationはGUIベースのアプリケーションですが、バックアップとリストアの操作はParagon Insights cMGD CLIから管理されます。Postgres は、マイクロサービスの主要な永続ストレージ データベースです。バックアップ ファイルは、クラスター ノード上のローカル永続ボリュームに保存されます。バックアップ手順は、マイクロサービスの実行中に実行でき、クラスターの動作には影響しません。ただし、復元手順では、マイクロサービスが停止し、データベースが復元されるまでクラスターは機能しません。
現時点では、バックアップおよび復元するアプリケーションをカスタム選択することはできません。バックアップおよびリストアできるのは、 表 1 にリストされているように、各コンポーネントの事前構成済みで固定されたアプリケーションおよび管理設定のセットのみです。
デバイス |
アラート/アラーム設定 |
管理グループ |
トピック |
作図設定 |
ユーザー定義のアクションと関数 |
プレイブック |
集計プロファイル |
監査ログ |
デバイス グループ |
取り込み設定 |
トポロジ フィルターの構成 |
ネットワークグループ |
SNMP プロキシ構成 |
パスファインダー設定 |
通知設定 |
IAM 設定 |
LSP ポリシーとプロファイル |
保存ポリシー |
ワークフロー |
レポート生成設定(宛先、レポート、スケジューラ設定) |
バックアップ手順には、次の制限があります。
-
テレメトリ データ - デバイスからキャプチャされたデータは、デフォルトではバックアップされません。テレメトリ データは手動でバックアップする必要があります。
詳細については、「 TSDB のバックアップと復元」を参照してください。
-
一時データとロギングデータ - 処理中のデータや期限切れのイベントはバックアップされません。例えば:
-
生成されたアラートとアラーム
-
コミットされていない設定変更
-
ほとんどのアプリケーションログ
-
-
Paragon-Automation以外の設定-Paragon Automationがサポートするサードパーティサービスで行われた設定はバックアップされません。例えば:
-
LDAPユーザーの詳細
-
-
トポロジー取り込み設定-トポロジー情報を得るためにBGP-LSルーターとピアリングするためのcRPD設定はバックアップされません。これは、必要に応じて手動で再設定する必要があります。詳細については、 cRPD設定の変更を参照してください。
Kubernetesジョブを通じて呼び出されるコンテナ化されたスクリプトを使用して、バックアップと復元の手順を実装します。
クラスターは、「 構成のバックアップ」で説明されている手順を使用して手動でバックアップできます。また、「 バックアップスクリプトと復元スクリプト」で説明されている手順を使用して、バックアップスクリプトを使用してクラスターをバックアップすることもできます。
同様に、 設定の復元で説明されている手順を使用して、バックアップした設定を手動で復元できます。また、復元スクリプトを使用して、「 バックアップおよび復元スクリプト」で説明されている手順を使用して、バックアップした構成を復元することもできます。
![Backup and Restore Process](/documentation/us/en/software/paragon-automation23.2/paragon-automation-installation-guide/images/jn-000007.png)
Paragon Automationリリース23.2では、新しいリリース23.2インストールのダミーバックアップを実行した後にのみ、Paragon Automationの以前のリリースのバックアップ設定を復元できます。リリース 23.2 クラスタで復元操作を使用するには、次のことを推奨します。
-
現在のParagon Automationクラスタをリリース23.1にアップグレードします。
-
リリース 23.1 の設定をバックアップします。
-
リリース 23.2 クラスタをインストールします。
23.2 クラスターをバックアップします。
リリース 23.1 の設定をバックアップしたリリース 23.2 の場所にコピーします。
-
コピーしたバックアップ構成を復元します。
設定のバックアップ
ほとんどのParagon Automationアプリケーションのデータは、主にPostgresに保存されます。構成をバックアップすると、システムによって決定され、事前定義されたデータがバックアップされます。バックアップを実行しても、運用システムとマイクロサービスは影響を受けません。バックアップ実行中も、Paragonオートメーションを使い続けることができます。バックアップを実行するには、Paragon Insights(旧Healthbot)によって管理される管理デーモン(MGD)CLIを使用します。
現在のParagon Automationの設定をバックアップするには、次の手順に従います。
バックアップの詳細を表示するために頻繁に使用されるkubectl コマンド
バックアップの状態またはバックアップ ファイルの場所を表示したり、バックアップ ファイルの詳細情報を表示したりするには、次のコマンドを使用します。
-
バックアップ ジョブは共通の名前空間に存在し、
common=db-backup
ラベルを使用します。すべてのバックアップ ジョブを表示するには:root@primary-node:~# kubectl get -n common jobs -l common=db-backup NAME COMPLETIONS DURATION AGE db-backup-hello-world 1/1 3m11s 2d20h
-
特定の Kubernetes ジョブの詳細を表示するには、以下を行います。
root@primary-node:~# kubectl describe -n common jobs/db-backup-hello-world
-
特定の Kubernetes ジョブのログを表示するには、次のようにします。
root@primary-node:~# kubectl logs -n common --tail 50 jobs/db-backup-hello-world
-
バックアップ ファイルの場所を確認するには:
root@primary-node:~# kubectl get -n common pvc db-backup-pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE db-backup-pvc Bound local-pv-cb20f386 145Gi RWO local-storage 3d3h
出力は、ローカル永続ボリュームを指します。その永続ボリュームを使用して、バックアップ ファイルが格納されているノードを特定します。
root@primary-node:~# kubectl describe -n common pv local-pv-cb20f386 Node Affinity: Required Terms: Term 0: kubernetes.io/hostname in [10.49.xxx.x2] Message: Source: Type: LocalVolume (a persistent volume backed by local storage on a node) Path: /export/local-volumes/pv*
すべてのバックアップ・ファイルを表示するには、ノードにログインし、バックアップ・フォルダーの場所に移動します。
root@primary-node:~# ssh root@10.49.xxx.x2 root@10.49.xxx.x2:~# ls -l /export/local-volumes/pv*
一般的に見られるバックアップと復元の失敗シナリオについては、「 一般的なバックアップと復元の問題」を参照してください。
設定の復元
以前にバックアップした設定フォルダからParagon Automationの設定を復元することができます。復元操作では、バックアップされたすべての構成情報でデータベースが書き換えられます。データベースを選択的に復元することはできません。復元操作を実行すると、Kubernetes ジョブが生成され、影響を受けるマイクロサービスが停止します。このジョブは、バックアップされた構成を復元し、マイクロサービスを再起動します。Paragon Automationは、復元手順が完了するまで機能しません。
復元プロセス中に Kubernetes ジョブによってマイクロサービスが停止するため、複数の復元ジョブを同時に実行することはできません。また、バックアップ プロセスと復元プロセスの両方を同時に実行することはできません。
メンテナンス期間中に設定を復元することを強くお勧めします。復元しないと、システムが不整合な状態になる可能性があります。
Paragon Automationの設定を以前にバックアップした設定に復元するには、次の手順に従います。
復元の詳細を表示するために頻繁に使用される kubectl コマンド
復元プロセスの詳細情報とステータスを表示するには、次のコマンドを使用します。
-
復元ジョブは共通の名前空間に存在し、
common=db-restore
ラベルを使用します。すべての復元ジョブを表示するには:root@primary-node:~# kubectl get -n common jobs -l common=db-restore NAME COMPLETIONS DURATION AGE db-restore-hello-world 0/1 20s 21s
-
特定の Kubernetes ジョブの詳細を表示するには、以下を行います。
root@primary-node:~# kubectl describe -n common jobs/db-restore-hello-world
-
特定の Kubernetes ジョブのログを表示するには、次のようにします。
root@primary-node:~# kubectl logs -n common --tail 50 jobs/db-restore-hello-world
一般的に見られるバックアップと復元の失敗シナリオについては、「 一般的なバックアップと復元の問題」を参照してください。
バックアップおよび復元スクリプト
また、Paragon Automationのバックアップおよびリストアスクリプトを使用して、バックアップおよびリストア操作を簡略化することもできます。このトピックでは、バックアップと復元のスクリプトの操作と、スクリプトの使用に関する注意事項について説明します。
バックアップ スクリプト操作
バックアップ スクリプトは、現在の設定を自動的にバックアップします。バックアップスクリプトの主な利点は、定期的なバックアップをスケジュールするために必要な頻度でcronジョブとして実行できることです。さらに、バックアップスクリプトは識別可能な日付スタンプ付きのバックアップフォルダを作成し、スクリプトが異なる日に実行されてもフォルダは上書きされません。
バックアップスクリプトを使用して設定をバックアップするには:
-
プライマリノードのいずれかにログインします。
-
バックアップスクリプトを実行します。
root@primary-node:~# data.sh --backup
このスクリプトは、バックアップ ジョブを実行して、現在の構成をバックアップします。バックアップ フォルダーが作成され、クラスター ノードの 1 つ上のローカル永続ボリュームに保存されます。フォルダー名は <name>-year_month_day 形式です。クラスター ノード内のフォルダーには、バックアップされたすべての構成メタデータが含まれています。
また、このスクリプトは、プライマリノードの現在のパスに同じ名前のフォルダを作成します。プライマリノードのバックアップフォルダには、バックアップされた設定の復元中に使用されるベースプラットフォームに必要な JSON ファイルが含まれています。
スクリプトが実行されると、バックアップの概要が生成され、画面に表示されます。概要には、バックアップ ファイルのノードと場所が含まれます。例えば:
===============================Backup Report================================ Name: db-backup-paa-2023-10-18 Namespace: common Selector: controller-uid=446d45fd-0a7e-4b21-94b1-02f079b11879 Labels: apps=db-backup common=db-backup id=paa-2023-10-18 Annotations: <none> Parallelism: 1 Completions: 1 Start Time: Wed, 18 Oct 2023 08:39:04 -0700 Completed At: Wed, 18 Oct 2023 08:39:23 -0700 Duration: 19s Pods Statuses: 0 Running / 1 Succeeded / 0 Failed Pod Template: Labels: app=db-backup common=db-backup controller-uid=446d45fd-0a7e-4b21-94b1-02f079b11879 id=paa-2023-10-18 job-name=db-backup-paa-2023-10-18 Service Account: db-backup Containers: db-backup: Image: localhost:5000/eng-registry.juniper.net/northstar-scm/northstar-containers/ns_dbinit:release-23-1-ge572e4b914 Port: <none> Host Port: <none> Command: /bin/sh Args: -c exec /entrypoint.sh --backup /paa-2023-10-18 Environment: PG_HOST: atom-db.common PG_PORT: 5432 PG_ADMIN_USER: <set to the key 'username' in secret 'atom.atom-db.credentials'> Optional: false PG_ADMIN_PASS: <set to the key 'password' in secret 'atom.atom-db.credentials'> Optional: false Mounts: /opt/northstar/data/backup from postgres-backup (rw) Volumes: postgres-backup: Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace) ClaimName: db-backup-pvc ReadOnly: false Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfulCreate 47m job-controller Created pod: db-backup-paa-2023-10-18-95b8j Normal Completed 47m job-controller Job completed ============================================================================= Running EMS Backup. ===============================Get Backup file location====================== Name: local-pv-81fa4ecb Labels: <none> Annotations: pv.kubernetes.io/bound-by-controller: yes pv.kubernetes.io/provisioned-by: local-volume-provisioner-10.16.18.20-b73872bc-257c-4e82-b744-c6981bc3e131 Finalizers: [kubernetes.io/pv-protection] StorageClass: local-storage Status: Bound Claim: common/db-backup-pvc Reclaim Policy: Delete Access Modes: RWO VolumeMode: Filesystem Capacity: 149Gi Node Affinity: Required Terms: Term 0: kubernetes.io/hostname in [10.16.18.20] Message: Source: Type: LocalVolume (a persistent volume backed by local storage on a node) Path: /export/local-volumes/pv1 Events: <none> ============================================================================= Running Pathfinder Kubernetes Config Backup. ============================================================================= ...<snipped>... =============================Backup Completed================================
この例では、すべてのバックアップ メタデータを含むバックアップ フォルダーが、IP アドレス 10.16.18.20 のクラスター ノードの /export/local-volumes/pv1 フォルダーに格納されます。
スクリプトの復元操作
復元スクリプトは、バックアップした構成を自動的に復元します。
復元スクリプトを使用して設定を復元するには:
-
プライマリノードのいずれかにログインします。
MGD コンテナー名を取得します。
#kubectl get po -n healthbot | grep mgd
復元コマンドを実行します。
#kubectl exec -ti -n healthbot mgd-858f4b8c9-sttnh -- cli request system restore path /paa-2023-10-18
共通の名前空間で復元ポッドを見つけます。
#kubectl get po -n common | grep restore db-restore-paa-2023-10-18-6znb8
復元ポッドのログを確認します。
#kubectl logs -n common db-restore-paa-2023-10-18-6znb8
ログをフォローし、ログの最後にある [復元の完了] を探して更新します。
2023-10-18 16:01:11,127:DEBUG:pg_restore: creating ACL "metric_helpers.TABLE pg_stat_statements" 2023-10-18 16:01:11,129:DEBUG:pg_restore: creating ACL "metric_helpers.TABLE table_bloat" 2023-10-18 16:01:11,131:DEBUG:pg_restore: creating ACL "pg_catalog.TABLE pg_stat_activity" 2023-10-18 16:01:11,137:INFO:Restore complete 2023-10-18 16:01:11,388:INFO:Deleted secret ems/jobmanager-identitysrvcreds 2023-10-18 16:01:11,396:INFO:Deleted secret ems/devicemodel-connector-default-scope-id 2023-10-18 16:01:11,396:WARNING:Could not restore common/iam-smtp-config, iam-smtp-bkup.yml not found 2023-10-18 16:01:21,405:DEBUG:Waiting for secrets to be deleted (10/60) sec 2023-10-18 16:01:21,433:INFO:Created secret ems/jobmanager-identitysrvcreds 2023-10-18 16:01:21,443:INFO:Created secret ems/devicemodel-connector-default-scope-id 2023-10-18 16:01:21,444:INFO:Starting northstar applications 2023-10-18 16:01:22,810:INFO:Starting ems applications 2023-10-18 16:01:23,164:INFO:Starting auditlog applications 2023-10-18 16:01:23,247:INFO:Starting iam applications
リリース 23.2 UI にログインし、復元されたデータを確認します。
バックアップおよび復元スクリプトの注意事項
バックアップおよび復元スクリプトの注意事項は次のとおりです。
-
スクリプトは、毎週実行することも、1 日に 1 回だけ実行することもできます。24時間に複数回実行すると、 その日の<name>-year_month_dayという名前のバックアップフォルダがすでに存在するため、エラーが返されます。同じ 24 時間以内に手動バックアップを作成する必要がある場合は、
kubectl delete -n common jobs
コマンドを使用してジョブを削除する必要があります。例えば:# kubectl delete -n common jobs db-backup-paa-2023_20_04
-
スクリプトは、バックアップファイルの頻度とサイズに応じて、ディスク領域をバックアップファイルで満たします。古いバックアップメタデータとファイルを削除して、ディスク領域を解放することを検討してください。
kubectl delete -n common jobs
コマンドを使用して、Kubernetes メタデータを削除できます。例えば:# kubectl delete -n common jobs db-backup-paa-2023_20_04
バックアップ ファイルを削除するには、バックアップ スクリプトの実行時に概要に表示されるローカル ボリューム パスの /root/ フォルダーに作成された <name>-year-month-day フォルダーを削除します。