ROSAでEFSを利用する際のバックアップ・リストア戦略

概要

前回の記事ではROSAでEFSを利用する方法とその際の考慮点をご紹介しましたが、本記事ではEFSをバックアップ・リストアする際の方法についてご紹介します。

本記事で紹介するユースケース

• ROSAのPVとしてEFSを利用する際のバックアップ(AWS Backup一択)
• EFSをPVとしてリストアする際のパターン

バックアップ

どの層でバックアップを行うか

OpenShift/Kubernetesクラスタにおいてストレージのバックアップを取得する際、どのレイヤーで取得するかを考える必要があります。

OpenShiftクラスタのツールを利用してバックアップ・リストアを行う場合は、データが保存されているストレージ本体だけでなく、それに関連するKubernetesリソース(PV,PVC,Pod,Deployment)までバックアップを取得することが可能です。

AWSのサービスを利用してバックアップ・リストアを行う場合はAWSリソースとしてのバックアップになりますので、Kubernetesリソースについては別途バックアップを行う必要があります。また、リストアする際にはPV・PVC等を再度作成し直す必要があります。

こう記載すると、前者の方が楽じゃないか、と思われるかもしれません。
ですが、実際の運用で利用することを考えると、運用としてAWSリソースだけをリストアして別のKubernetesリソースとして定義し直したいケースは往々にしてありますので、後者の方が実情にあっている場合もありうると思っています。

サービス/ツールの選定

結論としては、EFSのバックアップのためにはAWS Backupを使うことになります。
それはOpenShiftのバックアップツールであるOpenShift API for Data Protection(OADP)がEFSに対応していないためです。

OpenShift/ROSAではバックアップツール/サービスとしてOADPが提供されています。

OADPはKubernetesクラスタのリソースのバックアップ・リストアに利用出来るOSSであるVeleroをベースとしたツールです。
VeleroではResticとのIntegrationによりファイルストレージのバックアップも可能です。

しかし、残念ながらOADPではEFSのバックアップにresticを利用することが出来ません。
OADP currently does not support backup and restore of AWS EFS volumes using restic in Velero (OADP-778).

したがって、EFSを利用する際はOpenShift上のツールではなくAWS Backupを利用してEFSのバックアップを取得することになります。

もちろん、これ以外の方法として独自のバックアップを実装することも出来ます。
例えば、バックアップ用のPodを作成し、バックアップ対象ストレージ・バックアップ保管用ストレージをマウントして定期的にデータをコピーすることでバックアップを行うことも可能ですが、手間のかかる運用となりますので可能な限りAWSのサービスを利用すべきと思います。

リストア

前述の通り、EFSのバックアップはAWS Backup一択となるため、リストアもAWS Backupの機能で行います。
そして、AWSのサービスでバックアップ・リストアを行う際にはKubernetesのリソースはリストアされませんので別途再作成が必要となります。

EFSのリストア

EFSをリストアする際のオプションはRestore type・Restore locationの2つです。

Restore type
Full restore	全フォルダ・ファイルをリストアします。
Item-level restore	特定のフォルダ・ファイルをリストアします。

Restore location
Restore to directory in source file system	同一EFSリソースにリストア対象をリストアします。
Restore to a new file system	別EFSリソースを作成し、そこにリストア対象をリストアします。

Restore locationでRestore to directory in source file systemを選択してリストアを行うと、同一EFSリソースのルートボリュームにフォルダが作成され、リストアしたフォルダ・ファイルが格納されます。

Kubernetesリソースの新規作成

PV/PVCの作成

リストアしたディレクトリ(フォルダ)をKubernetes上のPodから扱えるようにするため、PV・PVCとして定義します。
前回の記事の通り、この環境では動的プロビジョニング(Dynamic Provisoning)を採用しており、PVC作成時に自動でPVが作成されるので、普段はPVの存在をあまり意識する必要はないのですが、ここでは既存のディレクトリをPV化する静的プロビジョニングを行いますので、PVを意識する必要があります。

↓動的プロビジョニングの場合はpvc作成時にpvも自動作成されますが、リストアの場合は静的プロビジョニングのため手動で作成する必要があります。
また、volumeHandleではEFS内でリストアされたディレクトリを指定する必要があります。
(storageClassNameは動的プロビジョニングと同様でも良いですし、異なる名称でも構いません。)

kind: PersistentVolume
apiVersion: v1
metadata:
  name: <pv-name>
spec:
  capacity:
    storage: 1Gi                  
  csi:
    driver: efs.csi.aws.com
    volumeHandle: 'fs-xxxxxx:/aws-backup-restore_yyyy-mm-ddThh-mm-ss-xxxxxxxxZ/<restore_dir>
    volumeAttributes:
      encryptInTransit: 'true'
  accessModes:
    - ReadWriteMany    
  persistentVolumeReclaimPolicy: Delete
  storageClassName: <storage_class_name>
  volumeMode: Filesystem

PV・PVCが作成出来たら、次はこのPVをPodにマウントします。

リストアパターン

ここでのリストアシナリオとして、2つのパターンが考えられます。

パターン①：元のPodで特定時刻の状態にデータを戻したい

このパターンとして、リストアしたフォルダ・ファイルの一部を戻したい場合が考えられます。例えば、誤ってファイルを削除したケースなどです。
この場合は元のPodにリストアしたPVを一時的にマウントし、ファイルのコピーを行うことでこれを実現することが出来ます。

パターン②：別Podで特定時刻の状態にデータを戻したい

このパターンとして、バックアップ時点でのPodの状態を再現したい場合が考えられます。
このパターンとして、アプリケーションが動かなくなり、過去時点での稼働を確認したい場合が考えられます。
この場合はアプリケーションのPodも別のPodとして作成し直した上でリストアしたPVをマウントすることで実現が可能です。（場合によってはService・Ingress・Routeなどのリソースも用意する必要があります）

まとめ

本記事ではEFSとROSAを組み合わせた際のEFSのバックアップ・リストア戦略についてご紹介しました。
EFS自体のバックアップ・リストアについてはAWS Backupを利用したバックアップ・リストア一択となりますが、リストアオプションやKubernetesリソースとしての取り扱い方については求められる要件や運用方式によって異なるかと思いますので、適切な方法を選択することが重要です。
本記事の内容が皆様の役に立ちましたら幸いです。