Cloud Native 技術をフル活用！壊して学ぶ自宅サーバーのバックアップ戦略！

自宅サーバーでのデータ損失経験から構築した、Kubernetes上のステートフルアプリケーション向けバックアップシステムを紹介します。CloudNativePG、MinIO、Longhorn、Veleroを活用し、多重バックアップと自動リストアテストで信頼性を実現した実例をお話しします。

CloudNative Days Winter 2025 (https://event.cloudnativedays.jp/cndw2025) の学生スカラシップLT 〜CloudNativeに挑戦する学生たち〜 (https://event.cloudnativedays.jp/cndw2025/talks/2777) の発表資料です。

Transcript

1. CloudNative技術をフル活⽤！ ⾃宅サーバーのバックアップ戦略 2025/11/19 京都大学 工学部 電気電子工学科 walnuts1018 壊して 学ぶ
2. 名前: 俵 遼太（たわら りょうた） 所属: 京都大学 工学部 電気電子工学科 4回生 趣味: ・Kubernetes ・Go ・OpenTelemetry ・React ⾃⼰紹介 @walnuts1018 @walnuts1018 id:walnuts1018 1 自己紹介 > 障害事例 > バックアップ構成を考える > 各データのバックアップ > クラウドへのバックアップ
3. 2 ディスク障害 事象 • NodeのSSD故障により、PersistentVolumeのデータが 破損した 対処 • 別のNodeのデータを用いたリビルド • バックアップからの復元 DB故障 事象 • Podの強制終了により、PostgreSQLの全Podが Failed状態になった 対処 • バックアップからの復元 全PV消失 事象 • 誤ったApplication ManifestをPushしてしまい、 ArgoCDによって全リソースを削除された • Longhornがアンインストールされ、全PVが消えた 対処 • バックアップからの復元 PVのバックアップデータ消失 事象 • Longhornを再インストールした際に、バックアップ先NFS のデータが全消去された 対処 • 不可能（ほぼ全データ消失） • たまたま手元のマシンにあったpgdumpや Internet Archiveから一部復元 ⾃宅クラスタで実際に起きた障害事例 自己紹介 > 障害事例 > バックアップ構成を考える > 各データのバックアップ > クラウドへのバックアップ
4. 3 前提 • 自宅サーバーのサービスは、全てKubernetesクラスタ上で稼働 • 全て=DBやオブジェクトストレージも含む • 永続ボリュームを払い出すためにLonghornを利用 達成目標 • ①PersistentVolume、②MinIO、③PostgreSQLのバックアップを行えている • 常に最新の数バージョンを保持できており、簡単な手順で復元可能な状態になっている • クラウドなど自宅外のストレージに最新バージョンをバックアップできている バックアップ構成を考え直す 自己紹介 > 障害事例 > バックアップ構成を考える > 各データのバックアップ > クラウドへのバックアップ
5. Application Cluster 4 方針 • 別ディスク・別マシン上にバックアップ用のMinIOを動かし、日次でそれぞれのデータを 増分バックアップする • バックアップ用MinIOに保存されたデータを、Backblaze Cloud Storage（S3互換クラウドストレージ）に 週次でバックアップする バックアップ構成を考え直す MinIO PostgreSQL BackupSystem Cluster MinIO Persistent Volume Backblaze Cloud Storage 日次バックアップ 週次バックアップ 自己紹介 > 障害事例 > バックアップ構成を考える > 各データのバックアップ > クラウドへのバックアップ
6. Manager • PersistentVolumeはLonghornを用いて払い出している • Longhornに搭載されている増分パックアップ機能を用いる • CSI VolumeSnapshot経由で呼び出す • PVCのDataSourceとしてVolume Snapshotを指定するだけで復元できる • CSI VolumeSnapshotを作成するためのトリガーとしてVeleroを用いる • CLIで簡単に復元できる PersistentVolumeのバックアップ Application Cluster BackupSystem Cluster MinIO Backblaze Cloud Storage 週次バックアップ バックアップ実行 Volume PersistentVolume 5 VolumeSnapshot Watch 作成 自己紹介 > 障害事例 > バックアップ構成を考える > 各データのバックアップ > クラウドへのバックアップ
7. 6 • MinIOのデータはRcloneを用いてバックアップ用のMinIOに増分バックアップする • なぜPersistentVolumeのバックアップを利用しないのか • 1. 冗長化のためにパリティデータが保存されている • 2. パフォーマンス向上のためにLocal Path Provisionerを用いている • Local Path ProvisionerはVolumeSnapshot非対応 • BucketでVersioningを有効化することで、過去バージョンの保持に対応 MinIOのバックアップ ʁ $ rclone sync --metrics-addr=:9250 minio-default: minio-biscuit:minio-default-backup/ 自己紹介 > 障害事例 > バックアップ構成を考える > 各データのバックアップ > クラウドへのバックアップ
8. 7 MinIOのバックアップ • MinIOのデータはRcloneを用いてバックアップ用のMinIOに増分バックアップする $ rclone sync --metrics-addr=:9250 minio-default: minio-biscuit:minio-default-backup/ Application Cluster BackupSystem Cluster MinIO Backblaze Cloud Storage 週次バックアップ バックアップ実行 MinIO Rclone Pod Rclone CronJob Create Job 自己紹介 > 障害事例 > バックアップ構成を考える > 各データのバックアップ > クラウドへのバックアップ
9. 8 PostgreSQLのバックアップ • CloudNativePGが備えるバックアップ機能を用いる • Barman Cloud CNPG-I pluginを用いたベースバックアップ＆WALアーカイブ • Backup Clusterではなく、Application ClusterのMinIOに書き込む • WALアーカイブは5分おきに実行されるから • なぜPersistentVolumeのバックアップを利用しないのか • さっきと一緒 ʁ BackupSystem Cluster MinIO Backblaze Cloud Storage 週次バックアップ バックアップ実行 Cluster. postgresql.cnpg.io CloudNativePG Manager MinIO Application Cluster 自己紹介 > 障害事例 > バックアップ構成を考える > 各データのバックアップ > クラウドへのバックアップ
10. 9 B2 Cloud Storageへのバックアップ • BackupSystem ClusterのMinIOは、週次でBackblaze Cloud Storageに同期させる • Versioningはオフ • コスト: $6/1TB/1monthくらい Application Cluster 永続データ BackupSystem Cluster MinIO Backblaze Cloud Storage 日次バックアップ 週次バックアップ バックアップ実行 Rclone Pod Rclone CronJob Create Job 自己紹介 > 障害事例 > バックアップ構成を考える > 各データのバックアップ > クラウドへのバックアップ
11. 10 その他ポイント • MinIO Security Token Serviceを活用 • マルチクラスタでの認証には課題あり • Cilium Cluster Mesh / Multi Cluster Servicesを活用 • MinIOとの通信や、Application Clusterへのメトリクス・ログ送信で利用 • Grafana Alertを設定 自己紹介 > 障害事例 > バックアップ構成を考える > 各データのバックアップ > クラウドへのバックアップ
12. おしまい
13. おしまい でいいんでしょうか？
14. 13 復元 • そのバックアップ、本当に復元できますか？ • 事例 • Longhornのバックアップから、PVを復元する際にエラーになった • Longhornの増分バックアップでは、変更されていないブロックのバリデーションを行わない when a data block in the backupstore becomes corrupted, Longhorn does not replace that data block with a healthy one during subsequent backup operations. 自己紹介 > 障害事例 > バックアップ構成を考える > 各データのバックアップ > クラウドへのバックアップ >リストアテスト > Future Work
15. Application Cluster 14 ⾃動リストアテスト • 定期的にLonghornのバックアップからリストアするテストを行おう！ • 手法 • KubeVirtを使って検証用k8sクラスタを建て、MinIO（BackupSystem Cluster）からPVを復元する • 検証用クラスタは動的に建てることになるので、ClusterAPIを使う • KubeVirtProvider×TalosProvider • fsckも一応しておく Manager Testing Cluster BackupSystem Cluster MinIO バックアップ復元 Volume PersistentVolume VolumeSnapshot Watch 作成 自己紹介 > 障害事例 > バックアップ構成を考える > 各データのバックアップ > クラウドへのバックアップ > リストアテスト > Future Work
16. 15 Future Work（時間があれば） • BackupSystem ClusterのNode起動を自動化 • バックアップクラスタが必要なのはせいぜい数時間 • 時間で起動/シャットダウン • ラベルを使って宣言的に記述 • Pod/Backup.velero.ioが作られた時に起動する • PodはMutatingWebhookでScheduleGateを設定して起動を待つ • // TODO: Backup.velero.ioはどうする？ • MinIO/PostgreSQLの自動リストアテスト 自己紹介 > 障害事例 > バックアップ構成を考える > 各データのバックアップ > クラウドへのバックアップ > リストアテスト > Future Work ❌ ⭕