前回の記事では、ResticとCloudflare R2、そして宅内NASを組み合わせて、WordOps環境のWordPressサイトを毎日午前3時に完全自動でバックアップする仕組みを構築しました。
自動化のログが綺麗に流れるのを見て、ひとまずはホッと胸を撫で下ろしていることと思います。
しかし、バックアップの世界には避けては通れない過酷な鉄則があります。
「復元（リストア）できないバックアップは、ただの自己満足である」
ということです。どれだけ完璧にデータを外へ逃がしていても、いざ自宅サーバーが物理的に大破した時、あるいはOSがクラッシュした時に、元通りに動く状態まで戻せなければ何の意味もありません。
そこで今回は、前回の予告通り万が一サーバーが完全に真っ白になっても、数分で元のWordPress環境を完全に元通りにする爆速リストア手順を徹底解説します！
WordOpsの特殊なパス構造に対応し、データベースのインポートからWordPress本体ファイルの復旧まで、コマンド数発で迷わず完遂できる「失敗しないための完全マニュアル」です。さっそく、絶望を希望に変えるリカバリの術式を発動しましょう！
リストアが必要になる状況と「3つ」の前提条件
どれだけ頑丈な自宅サーバーを組んでいても、データが消し飛ぶときは一瞬です。まずは「どんな絶望的状況から復元可能なのか」というシチュエーションと、爆速リカバリを発動するために最低限揃えておくべき前提条件を整理します。
🚨 想定される絶望的なシチュエーション
この記事の手順が真価を発揮するのは、以下のような「完全にイチから環境を作り直さなければならない」状態です。
- 物理的崩壊： 自宅サーバーのSSDが突然死した、あるいは電源ユニットが巻き添えを起こして物理的に大破した場合。
- 論理的崩壊： OSのアップデートに失敗して起動不可になった、またはコマンドの誤操作（
rm -rfなど）でシステムを自ら破壊した場合。 - サイバー攻撃： サーバーに不正侵入され、WordPressのコアファイルを改ざんされたり、データベースを暗号化されたりした場合（例：ランサムウェアによる身代金要求など）。
🔑 リストアを成功させるための「3つ」の前提条件
いくらResticとCloudflare R2（またはNAS）が最強の組み合わせとはいえ、手元に何も情報が残っていなければデータは引き出せません。サーバーが大破したあと、新しい環境で以下の3点がしっかり揃っていることをまずは確認してください。
- 新しいUbuntuサーバー（WordOpsインストール済み）
ハードウェアの買い直しや初期化を済ませ、OSが立ち上がりwoコマンドが叩ける状態に戻しておきます。 - Resticの暗号化パスワード
バックアップ構築時に設定した、リポジトリ（保管庫）を開くための共通パスワードです。これが無いと強固な暗号化の前に弾かれるため、必ず手元に控えておいてください。 - Cloudflare R2（またはNAS）への接続キー
自動化スクリプトにも仕込んでいたACCESS_KEY_IDとSECRET_ACCESS_KEY、およびバケットのエンドポイントURLです。外のストレージからデータを引き出すための「命綱」になります。
Resticリポジトリの再接続と生存確認
新しいUbuntuサーバーが立ち上がり、WordOpsのインストールが済んだら、まずは外の世界（Cloudflare R2や宅内NAS）に無事保管されているバックアップデータを、この新しいサーバーに認識させます。
暗号化された保管庫（リポジトリ）の生存を確認し、中身のセーブデータ（スナップショット）の一覧を呼び出すまでの手順です。
🔑 1. 接続キーの環境変数への登録
まずはResticがCloudflare R2へアクセスできるように、認証情報を新しいサーバーのターミナルに一時的に記憶させます。（※今回は手動操作のため、コマンドラインに直接入力します）
export AWS_ACCESS_KEY_ID="あなたのCloudflareアクセスキーID"
export AWS_SECRET_ACCESS_KEY="あなたのCloudflareシークレットアクセスキー"
export RESTIC_PASSWORD="前回決めたResticの共通パスワード"
export AWS_ACCESS_KEY_ID="Your Cloudflare Access Key ID"
export AWS_SECRET_ACCESS_KEY="Your Cloudflare Secret Access Key"
export RESTIC_PASSWORD="Your previously configured Restic shared password"📡 2. 保管庫の生存確認（スナップショット一覧の取得）
準備ができたら、Cloudflare R2に繋いで「過去のバックアップデータがちゃんと存在しているか」を確認するコマンドを叩きます。
# Cloudflare R2からスナップショット一覧を表示
restic -r s3:https://あなたのS3_API_エンドポイント/server-backup snapshots
# Display the snapshot list from Cloudflare R2
restic -r s3:https://your-S3-API-endpoint/server-backup snapshotsコマンドを実行し、ターミナルに以下のようなリストが表示されればデータとの再接続は完全成功です！
repository cee439d8 opened (version 2, compression level auto)
ID Time Host Tags Paths
---------------------------------------------------------------------------------------------------
9fb4c723 2026-07-19 01:05:39 tset-system /var/www/test-site.online/htdocs
/tmp/wp_backup_files
---------------------------------------------------------------------------------------------------
1 snapshots💡 ここで確認すべきポイント
- ID（スナップショットID）：
9fb4c723といった8桁の英数字が、あなたのサイトの「セーブデータの識別番号」になります。リストアの際にこのIDを指定するため、メモ帳などにコピーしておきましょう。 - Paths（バックアップ元パス）：
復元したいサイトのWordOpsのパス（/var/www/test-site.online/htdocs)）がしっかり含まれているかを確認します。
WordPress本体ファイル（htdocs）の爆速展開
リポジトリとの接続が無事に確認できたら、いよいよ真っ白になったサーバーにWordPressの本体ファイル（画像、テーマ、プラグインなど）を力技で引き戻します。
Resticの素晴らしいところは、特定のフォルダだけを狙い撃ちして、元のディレクトリ構造を維持したまま爆速で復元できる点です。
🚨 リストアを実行する前の「超重要」な鉄則
ファイルを復元する前に、新しいUbuntuサーバー側であらかじめWordOpsのサイト作成コマンドを実行し、WordPressの「器（空のフォルダと設定）」だけを作っておく必要があります。
# 対象ドメインの「器」を新規に作成（DBも自動生成されます）
# Create a new site container for the target domain (the database will also be created automatically)
wo site create test-site.online --wp💡 なぜこの手順が必要か？
フォルダが空っぽの状態でResticから中身だけをドロップするためです。WordOpsのシステム側に「ここに新しくサイトを作ったよ」と正しく認識させるため、必ず先に器を作っておいてください。
📂 コマンド一発でファイルを元の場所に解凍する
準備ができたら、先ほど確認した「スナップショットID」を指定して、データをサーバーのルート（/）に向けて流し込みます。
# スナップショットID（例: 9fb4c723）を指定して本体ファイルを復元
restic -r s3:https://あなたのS3_API_エンドポイント/server-backup \
restore 9fb4c723 --target /
# Restore the WordPress files by specifying the snapshot ID (e.g., 9fb4c723)
restic -r s3:https://your-S3-API-endpoint/server-backup \
restore 9fb4c723 --target✍️ --target / の魔法
Resticはバックアップした時の絶対パス（/var/www/...）をそのまま記憶しています。そのため、展開先（--target）にルートディレクトリ（/）を指定してあげるだけで、自動的に正しい場所（/var/www/[test-site.online）へ寸分の狂いもなくファイルが上書き復元されます。
展開が終わったら、念のためファイルが戻っているか確認してみましょう。
ls -la /var/www/your-domain.com/htdocs無事にいつものWordPressのファイル群（wp-config.php や wp-content フォルダなど）がズラリと並んでいれば、ファイルの実体復旧は完了です！
データベース（MariaDB）のインポートと権限の復旧
本体ファイルの展開が終わると、バックアップ時に同時に保存されていた「データベースのダンプファイル（.sql.gz）」が、一時フォルダ（/tmp/wp_backup_files/）の中に自動的に復元されています。
最後の仕上げとして、このSQLデータをWordOpsが新しく生成したデータベースへ流し込み、正常にWebサイトが表示される状態まで持っていきます。
🔑 1. 新しいデータベース名とパスワードの確認
WordOpsでサイトを再作成した際、内部のデータベース名やユーザーパスワードはランダムに新規生成されています。Resticから上書きされた wp-config.php の記述は「古い情報」になっているため、まずは新環境の正しいDB情報を確認します。
# WordOpsのサイト設定から、新しく生成されたDB情報を確認
# Check the newly generated database information in the WordOps site configuration
wo site info test-site.online出力された結果から、以下の3つの値をメモします。
- DB Name （データベース名）
- DB User （データベースユーザー名）
- DB Password （データベースパスワード）
📝 2. wp-config.php の一時退避と修正
Resticによって復元された過去の wp-config.php のままだと、新しいデータベースに接続できず「データベース接続確立のエラー」が発生します。
そのまま wp-config.php を開き、先ほど wo site info で確認した「新しいDB名・ユーザー名・パスワード」へ書き換えて保存してください。
📥 3. データベースの流し込み（インポート）
準備が整ったら、一時フォルダに解凍されているSQLファイルを、MariaDBコマンドを使って新しいデータベースへ一気に流し込みます。
# 圧縮されたSQLを展開しながら、新しいデータベースへインポート
# Decompress the SQL dump and import it into the new database
zcat /tmp/wp_backup_files/your-db-name.sql.gz | mariadb -u root -p※パスワードを求められるので、サーバーのrootパスワードを入力します。
🛠️ 4. 仕上げ：ファイル権限（パーミッション）の完全修復
Resticは権限を維持したままファイルを復元してくれますが、WordOps環境のNginxやPHPが正常にファイルを読み書きできるよう、最後に以下のコマンドを叩いてWordPressディレクトリの所有権を www-data（Webサーバーの権限）に完全最適化します。
# 所有権をWordOpsの標準であるwww-dataに一括変更
# Recursively change ownership to WordOps' default user and group, www-data
chown -R www-data:www-data /var/www/test-site.online/htdocs
chmod -R 755 /var/www/test-site.online/htdocsこれで、ブラウザから自分のサイト（https://test-site.online）にアクセスしてみてください。 真っ白だった画面に、崩壊前と全く同じ、いつもの見慣れたブログのトップページが爆速で大復活しているはずです！
⚠️ 複数サイトをリストアする際の2つの注意点
1. スナップショットIDの間違いに注意
「Resticリポジトリの再接続と生存確認」で restic snapshots を叩いたとき、複数サイトをバックアップしている場合は、以下のようにそれぞれのサイトの履歴（スナップショット）がズラリと並びます。
ID Time Paths
----------------------------------------------------------------------
9fb4c723 2026-07-19 01:05:39 /var/www/site-A.com/htdocs ...
a1b2c3d4 2026-07-19 01:10:22 /var/www/site-B.com/htdocs ...本体ファイルを展開（restore）するときは、必ず「復元したいドメインのパス」に対応する正しいID（9fb4c723 や a1b2c3d4）を1つずつ指定して実行してください。
2. SQLファイルの上書きに注意
もしバックアップスクリプトの仕様で、全サイトのSQLダンプファイルが /tmp/wp_backup_files/ という「同じ一時フォルダ」の中に、ドメイン名を含まない固定のファイル名（例: wordpress.sql.gz）で出力されるようになっている場合、連続して restore コマンドを叩くと、後に実行したサイトのSQLファイルで上書きされてしまう可能性があります。
安全に処理するなら、以下の手順で1サイトずつ完全に終わらせてから次に行くのが一番確実です。
🔄 複数サイト時の安全な巡回ルーティン（1サイトずつ完結させる）
- 【サイトAの復元】
wo site create site-A.com --wpで器を作る- サイトAの ID を指定して
restic restore [ID] --target / /tmp/wp_backup_files/に戻ってきたSQLを、サイトAの新DBにインポート- サイトAの権限修復（
chown）
- 【サイトBの復元】
wo site create site-B.com --wpで器を作る- サイトBの ID を指定して
restic restore [ID] --target / /tmp/wp_backup_files/に戻ってきた（新しく上書きされた）SQLを、サイトBの新DBにインポート- サイトBの権限修復（
chown）
このように「1サイトずつ器を作って、ファイルを戻して、DBを流し込む」というセットをドメインの数だけ繰り返してあげれば、何サイトあっても安全かつ確実に完全復旧できます！
まとめ：バックアップを「本当の安心」に変えるために
バックアップの仕組みを作ることは、いわば「お守り」を持つようなものです。しかし、そのお守りが本当に自分を救ってくれるかどうかは、このリストア（復元）の手順を知って、いつでも戻せる自信があって初めて「本物の安心」に変わります。
万が一、自宅サーバーが真っ白になるような絶望的状況が訪れても、慌てずにこの記事を上から順番に読み直してください。用意しておいたCloudflare R2（またはNAS）のデータと、数発のコマンドが、あなたのブログを必ず元の姿へと爆速で引き戻してくれます。
データ防衛の旅、本当にお疲れ様でした！これからは、何が起きても怖くない最強の自宅サーバーライフを存分に楽しんでください！
コメント