- TiDBについて
- クイックスタート
- デプロイ
- 移行する
- 管理
- アップグレード
- 規模
- バックアップと復元
- BRツールを使用する(推奨)
- タイムゾーンの構成
- 毎日のチェックリスト
- TiFlashを管理する
- TiUPを使用してTiDBを管理する
- オンラインでConfiguration / コンフィグレーションを変更する
- オンラインの安全でない回復
- 監視と警告
- トラブルシューティング
- 性能チューニング
- システムチューニング
- ソフトウェアのチューニング
- Configuration / コンフィグレーション
- コプロセッサーキャッシュ
- SQLチューニング
- チュートリアル
- TiDBツール
- 概要
- ユースケース
- ダウンロード
- TiUP
- ドキュメントマップ
- 概要
- 用語と概念
- TiUPコンポーネントを管理する
- FAQ
- トラブルシューティングガイド
- コマンドリファレンス
- 概要
- TiUPコマンド
- TiUPクラスターコマンド
- 概要
- tiup cluster audit
- tiup cluster check
- tiup cluster clean
- tiup cluster deploy
- tiup cluster destroy
- tiup cluster disable
- tiup cluster display
- tiup cluster edit-config
- tiup cluster enable
- tiup cluster help
- tiup cluster import
- tiup cluster list
- tiup cluster patch
- tiup cluster prune
- tiup cluster reload
- tiup cluster rename
- tiup cluster replay
- tiup cluster restart
- tiup cluster scale-in
- tiup cluster scale-out
- tiup cluster start
- tiup cluster stop
- tiup cluster template
- tiup cluster upgrade
- TiUPDMコマンド
- 概要
- tiup dm audit
- tiup dm deploy
- tiup dm destroy
- tiup dm disable
- tiup dm display
- tiup dm edit-config
- tiup dm enable
- tiup dm help
- tiup dm import
- tiup dm list
- tiup dm patch
- tiup dm prune
- tiup dm reload
- tiup dm replay
- tiup dm restart
- tiup dm scale-in
- tiup dm scale-out
- tiup dm start
- tiup dm stop
- tiup dm template
- tiup dm upgrade
- TiDBクラスタートポロジリファレンス
- DMクラスタートポロジリファレンス
- ミラーリファレンスガイド
- TiUPコンポーネント
- TiDB Operator
- バックアップと復元(BR)
- TiDB Binlog
- TiDB Lightning
- TiDBデータ移行
- TiDBデータ移行について
- DMの概要
- 基本的な機能
- 高度な機能
- シャーディングされたテーブルからのデータのマージと移行
- GH-ost/PT-oscを使用するMySQLデータベースからの移行
- SQL式を使用してDMLをフィルタリングする
- DMアーキテクチャ
- ベンチマーク
- クイックスタート
- データ移行シナリオ
- デプロイ
- 管理
- ツール
- クラスターのアップグレード
- データソースを作成する
- データソースの管理
- データ移行タスクの管理
- シャーディングDDLロックを手動で処理する
- 移行するMySQLインスタンスを切り替える
- 移行するテーブルのスキーマを管理する
- アラートを処理する
- デイリーチェック
- トラブルシューティング
- 性能チューニング
- 参照
- セキュリティ
- モニタリング指標
- アラートルール
- エラーコード
- FAQ
- 用語集
- 例
- リリースノート
- TiCDC
- Dumpling
- sync-diff-inspector
- TiSpark
- 参照
- クラスターアーキテクチャ
- 主要な監視指標
- セキュリティ
- 権限
- SQL
- SQL言語の構造と構文
- SQLステートメント
ADD COLUMN
ADD INDEX
ADMIN
ADMIN CANCEL DDL
ADMIN CHECKSUM TABLE
ADMIN CHECK [TABLE|INDEX]
ADMIN SHOW DDL [JOBS|QUERIES]
ADMIN SHOW TELEMETRY
ALTER DATABASE
ALTER INDEX
ALTER INSTANCE
ALTER PLACEMENT POLICY
ALTER TABLE
ALTER USER
ANALYZE TABLE
BACKUP
BEGIN
CHANGE COLUMN
COMMIT
CHANGE DRAINER
CHANGE PUMP
CREATE [GLOBAL|SESSION] BINDING
CREATE DATABASE
CREATE INDEX
CREATE PLACEMENT POLICY
CREATE ROLE
CREATE SEQUENCE
CREATE TABLE LIKE
CREATE TABLE
CREATE USER
CREATE VIEW
DEALLOCATE
DELETE
DESC
DESCRIBE
DO
DROP [GLOBAL|SESSION] BINDING
DROP COLUMN
DROP DATABASE
DROP INDEX
DROP PLACEMENT POLICY
DROP ROLE
DROP SEQUENCE
DROP STATS
DROP TABLE
DROP USER
DROP VIEW
EXECUTE
EXPLAIN ANALYZE
EXPLAIN
FLASHBACK TABLE
FLUSH PRIVILEGES
FLUSH STATUS
FLUSH TABLES
GRANT <privileges>
GRANT <role>
INSERT
KILL [TIDB]
LOAD DATA
LOAD STATS
MODIFY COLUMN
PREPARE
RECOVER TABLE
RENAME INDEX
RENAME TABLE
REPLACE
RESTORE
REVOKE <privileges>
REVOKE <role>
ROLLBACK
SELECT
SET DEFAULT ROLE
SET [NAMES|CHARACTER SET]
SET PASSWORD
SET ROLE
SET TRANSACTION
SET [GLOBAL|SESSION] <variable>
SHOW ANALYZE STATUS
SHOW [BACKUPS|RESTORES]
SHOW [GLOBAL|SESSION] BINDINGS
SHOW BUILTINS
SHOW CHARACTER SET
SHOW COLLATION
SHOW [FULL] COLUMNS FROM
SHOW CONFIG
SHOW CREATE PLACEMENT POLICY
SHOW CREATE SEQUENCE
SHOW CREATE TABLE
SHOW CREATE USER
SHOW DATABASES
SHOW DRAINER STATUS
SHOW ENGINES
SHOW ERRORS
SHOW [FULL] FIELDS FROM
SHOW GRANTS
SHOW INDEX [FROM|IN]
SHOW INDEXES [FROM|IN]
SHOW KEYS [FROM|IN]
SHOW MASTER STATUS
SHOW PLACEMENT
SHOW PLACEMENT FOR
SHOW PLACEMENT LABELS
SHOW PLUGINS
SHOW PRIVILEGES
SHOW [FULL] PROCESSSLIST
SHOW PROFILES
SHOW PUMP STATUS
SHOW SCHEMAS
SHOW STATS_HEALTHY
SHOW STATS_HISTOGRAMS
SHOW STATS_META
SHOW STATUS
SHOW TABLE NEXT_ROW_ID
SHOW TABLE REGIONS
SHOW TABLE STATUS
SHOW [FULL] TABLES
SHOW [GLOBAL|SESSION] VARIABLES
SHOW WARNINGS
SHUTDOWN
SPLIT REGION
START TRANSACTION
TABLE
TRACE
TRUNCATE
UPDATE
USE
WITH
- データ型
- 関数と演算子
- クラスター化インデックス
- 制約
- 生成された列
- SQLモード
- テーブル属性
- トランザクション
- ガベージコレクション(GC)
- ビュー
- パーティショニング
- 一時的なテーブル
- 文字セットと照合
- SQLの配置ルール
- システムテーブル
mysql
- INFORMATION_SCHEMA
- 概要
ANALYZE_STATUS
CLIENT_ERRORS_SUMMARY_BY_HOST
CLIENT_ERRORS_SUMMARY_BY_USER
CLIENT_ERRORS_SUMMARY_GLOBAL
CHARACTER_SETS
CLUSTER_CONFIG
CLUSTER_HARDWARE
CLUSTER_INFO
CLUSTER_LOAD
CLUSTER_LOG
CLUSTER_SYSTEMINFO
COLLATIONS
COLLATION_CHARACTER_SET_APPLICABILITY
COLUMNS
DATA_LOCK_WAITS
DDL_JOBS
DEADLOCKS
ENGINES
INSPECTION_RESULT
INSPECTION_RULES
INSPECTION_SUMMARY
KEY_COLUMN_USAGE
METRICS_SUMMARY
METRICS_TABLES
PARTITIONS
PLACEMENT_RULES
PROCESSLIST
REFERENTIAL_CONSTRAINTS
SCHEMATA
SEQUENCES
SESSION_VARIABLES
SLOW_QUERY
STATISTICS
TABLES
TABLE_CONSTRAINTS
TABLE_STORAGE_STATS
TIDB_HOT_REGIONS
TIDB_HOT_REGIONS_HISTORY
TIDB_INDEXES
TIDB_SERVERS_INFO
TIDB_TRX
TIFLASH_REPLICA
TIKV_REGION_PEERS
TIKV_REGION_STATUS
TIKV_STORE_STATUS
USER_PRIVILEGES
VIEWS
METRICS_SCHEMA
- UI
- TiDBダッシュボード
- 概要
- 管理
- アクセス
- 概要ページ
- クラスター情報ページ
- Top SQL
- キービジュアライザーページ
- メトリクス関係グラフ
- SQLステートメント分析
- 遅いクエリページ
- クラスター診断
- 検索ログページ
- インスタンスプロファイリング
- セッションの管理とConfiguration / コンフィグレーション
- FAQ
- CLI
- コマンドラインフラグ
- Configuration / コンフィグレーションファイルのパラメーター
- システム変数
- ストレージエンジン
- テレメトリー
- エラーコード
- テーブルフィルター
- トポロジラベルによるレプリカのスケジュール
- よくある質問
- リリースノート
- すべてのリリース
- リリースタイムライン
- TiDBバージョニング
- v5.4
- v5.3
- v5.2
- v5.1
- v5.0
- v4.0
- v3.1
- v3.0
- v2.1
- v2.0
- v1.0
- 用語集
古いバージョンの TiDB データベース (TiDB {{ curdocVersion }}) のドキュメントを表示しています。
BRツールの概要
BR (バックアップと復元)は、TiDBクラスタデータの分散バックアップと復元のためのコマンドラインツールです。
Dumplingと比較して、BRは大量のデータを含むシナリオに適しています。
定期的なバックアップと復元に加えて、互換性が確保されている限り、BRを使用して大規模なデータ移行を行うこともできます。
このドキュメントでは、BRの実装原則、推奨される展開構成、使用制限、およびBRを使用するためのいくつかの方法について説明します。
実装の原則
BRは、バックアップまたは復元コマンドを各TiKVノードに送信します。これらのコマンドを受信した後、TiKVは対応するバックアップまたは復元操作を実行します。
各TiKVノードには、バックアップ操作で生成されたバックアップファイルが保存され、復元中に保存されたバックアップファイルが読み取られるパスがあります。
バックアップの原則
BRがバックアップ操作を実行すると、最初にPDから次の情報を取得します。
- バックアップスナップショットの時刻としての現在のTS(タイムスタンプ)
- 現在のクラスタのTiKVノード情報
これらの情報に従って、BRは内部でmysql
インスタンスを起動して、TSに対応するデータベースまたはテーブル情報を取得し、同時にシステムデータベース( information_schema
)を除外しperformance_schema
。
backupサブコマンドによると、BRは次の2種類のバックアップロジックを採用しています。
- 完全バックアップ:BRはすべてのテーブルをトラバースし、各テーブルに従ってバックアップされるKV範囲を構築します。
- 単一テーブルのバックアップ:BRは、単一のテーブルに従ってバックアップされるKV範囲を構築します。
最後に、BRはバックアップするKV範囲を収集し、完全なバックアップ要求をクラスタのTiKVノードに送信します。
リクエストの構造:
BackupRequest{
ClusterId, // The cluster ID.
StartKey, // The starting key of the backup (backed up).
EndKey, // The ending key of the backup (not backed up).
StartVersion, // The version of the last backup snapshot, used for the incremental backup.
EndVersion, // The backup snapshot time.
StorageBackend, // The path where backup files are stored.
RateLimit, // Backup speed (MB/s).
}
バックアップ要求を受信した後、TiKVノードはノード上のすべてのリージョンリーダーをトラバースして、この要求のKV範囲と重複するリージョンを見つけます。 TiKVノードは、範囲内のデータの一部またはすべてをバックアップし、対応するSSTファイルを生成します。
対応するリージョンのデータのバックアップが終了すると、TiKVノードはメタデータをBRに返します。 BRはメタデータを収集し、復元に使用されるbackupmeta
のファイルに保存します。
StartVersion
が0
でない場合、バックアップは増分バックアップと見なされます。 KVに加えて、BRは[StartVersion, EndVersion)
の間のDDLも収集します。データの復元中に、これらのDDLが最初に復元されます。
バックアップコマンドの実行時にチェックサムが有効になっている場合、BRはデータチェックのためにバックアップされた各テーブルのチェックサムを計算します。
バックアップファイルの種類
バックアップファイルが保存されるパスには、次の2種類のバックアップファイルが生成されます。
- SSTファイル:TiKVノードがバックアップしたデータを保存します。
backupmeta
ファイル:バックアップファイルの数、キー範囲、サイズ、ハッシュ(sha256)値など、このバックアップ操作のメタデータを格納します。backup.lock
ファイル:複数のバックアップ操作が同じディレクトリにデータを保存するのを防ぎます。
SSTファイル名の形式
SSTファイルはstoreID_regionID_regionEpoch_keyHash_cf
の形式で名前が付けられます。ここで
storeID
はTiKVノードIDです。regionID
はリージョンIDです。regionEpoch
はリージョンのバージョン番号です。keyHash
は、範囲のstartKeyのハッシュ(sha256)値であり、キーの一意性を保証します。cf
はRocksDBのカラムファミリーを示します(デフォルトではdefault
またはwrite
)。
修復の原則
データ復元プロセス中に、BRは次のタスクを順番に実行します。
バックアップパス内の
backupmeta
のファイルを解析し、内部でTiDBインスタンスを起動して、解析された情報に基づいて対応するデータベースとテーブルを作成します。解析されたSSTファイルをテーブルに従って集約します。
SSTファイルのキー範囲に従ってリージョンを事前に分割し、すべてのリージョンが少なくとも1つのSSTファイルに対応するようにします。
復元する各テーブルと、各テーブルに対応するSSTファイルをトラバースします。
SSTファイルに対応するリージョンを見つけ、ファイルをダウンロードするために対応するTiKVノードにリクエストを送信します。次に、ファイルが正常にダウンロードされた後、ファイルのロード要求を送信します。
TiKVがSSTファイルをロードする要求を受信した後、TiKVはRaftメカニズムを使用して、SSTデータの強力な整合性を確保します。ダウンロードしたSSTファイルが正常に読み込まれると、ファイルは非同期で削除されます。
復元操作が完了すると、BRは復元されたデータに対してチェックサム計算を実行して、保存されたデータとバックアップされたデータを比較します。
デプロイを導入して使用する
推奨される展開構成
- PDノードにBRを展開することをお勧めします。
- 高性能SSDをBRノードとすべてのTiKVノードにマウントすることをお勧めします。 10ギガビットのネットワークカードをお勧めします。そうしないと、バックアップおよび復元プロセス中に帯域幅がパフォーマンスのボトルネックになる可能性があります。
ノート:
ネットワークディスクをマウントしない場合、または他の共有ストレージを使用する場合、BRによってバックアップされたデータは各TiKVノードで生成されます。 BRはリーダーのレプリカのみをバックアップするため、リーダーのサイズに基づいて各ノードに予約されているスペースを見積もる必要があります。
TiDBはデフォルトで負荷分散にリーダー数を使用するため、リーダーのサイズは大きく異なる可能性があります。これにより、各ノードでバックアップデータが不均一に分散される可能性があります。
使用制限
バックアップと復元にBRを使用する場合の制限は次のとおりです。
- BRがTiCDC/ Drainerのアップストリームクラスタにデータを復元する場合、TiCDC/ Drainerは復元されたデータをダウンストリームに複製できません。
- BRはKVデータのみをバックアップするため、BRは同じ
new_collations_enabled_on_first_bootstrap
の値を持つクラスター間の操作のみをサポートします。バックアップするクラスタと復元するクラスタが異なる照合を使用する場合、データ検証は失敗します。したがって、クラスタを復元する前に、select VARIABLE_VALUE from mysql.tidb where VARIABLE_NAME='new_collation_enabled';
ステートメントのクエリ結果からのスイッチ値がバックアッププロセス中のスイッチ値と一致していることを確認してください。
互換性
BRとTiDBクラスタの互換性の問題は、次のカテゴリに分類されます。
BRの一部のバージョンは、TiDBクラスタのインターフェースと互換性がありません。
- v5.4.0より前のBRバージョンは、
charset=GBK
のテーブルのリカバリーをサポートしていません。 v5.4.0より前のバージョンのBRは、charset=GBK
のテーブルをTiDBクラスターにリカバリーすることをサポートしていません。
- v5.4.0より前のBRバージョンは、
一部の機能が有効または無効になると、KV形式が変更される場合があります。これらの機能がバックアップおよび復元中に一貫して有効または無効にされていない場合、互換性の問題が発生する可能性があります。
これらの機能は次のとおりです。
特徴 | 関連する問題 | ソリューション |
---|---|---|
クラスター化されたインデックス | #565 | 復元中のtidb_enable_clustered_index のグローバル変数の値が、バックアップ中の値と一致していることを確認してください。そうしないと、 default not found やデータインデックスの不整合など、データの不整合が発生する可能性があります。 |
新しい照合順序 | #352 | new_collations_enabled_on_first_bootstrap 変数の値がバックアップ中の値と一致していることを確認してください。そうしないと、一貫性のないデータインデックスが発生し、チェックサムが渡されない可能性があります。 |
復元クラスタでTiCDCが有効になっている | #364 | 現在、TiKVはBRを取り込んだSSTファイルをTiCDCにプッシュダウンできません。したがって、BRを使用してデータを復元する場合は、TiCDCを無効にする必要があります。 |
グローバル一時テーブル | データのバックアップと復元には、BRv5.3.0以降のバージョンを使用していることを確認してください。そうしないと、バックアップされたグローバル一時テーブルの定義でエラーが発生します。 |
ただし、バックアップと復元中に上記の機能が一貫して有効または無効になっていることを確認した後でも、BRとTiKV / TiDB / PD間の内部バージョンまたはインターフェイスの一貫性がないため、互換性の問題が発生する可能性があります。このようなケースを回避するために、BRにはバージョンチェックが組み込まれています。
バージョンチェック
バックアップと復元を実行する前に、BRはTiDBクラスタのバージョンとBRのバージョンを比較して確認します。メジャーバージョンの不一致(たとえば、BRv4.xとTiDBv5.x)がある場合、BRは終了するようにリマインダーを表示します。バージョンチェックを強制的にスキップするには、 --check-requirements=false
を設定します。
バージョンチェックをスキップすると、非互換性が生じる可能性があることに注意してください。 BRバージョンとTiDBバージョン間のバージョン互換性情報は次のとおりです。
バックアップバージョン(垂直)\復元バージョン(水平) | 毎晩BRを使用して、毎晩TiDBを復元します | BRv5.0を使用してTiDBv5.0を復元します | BRv4.0を使用してTiDBv4.0を復元します |
---|---|---|---|
毎晩BRを使用してTiDBを毎晩バックアップします | ✅ | ✅ | ❌(非整数のクラスター化インデックスタイプの主キーを持つテーブルがTiDB v4.0クラスタに復元された場合、BRは警告なしにデータエラーを引き起こします。) |
BRv5.0を使用してTiDBv5.0をバックアップします | ✅ | ✅ | ❌(非整数のクラスター化インデックスタイプの主キーを持つテーブルがTiDB v4.0クラスタに復元された場合、BRは警告なしにデータエラーを引き起こします。) |
BRv4.0を使用してTiDBv4.0をバックアップします | ✅ | ✅ | ✅(TiKV> = v4.0.0-rc.1で、BRに#233のバグ修正が含まれ、TiKVに#7241のバグ修正が含まれていない場合、BRによってTiKVノードが再起動します。) |
BRnightlyまたはv5.0を使用してTiDBv4.0をバックアップします | ❌(TiDBバージョンがv4.0.9より前の場合、 #609の問題が発生する可能性があります。) | ❌(TiDBバージョンがv4.0.9より前の場合、 #609の問題が発生する可能性があります。) | ❌(TiDBバージョンがv4.0.9より前の場合、 #609の問題が発生する可能性があります。) |
mysql
システムスキーマのテーブルデータをバックアップおよび復元します(実験的機能)
この機能は実験的であり、徹底的にテストされていません。この機能を実稼働環境で使用することは強くお勧めしません。
v5.1.0より前では、BRはバックアップ中にシステムスキーマmysql
からデータを除外していました。 v5.1.0以降、BRは、システムスキーマmysql.*
を含むすべてのデータをデフォルトでバックアップします。ただし、 mysql.*
でシステムテーブルを復元する技術的な実装はまだ完了していないため、システムスキーマmysql
のテーブルはデフォルトでは復元されません。
システムテーブルのデータ(たとえば、 mysql.usertable1
)をシステムスキーマmysql
に復元する場合は、 filter
パラメータを設定してテーブル名( -f "mysql.usertable1"
)をフィルタリングできます。設定後、システムテーブルは最初に一時スキーマに復元され、次に名前を変更してシステムスキーマに復元されます。
以下のシステムテーブルは、技術的な理由により正しく復元できないことに注意してください。 -f "mysql.*"
を指定しても、次のテーブルは復元されません。
- 統計に関連するテーブル: "stats_buckets"、 "stats_extended"、 "stats_feedback"、 "stats_fm_sketch"、 "stats_histograms"、 "stats_meta"、 "stats_top_n"
- 特権またはシステムに関連するテーブル: "tidb"、 "global_variables"、 "columns_priv"、 "db"、 "default_roles"、 "global_grants"、 "global_priv"、 "role_edges"、 "tables_priv"、 "user"、 "gc_delete_range "、" Gc_delete_range_done "、" schema_index_usage "
BRの実行に必要な最小マシン構成
BRの実行に必要な最小マシン構成は次のとおりです。
CPU | メモリー | ハードディスクの種類 | 通信網 |
---|---|---|---|
1コア | 4ギガバイト | HDD | ギガビットネットワークカード |
一般的なシナリオ(バックアップと復元用に1000テーブル未満)では、実行時のBRのCPU消費量は200%を超えず、メモリ消費量は4GBを超えません。ただし、多数のテーブルをバックアップおよび復元する場合、BRは4GBを超えるメモリを消費する可能性があります。 24000テーブルをバックアップするテストでは、BRは約2.7 GBのメモリを消費し、CPU消費量は100%未満のままです。
ベストプラクティス
以下は、BRを使用するためのいくつかの推奨操作です。
- アプリケーションへの影響を最小限に抑えるために、オフピーク時にバックアップ操作を実行することをお勧めします。
- データを復元するとき、BRはターゲットクラスタのリソースを可能な限り消費します。したがって、データを新しいクラスターまたはオフラインクラスターに復元することをお勧めします。稼働中の本番クラスタにデータを復元しないでください。そうしないと、サービスが影響を受ける可能性があります。
- 複数のバックアップまたは復元操作を1つずつ実行することをお勧めします。バックアップまたは復元操作を並行して実行すると、パフォーマンスが低下し、オンラインアプリケーションにも影響します。さらに悪いことに、複数のタスク間のコラボレーションが不足していると、タスクが失敗し、クラスタのパフォーマンスに影響を与える可能性があります。
- バックアップデータの保存には、Amazon S3、Google Cloud Storage、AzureBlobStorageをお勧めします。
- BRノードとTiKVノード、およびバックアップストレージバックエンドに、読み取りと書き込みのパフォーマンスを確保するのに十分なネットワーク帯域幅があることを確認してください。不十分なストレージ容量は、バックアップまたは復元操作のボトルネックになる可能性があります。
BRの使い方
現在、BRツールを実行するために次のメソッドがサポートされています。
- SQLステートメントを使用する
- コマンドラインツールを使用する
- Kubernetes環境でBRを使用する
SQLステートメントを使用する
TiDBは、 BACKUP
つとRESTORE
のSQLステートメントの両方をサポートします。これらの操作の進行状況は、ステートメントSHOW BACKUPS|RESTORES
で監視できます。
コマンドラインツールを使用する
br
コマンドラインユーティリティは別ダウンロードとして使用できます。詳細については、 バックアップと復元にBRコマンドラインを使用するを参照してください。
Kubernetes環境で
Kubernetes環境では、BRツールを使用してTiDBクラスタデータをS3互換ストレージ、Google Cloud Storage(GCS)、永続ボリューム(PV)にバックアップし、それらを復元できます。
ノート:
AmazonS3およびGoogleCloudStorageのパラメーターの説明については、 外部ストレージのドキュメントを参照してください。
- BRを使用してS3互換ストレージにデータをバックアップする
- BRを使用してS3互換ストレージからデータを復元する
- BRを使用してデータをGCSにバックアップする
- BRを使用してGCSからデータを復元する
- BRを使用してデータをPVにバックアップする
- BRを使用してPVからデータを復元する