メインコンテンツにスキップ ナビゲーションにスキップ フッターにスキップ

バックアップと復元

稼働中のリポジトリを2台目のマシンにコピーし、最初のマシンを落としてから、データを取り戻します。

バックアップと復元

本番でアプリが稼働しています。バックアップしましょう。rdc はリポジトリ全体、アプリ、そのデータベース、ファイル、設定を丸ごと2台目のマシンにコピーし、最初のマシンが失われたときにそこから元へ戻します。

このチュートリアルはそれを説明するだけではありません。実際に2台の実機で行い、最後にデータを読み出して確かめます。

3つのステップ

コピー、復元、証明

  1. コピー: リポジトリを自分が管理するマシンにコピーします。
  2. 復元: そのコピーを独立したリポジトリとして復元します。
  3. 証明: データを読み出し、実際に戻ったことを確かめます。

ステップ1: 生き残るべきデータ

rdc term connect my-app --command 'cat orders.txt'

まず稼働中の repository からデータを読み出します。1つのファイルにある1行、それによって最後の証明は信じるしかないものではなく、自分の目で確かめられるものになります。

以下すべての手順は、この一行が生き残るかどうかで判定されます。ステップ7で再びこれを確認します。

ステップ2: リポジトリを2台目のマシンにコピーする

rdc repo push my-app --to machine-12

repository を2台目のマシンにコピーします。最初のプッシュは暗号化されたイメージ全体を転送し、この環境ではおよそ2ギガバイトが30〜40秒で完了します。それ以降のプッシュは変更されたブロックだけを送ります。転送先に届くのはバックアップアーティファクトであり、稼働中の2つ目の repository ではありません。

デルタ転送チュートリアル では、この差分転送の部分をライブで確認できます。

成果物はまだ稼働中のリポジトリではありません。それがステップ5の存在理由です。

ステップ3: バックアップ先のマシンにデータが渡った

rdc repo list --machine machine-12

バックアップマシンに何を保持しているか確認します。コピーは config から解決された自身の名前で表示されます。生の識別子を持つ2行目は保持されたデルタベースであり、これがこのマシンへの次のプッシュを差分転送にしています。

ステップ4: 障害発生

rdc repo down my-app --unmount

プライマリをオフラインにします。サービスを停止し、暗号化ボリュームをアンマウントしてください。これ以降はすべて別のマシンにあるコピーに対して行います。

ステップ5: 成果物をリポジトリに変える

rdc backup restore my-app@machine-12 --as my-app-restored --machine machine-12 --yes

restore は、プッシュされたコピーを repository に変えるコマンドです。名前は --as で指定し、配置先は --machine で指定し、確認は --yes で行います。新しい名前で復元するので何も上書きされず、稼働中のマシンで安全に練習できます。

これは必要になる前に、マシンごとに一度実施しておいてください。一度も往復させたことのないマシンは、プッシュがどれほど順調に見えてもバックアップされているとは言えません。また、新しい名前での復元は、トラフィックを処理中のマシンに対しても安全に行えます。

ステップ6: マウントする

rdc repo up my-app-restored --no-start

復元した repository をマウントします。コンテナはあえて停止したままにします。ここで証明されるのはデータであり、アプリケーションではありません。

ステップ7: データは生き残った

rdc term connect my-app-restored --command 'cat orders.txt'

ステップ1と同じコマンドを、2つ前のコマンドの時点では存在していなかった repository に対して実行します。行はバイト単位で完全に戻ってきます。しかもそれは、一度もオリジナルではなかったマシンからです。

2つを並べてみましょう。ステップ1、プライマリマシン上の元のリポジトリから:

order-1042 paid 2026-08-16

ステップ7、2つ前のコマンドの時点ではまだ存在しなかったリポジトリから、しかも別のハードウェア上で:

order-1042 paid 2026-08-16

これがこのチュートリアルです。バックアップが成功したという報告ではなく、その行自体を、別のマシンから読み戻したのです。

ステップ8: 巻き戻せるバックアップ

rdc backup snapshot my-app

マシンへのコピーは、今の時点の repository をそのまま渡します。さかのぼれる履歴が欲しい場合は、スナップショットをチャンクストアに送ります。最初の実行は書き込まれたブロックをすべてアップロードし、それ以降の実行は変更分だけをアップロードします。どのスナップショットも単独で復元できます。このコマンドはここでは入力するだけで実行しません。アップロードにはアカウントサーバーとライセンス済みの repository が必要で、録画環境にはどちらもないためです。自分の環境でアカウントを持っていれば、これがそのコマンドです。

自分の環境で、アカウントを使う場合の一連の流れは次のとおりです。

rdc backup snapshot my-app
rdc backup manifests my-app
rdc backup restore my-app --as my-app-yesterday --at <snapshot-id> --up

スナップショット、保持期間、検証については バックアップと復元ガイド で詳しく解説しています。


次: ネットワークとドメイン