8. バックアップとリストア

ここではバックアップとリストアについて説明します。

8.1. バックアップとリストアの観点

intdash全体でバックアップを取る対象は次の通りです。

対象	バックアップ方針	ミドルウェア	説明
時系列データベースのデータ	推奨	InfluxDB または TimescaleDB	エッジから送信された時系列データ。
リレーショナルデータベースのデータ	推奨	PostgreSQL	ユーザーやエッジなどの時系列データ以外の永続化リソース。
イベントバスのデータ	任意	JetStream	intdash内のイベント情報のデータ。もし損失した場合でも復旧可能。
Measurement Serviceのファイルアップロード機能のディレクトリ	任意	ファイルシステム、またはS3	アップロードされたファイルの一時保存先。アップロードされたファイルを損失した場合でも、ファイルを再アップロードすることができれば復旧可能。
Media Serviceのメディアデータを配置するディレクトリ	任意	ファイルシステム、またはS3	Media Serviceが作成するメディアデータ（hlsやMP4など）の保存先。時系列データベースのデータが存在すれば復旧可能。

データのバックアップは必要に応じて複数の方法を併用することも可能です。要件に合わせたバックアップ/リストア戦略を立ててください。

intdashシステムのバックアップ・リストア戦略を考える際のいくつかのその他の観点について説明します。

8.1.1. 目標復旧時間（RTO）

障害が発生してから復旧するまでの目標となる時間です。この時間が長いほど、余裕を持ったリストア処理ができます。 RTOが0の場合は完全冗長化するシステムを構築する必要があるため、一般的により多くのコストが掛かります。

8.1.2. 目標復旧時点（RPO）

障害発生後の復旧の際に、どれだけ前の状態を復旧させるかの目標です。この時間が短いほど、より短い間隔でバックアップを取得する必要があります。

復旧させる際には、保存しておいたバックアップデータを使用しますので、最後にバックアップを取った時点から障害発生時までのデータは損失することになります。このことに注意してバックアップ周期を設定してください。

注釈

RTOが長く設定されている場合は、復旧が必要だと分かった時点で、あえて可能な限り早くintdashシステム全体を停止させることでデータの損失を抑えるという方針も考えられます。

intdashシステム全体を止めるとエッジからのデータ送信は失敗しますが、エッジ側で「時系列データの送信が失敗したら、保存できるまでローカルにデータを保持し再送信を行う」という処理を行っている場合は、サーバー側が復旧するまでローカルにデータが保持されますので、損失の影響を抑えることができます。

8.1.3. システムの可用性

バックアップの取得にはオフラインバックアップとオンラインバックアップがあります。

可用性の観点で、メンテナンス時間など確保できかつRPOの要件を満たすことができれば場合はオフラインバックアップのみの運用でも問題ないケースもあります。

intdashシステムのオンラインバックアップが必要な場合は後述する動作環境による具体的な手法を参考にシステムのバックアップを取得します。

8.2. 動作環境による具体的な手法

8.2.1. AWS

AWSを使用している場合は、AWSが提供しているバックアップサービスである AWS Backup の使用を推奨します。例えば、時系列データベースをEC2で構築し、リレーショナルデータベースをRDSで構築している場合は、AWS Backup を使用することで安全にバックアップ・リストアが可能です。

また、intdashの計測のアップロード機能などファイルシステムを使用する機能は、設定により、データの保存先としてAWS S3を使用することができます。AWS S3を使用することで、バックアップなどの考慮が不要となります。このような機能については特別な理由がない限りはS3の使用を推奨します。

8.2.2. Kubernetes

Kubernetesでの運用の場合、バックアップの対象は次のように分類できます。

分類	方針
Kubernetesコントロールプレーン	クラウドプロバイダが提供するフルマネージドKubernetesサービス（EKSなど）を使用している場合、コントロールプレーンノードのスケーラビリティや可用性は、クラウドプロバイダで通常担保されているので、考える必要はありません。そうではない場合は、別途コントロールプレーンのバックアップ（etcdなど）が必要です。環境に応じて設定してください。
intdashのリソースが使用するデータ	計測のアップロード機能などでファイルシステムを使用している場合は、ボリュームを用意してコンテナの対象のディレクトリにマウントしてください。その上でボリュームの種類に応じたバックアップを設定してください。
intdashが使用するミドルウェアのデータ	Kubernetesクラスタにリレーショナルデータベースや、時系列データベースなどのStatefulSetをデプロイする場合は、それらをバックアップすることを推奨します。例えば Verelo などを使用してバックアップすることができます。
リソースのマニフェスト	デプロイされたKubernetesクラスタのマニフェスト。Veleroを使用してバックアップすることができます。一方でマニフェストについてはデプロイ戦略によってはバックアップをする必要がないケースもあります。運用に応じて設定します。

8.2.3. 特定ミドルウェアの論理バックアップとリストア

intdashはデータを保存するミドルウェアとして、次のものを採用しています。要件に応じてミドルウェアごとに論理バックアップを取っておくことができます。

InfluxDB
PostgreSQL
JetStream
minio（Measurement Service、Media Serviceのオブジェクトストレージとしてminioを採用している場合）
ファイルシステム（Measurement Service、Media Serviceのオブジェクトストレージとしてファイルシステムを採用している場合）

バックアップとリストアの詳細については各ミドルウェアの公式ドキュメントを参照してください。

8.2.3.1. InfluxDB

InfluxDB v1.8.xのバックアップとリストアについて説明します。基本的な流れは InfluxDB Back up and restore data に従います。

警告

バックアップ取得時、及びリストア実行時はintdashサーバーを停止しておくことを推奨します。

InfluxDBのバックアップを取得します。

# InfluxDBのバックアップ
influxd backup -portable /path/to/backup-destination


# または、リモートアドレスを指定して、InfluxDBをバックアップ
influxd backup -portable -h <バックアップするInfluxDBのホスト名:例 203.0.113.0:8088> /path/to/backup-destination

データベース名を指定してInfluxDBのリストアを行います。

# データベース名を指定してInfluxDBをリストア
influxd restore -portable \
   -db "intdash-measurement" \
   /path/to/backup-directory

# または、データベース名とリモートアドレスを指定してInfluxDBをリストア
influxd restore -portable \
   -db "intdash-measurement" \
   -host <リストアするInfluxDBのホスト名:例 203.0.113.0:8088> \
   /path/to/backup-directory

注釈

InfluxDBのバックアップとリストアは説明した以外にも様々な方法があります。詳細についてはInfluxDBのドキュメント InfluxDB Back up and restore data を参照してください。

8.2.3.2. PostgreSQL

PostgreSQL14系のバックアップとリストアについて説明します。基本的な流れは、PostgreSQLのドキュメント第26章バックアップとリストアに従います。

pg_dump コマンドを使用して、使用しているデータベースすべてのダンプファイルを出力します。データベースを使用しているサービスは次の通りです。
- Authentication Service
- Broker Service
- Tenant Service
- Measurement Service
- Media Service
- Data Visualizer Backend Service
- Webhook Service

pg_dump <データベース名> > dumpfile
注釈

使用しているデータベース名は設定で確認します。設定については設定リファレンスを参照してください。

psql コマンドを使用して、リストアを行います。

psql <データベース名> < dumpfile

8.2.3.3. JetStream(NATS)

NATS v2.x系に含まれるJetStreamのバックアップとリストアについて説明します。基本的な流れは、NATSのドキュメント Managing JetStream-Manual Recovery に従います。

nats コマンドを使用して、使用しているストリームを確認します。

nats stream ls

nats コマンドを使用して、バックアップを取得します。

nats stream backup <ストリーム名> '<バックアップディレクトリ>'
警告

バックアップはストリームごとに行います。バックアップ先もストリームごとに分けるようにしてください。

nats コマンドを使用して、使用しているストリームをリストアします。

nats stream restore '<バックアップディレクトリ>'

8.2.3.4. minio

minioのバックアップとリストアについて説明します。minioは複数のバックアップ方法をサポートしていますが、ここでは mc mirror コマンドを使用し、S3にミラーリングする方法を説明します。詳細は MINIOのWebサイトを参照してください。

注釈

mc mirror コマンドによるミラーリングでは、オブジェクトのバージョン情報などはミラーリングの対象ではないことに注意してください。もし、バージョン情報などもバックアップする場合は mc replicate や mc admin replicate を検討してください。

参考-mc mirror

mc alias コマンドを使用してS3のエイリアスを作成します。

mc alias set <バックアップ先のエイリアス名>  <バックアップ先のS3のURL> <アクセスキー> <シークレットキー>

mc mirror コマンドを使用してミラーリングします。

mc mirror <移行元のエイリアス名>/<移行元のバケット名>  <バックアップ先のエイリアス名>/<バックアップ先のS3バケット名>

mc mirror コマンドを使用してリストアします。

mc mirror <バックアップ先のエイリアス名>/<バックアップ先のS3バケット名> <復元先のエイリアス名>/<復元先のS3のバケット名>

注釈

S3へバックアップされたデータは、intdashの設定でそのまま参照して使用することが可能です。これは環境間の移行などで利用できます。

8.2.3.5. ファイルシステム

定期的に対象のディレクトリのバックアップを行います。構築された環境に応じた方法でバックアップおよびリストアを実施してください。