ウェブサイトのステージングサイトのバックアップ方法

ステージング環境の変更を本番環境にデプロイしようとしたところ、ふと立ち止まり、「まずバックアップを取るべきだろうか」と考え込んでしまいました。

その直感は正しい。

ほとんどのWordPressチュートリアルでは、変更を反映する前に本番サイトのバックアップを取るよう推奨しています。それは良いアドバイスですが、それは全体像の半分に過ぎません。

ステージング環境にも独自のバックアップが必要です。プッシュに失敗したり、ステージング環境が破損したりすると、何時間もかけて構築したテスト用のベースラインが失われてしまいます。それを元に戻せる本番環境のバックアップなど、この世に存在しません。

実際にそんな場面を目にしたことがある。プッシュの失敗でステージングサイトが完全に消去されてしまったのだ。変更内容はすべて失われてしまった。残された選択肢は、記憶を頼りにサイトを再構築し、すべてを再テストすることだけだった。

このチュートリアルでは、本番環境へのデプロイを行う前に、ステージングサイトのバックアップを取る手順を詳しく解説します。このチュートリアルを終える頃には、ステージング環境と本番サイトの両方の完全なバックアップが作成されているため、万が一問題が発生しても安心してデプロイを行うことができます。

以下はその要点である：

• 本番環境のバックアップだけでは不十分です。変更を反映させる前に、ステージング環境と本番環境の両方をバックアップする必要があります。
• ステージングバックアップは、プッシュの失敗によってテスト環境が破損した場合に備え、検証済みの正確な構成を保存します。
• Duplicator Proはワークフロー全体を処理するため、両方の環境においてサイト全体のバックアップ（ファイルとデータベース）を簡単に取得できます。
• サーバー障害に備えて、必ずローカルにコピーを保存し、もう1つのコピーをクラウドストレージに保存してください。
• プッシュが正常に完了した直後にステージングのバックアップを削除しないでください。後日、隠れたバグが見つかる可能性があるため、1か月間は保管しておいてください。

目次

ステージングサイトをバックアップする理由は？

多くの人は、本番環境にデプロイする前にサイトをバックアップし、それで完了だと考えています。そうすることで本番環境は守られますが、重要なもの――つまり自分の作業内容――が露出したままになってしまいます。

ステージングサイトは、本番環境の単なるコピーではありません。本番環境へデプロイする準備が整った時点で、そこには検証済みの正確な構成が反映されています。プラグインの更新、テーマの変更、新機能など、すべてがテストされ、相互に正常に動作することが確認されています。

これが基準状態です。プッシュが失敗し、ステージング環境も巻き添えになってダウンしてしまった場合、その基準状態は失われてしまいます。本番環境をバックアップから復元しても、ステージング環境は復元されません。

だからこそ、プッシュする前には必ず2つのバックアップが必要なのです。

最初のバックアップはステージングサイトのものです。これは、先ほど行ったテスト作業を保護するものです。ステージングサイトが破損した場合でも、検証済みの状態に復元できるため、一からやり直すことなく、何が問題だったのかを特定することができます。

2つ目のバックアップは本番環境のものです。これは稼働中のサイトを保護するものです。デプロイ後に本番環境で何らかの問題が発生した場合、最後に正常だった状態までロールバックすることができます。

これらはそれぞれ異なる復旧シナリオに対応しています。どちらも必要です。

始める前に必要なもの

バックアップを実行する前に、以下の準備を整えておいてください。あらかじめこれらを整えておけば、処理の途中で中断されることはありません。

• Duplicator 本番サイトだけでなく、ステージングサイトにもインストールする必要があります。
• ステージングサイトの wp-admin への管理者アクセス：本番サイトではなく、ステージング環境に直接ログインする必要があります。
• サイト全体のバックアップに必要なサーバーのディスク容量：空き容量がわからない場合は、作業を開始する前にホスティングのコントロールパネルで確認してください。
• Duplicator Proで設定するクラウドストレージ先（任意ですが、強く推奨されます）：Dropbox、Google Drive、Amazon S3、およびDuplicator Cloudがすべてサポートされています。まだ設定していない場合は、当面はローカルストレージでも問題ありませんが、次回のプッシュを行う前にクラウドストレージを追加するようにしてください。
• ステージングサイトのURL：サブドメイン（staging.yoursite.com）であれ、サブディレクトリ（yoursite.com/staging）であれ、作業を始める前にその場所を確認しておきましょう。

ウェブサイトのステージングサイトのバックアップ方法

Duplicator Pro を使用してステージングサイトのバックアップを行うには、約 10 分かかります。ステージング環境がサブドメイン、サブフォルダ、または別のサーバーのいずれに存在する場合でも、手順は同じです。

具体的な手順は以下の通りです：

• 手順 1：ステージングサイトに Duplicator をインストールして有効化する：プラグインをステージング環境に直接インストールします。Duplicator Pro のワンクリック・ステージング機能を使用してサイトを作成した場合は、すでにインストール済みですので、この手順はスキップできます。
• ステップ 2：ステージング環境のサイト全体バックアップを作成する：「サイト全体バックアップ」プリセットを使用して、ファイルとデータベースを1つのパッケージにまとめて保存します。実行する前に、わかりやすい名前を付け、少なくとも1つの保存先を選択してください。
• ステップ 3：バックアップのローカルコピーをダウンロードする：アーカイブファイルと installer.php を、コンピューター上の適切な名前のフォルダにダウンロードします。これにより、サーバーが完全にダウンした場合でも復元可能なコピーを確保できます。
• ステップ4：本番サイトもバックアップする：本番サイトでも同じ手順を繰り返します。デプロイを行う前に、両方のバックアップが必要です。

ステップ1：ステージングサイトにDuplicatorをインストールして有効化する

ステージングサイトのバックアップを行うには、まずそのサイトにバックアップツールをインストールする必要があります。私がお勧めするのは「Duplicator」というツールです。

Duplicatorは、150万人のWordPressプロフェッショナルに利用されている、WordPress用のバックアップ、移行、ステージングプラグインです。このプラグインは、サイトの完全なスナップショットを作成し、それを単一のパッケージとしてローカルに保存したり、クラウドに送信したりすることができます。

特にバックアップのステージングに適している理由は、ワークフロー全体を一か所で処理できる点にあります。

Duplicatorを使えば、ステージング環境のバックアップ、本番環境のバックアップ、変更内容の反映、そして何か問題が発生した際の復元を行うことができます。各ステップごとに個別のプラグインを用意する必要はありません。

Duplicator Proのワンクリックステージング機能を使用してステージングサイトを作成した場合は、準備は完了しています。Duplicator Proはステージングサイトに自動的にインストールされ、有効になっています。手順2に進んでください。

ステージングサイトが別の方法（ホスティングプロバイダのステージングツール、手動でのサブドメイン設定、または他のプラグインなど）で作成されている場合は、Duplicator Proをステージングサイトに直接インストールする必要があります。

ステージングサイトの wp-admin にアクセスし、「プラグイン」＞「新規追加」 に移動します。 「Duplicator」を検索して インストールし、「有効化」をクリックします。

Duplicatorの無料版でも、基本的なステージングサイトのバックアップは可能です。ドラッグ＆ドロップによる移行、ワンクリック復元、クラウドストレージ、その他の高度なツールといった機能が必要な場合は、Duplicator Proへのアップグレードをお勧めします。

ライセンスキーは、duplicator.com のアカウントダッシュボードに表示されています。それをコピーし、設定画面のライセンス欄に貼り付けてください。

Proライセンスは複数のサイトで利用可能ですので、ステージング環境で有効化しても、同じプランの範囲内となります。追加での購入は必要ありません。

ライセンスキーの横に緑色のチェックマークが表示されているはずです。確認できたら、バックアップの作成準備は完了です。

ステップ 2：ステージング環境のサイト全体バックアップを作成する

これは、テスト作業を保護するためのバックアップです。万が一の事態に備え、ステージング環境の変更を本番サイトに反映させる前に、必ず実行してください。

ステージングサイトの wp-admin にアクセスし、「Duplicator Pro」»「バックアップ」に移動して、「新規追加」ボタンをクリックしてください。

後でわかるような名前をつけてください。

次に、バックアップの保存先を選択してください。以下の2つの選択肢があります：

• ローカルストレージはバックアップをサーバーに保存します。処理は高速ですが、サーバーがダウンすると、バックアップも失われてしまいます。
• クラウドストレージは、バックアップデータをDropbox、Google Drive、Amazon S3、またはDuplicator Cloudに送信します。サーバーにまったく接続できない場合でも、データにアクセスできます。

どれを選べばいいか迷っていますか？ローカルバックアップとクラウドバックアップの詳しい比較記事をご覧ください！

設定済みのクラウド保存先がある場合は、少なくとも1つ選択してください。設定されていない場合は、当面はローカルストレージでも問題ありませんが、次回のプッシュ前にクラウドストレージを設定するよう、メモしておいてください。

「バックアップ」設定で、「サイト全体」プリセットを選択してください。これにより、ファイルとデータベースが1つのパッケージにまとめて保存されます。

どちらか一方しか対象としないカスタムプリセットは選択しないでください。ステージング環境で完全な復元が必要になった場合、部分的なバックアップでは役に立ちません。

次のページには、ステージングサイトのスキャン結果がすべて表示されます。注意事項を確認し、「バックアップを作成」をクリックしてください。

バックアップを実行してください。完了すると、「バックアップ」ページに新しいファイルが表示されます。

ステップ3：バックアップのコピーをダウンロードする

クラウドストレージは、サーバーがダウンした場合にも対応します。バックアップをクラウドに保存しておけば、ローカルでの障害からデータを保護できます。

ローカルバックアップについては、ダウンロードすることをお勧めします。所要時間は2分ほどですが、万が一他のデータにアクセスできなくなった時、このバックアップがあれば本当に助かります。

先ほど作成したバックアップを探してください。両方のファイルをダウンロードしてください。

2つのファイルがダウンロードされます：アーカイブファイル（.daf または .zip）とinstaller.php です。両者の違いは以下の通りです：

• アーカイブファイルにはサイトのデータが保存されています
• installer.php はデータを展開し、サイトの復元や移行を行います

両方のファイルを、パソコン内の名前がはっきりわかるフォルダにまとめて保管してください。

一部のブラウザでは、ダウンロード時にファイル名に変更が加えられ、番号が追加されたり拡張子が変更されたりすることがあります。installer.php を保存する前に、ダウンロードされたファイル名が正確に一致しているか確認してください。ファイル名を変更すると、復元プロセスが正常に実行できなくなる可能性があります。

ステップ4：本番サイトのバックアップも行う

ステージングサイトは保護されています。本番サイトに何かをデプロイする前に、同じ手順を実行してください。

本番サイトの wp-admin にアクセスし、同じ手順を実行してください。「Duplicator Pro」→「バックアップ」→「新規追加」の順に進み、「Full Site」プリセットを選択して、わかりやすい名前を付けてください。

バックアップを実行し、完了するまで待ってから、ローカルにコピーをダウンロードしてください。

完了すると、ローカルに2つのバックアップがダウンロードされているはずです。これが、プッシュを行う前の最適な状態です。

2つの環境のバックアップが完了し、2つの復旧オプションも準備万端です。これで、エラーを心配することなく変更を反映できます！

プッシュが成功した後、ステージングのバックアップをどうするか

プッシュは正常に完了し、本番環境の状況も良好です。すべてを終了する前に、ステージング環境のバックアップについて、もう一つ決定すべき事項があります。

まだ削除しないでください。

プッシュ操作による本番環境の問題は、必ずしもすぐに表面化するとは限りません。キャッシュ層によって、破損したテンプレートが何日も隠されたままになることがあります。また、チェックアウトフローにおけるエッジケースは、実際のトラフィックが流入するまでトリガーされない可能性があります。

プッシュが正常に完了した後、ステージングのバックアップは少なくとも30日間保持し、その後削除を検討してください。

まだクラウドストレージに保存していない場合は、今すぐ保存してください。パソコンに保存したローカルコピーも便利ですが、特定の1台のマシンに縛られてしまいます。

クラウドストレージを使えば、後で参照したり復元したりする必要がある場合でも、どこからでもアクセスできます。私はいつもDuplicator Cloudを利用しています。Duplicatorとの連携がスムーズで、WordPressのバックアップ保存のために特別に設計されているからです。

次の変更を実施する準備が整ったら、ステージング環境は本番環境から再同期されることになるでしょう。その時点で、以前のステージング環境のバックアップはそれほど重要ではなくなります。

ただし、新しいステージング環境がセットアップされ、正常に動作することが確認されるまでは、そのままにしておいてください。新しい環境が整う前に、安全策を削除してしまってはいけません。

よくある質問 (FAQ)

あなたのステージング作業は、守る価値があります

これで、ステージング環境と本番サイトの完全なバックアップが、ローカルおよび少なくとも1つのクラウド先へ保存されました。これが、デプロイを行う前に整えておくべき状態です。2つの環境がカバーされ、万が一のトラブルに備えて2つの復旧経路が確保されています。

今後は、大きなプッシュだけでなく、すべてのプッシュの前に、これをルーチンに組み込んでください。小さな変更でもシステムを壊すことがありますし、リスクが低いと感じるプッシュほど、実行前にバックアップを取ろうと思わないものなのです。

プッシュに失敗すると、設定やテストに何時間もかかったステージング環境が消えてしまう可能性があります。バックアップがない場合、唯一の選択肢は、一から環境を再構築し、プラグインを再インストールし、すべてを再テストすることになり、正常な状態がどうだったかを覚えていることを祈るしかありません。

少なくとも2か所に保存された、日付が記録され、整合性が確認されたバックアップがあれば、そのような事態は決して起こりません。

150万人以上のWordPress専門家が、サイトの移行、更新、公開のたびにDuplicator Proを使用してサイトを保護しています。ワンクリックでのステージング、スケジュールされたバックアップ、10種類以上のクラウドストレージへの対応など、このチュートリアルで解説するワークフローに最適に設計されています。

このチュートリアルがお役に立ったなら、以下のガイドもブックマークしておく価値があります。

• WordPressステージングサイトの作り方（安全なテストのために）
• WordPressをステージングサイトに変換する方法
• ステージングサイトは必要ですか？
• クラウドバックアップとローカルバックアップ：どちらがWordPressサイトをしっかり保護するのか？
• WordPressサイトの移行方法（2026年版初心者ガイド）