破損したウェブサイトを復旧するために、クラウド上のWordPressバックアップを復元する方法
ジョン・ターナー
ジョン・ターナー
火曜日の午後11時、サーバーがダウンしてしまった。あるいは、プラグインのアップデートに不具合があり、データベースがすべて消去されてしまった。あるいは、ホスティングサービスで致命的な障害が発生し、サポートへの問い合わせに対して「現在調査中です」と返ってきた。
サイトが消えてしまったと気づいた瞬間、重要なのはただ一つ――取り戻せるかどうか、ということです。
多くのWordPressサイトの運営者は、その問いに対する答えを、最悪の形で知ることになる。
彼らはどこかのクラウドストレージのフォルダにバックアップを保管している。しかし、「バックアップが存在する」ことと「サイトが復元される」ことの間には、多くの環境では決して対処されていないギャップがある。バックアップはそこにある。だが、元に戻る道筋はない。
この記事では、クラウド上のWordPressバックアップを復元する方法と、サーバーが完全にオフラインになって通常の復元ツールが動作しない場合の対処法について解説します。
以下はその要点である:
- WordPressにアクセスできない場合でも、クラウドバックアップから復元できれば、データは保護されます
- WordPressの完全なバックアップには、サイトファイルとデータベースの両方が必要です。どちらか一方だけでは、正常に動作するサイトを復元することはできません。
- 標準のバックアッププラグインは、動作させるために稼働中のWordPress環境が必要であるため、サーバーがダウンしている場合は機能しません
- Duplicator Cloudのリモート復元機能を使えば、FTP/SFTPの認証情報だけでクラウドダッシュボードからサイト全体を復元でき、稼働中のサーバーは不要です
- 実際の緊急事態が発生し、その場で対応策を考えざるを得なくなる前に、必ずステージング環境で復旧手順をテストしておきましょう
- バックアップ用の認証情報を、サーバー外からアクセスできる場所に保管してください。サーバーが利用できなくなった場合、保存したデータにアクセスするためにそれらが必要になります。
目次
なぜクラウド型WordPressバックアップが必要なのでしょうか?
多くのWordPressサイトの管理者は、バックアップがあれば安全だと考えています。しかし、それは半分に過ぎません。問題が発生した際に、そのバックアップを実際に活用できるかどうかは、バックアップがどこに保存されているかによって決まります。
ローカルバックアップは、サーバーが故障するまでは便利に思えます。しかし、サーバーがダウンすれば、そこに保存されていたデータもすべて失われてしまいます。頼りにしていたバックアップは、まさに今、問題の原因となったそのマシン上に残されているのです。
これは単なる仮定上のリスクではありません。2021年3月、ストラスブールにあるOVHのデータセンターで発生した火災により、サーバーが焼失し、隣接する建物にも被害が出ました。同データセンターでホスティングされていたサイトはすべて消失しました。
復旧できたのは、オフサイトバックアップを持っていたシステムだけだった。ローカルまたはサーバー内のストレージしか持っていなかったシステムは、復元できるデータが何もなかった。
まさにこの理由から、「3-2-1のルール」が存在します。つまり、データを3部作成し、2種類の異なるメディアに保存し、そのうち1部は別の場所に保管するということです。
クラウドストレージとは、まさにその「オフサイトのコピー」のことです。ローカルのデータがすべて失われても、唯一残されるコピーなのです。
クラウドWordPressバックアップの復元方法
クラウドバックアップからWordPressサイトを復元するにはいくつかの方法がありますが、適切な方法は、サーバーやWordPressダッシュボードにまだアクセスできるかどうかによって異なります。
ここでは、2つの復元方法について説明します:
- 方法 1:Duplicator Cloud Recovery:プラグインまたはオフサイトのクラウドダッシュボードからワンクリックでバックアップを復元(サーバーがダウンしている場合)
- 方法 2: FTP + phpMyAdmin:ダッシュボードが利用できない場合でも、FTP やデータベース管理ツールを通じてサーバーにアクセスできる場合の手動での代替手段
方法 1:バックアッププラグインを使用してクラウドバックアップを復元する
ここ数年、数多くのWordPressバックアッププラグインを試してきましたが、特にクラウドバックアップの復元に関しては、いつもDuplicator Proに戻ってきてしまいます。

多くのプラグインでは、まずバックアップをダウンロードしてから、自分で復元の手順を考えなければなりません。Duplicatorなら、そのプロセス全体をWordPress内で完結させることができます。
Duplicatorを以下のいずれかのクラウドストレージに接続します:
- デュプリケーター・クラウド
- グーグルドライブ
- ドロップボックス
- マイクロソフトOneDrive
- アマゾンS3
- わさび
- グーグル・クラウド
- ドリームオブジェクト
- ウルトル
- DigitalOceanスペース
- クラウドフレアR2
- バックブレイズB2
クラウドバックアップを作成すると、それらはプラグインのダッシュボードに直接表示され、復元ウィザードが以降のすべての処理を代行します。業務に不可欠なサイトを管理しているにもかかわらず、まだこの設定を行っていない場合は、いざという時になる前に設定しておくことをお勧めします。
軽微なエラーに対するDuplicatorバックアップの復元
Duplicatorの復元プロセスは、phpMyAdminやFTPを手動で操作したくないサイト運営者のために設計されています。WordPressのダッシュボードにアクセスできる状態であれば、これがサイトを正常な状態に戻す最も手っ取り早い方法です。
WordPressのダッシュボードにログインし、Duplicator Proプラグインを開きます。「バックアップ」に移動し、復元したいバックアップを探します。「復元」ボタンをクリックします。

バックアップがクラウドに保存されている場合、Duplicatorが自動的にダウンロードします。

その後、Duplicatorは復元ウィザードを起動し、手順を一つひとつ案内します。

ファイルの抽出、データベースのインポート、wp-config.phpの更新といった面倒な作業は、このツールが自動的に処理してくれます。これらの作業を手動で行う必要はありません。
復元が完了したら、キャッシュを消去し、サイトを確認して、すべてが正常に戻っていることを確認してください。
重大なエラーが発生した場合のDuplicatorクラウドバックアップの復元
これは、ほとんどのバックアッププラグインが提供していない方法です。サーバーがオフラインになると、WordPressのダッシュボードも利用できなくなり、プラグインベースの復元ツールはすべて役に立たなくなってしまいます。
Duplicator Cloudはその問題を解決します。
バックアップをDuplicatorの組み込みクラウドストレージに送信すると、データはオフサイトのダッシュボードに保存されます。これにより、ローカルサーバーのエラーの影響を受けず、これらのバックアップを使用してリモートからサイトを復元することができます。

復元プロセス全体は、Duplicator Cloudのダッシュボードから実行されます。サーバーがオンラインである必要はなく、WordPressが稼働している必要もありません。
世界中のどこからでも、どのデバイスからでも、どのようなインターネット接続環境でも、サイト全体の復旧を開始できます。
この設定は一度だけ行えば完了します。Duplicator Cloudのダッシュボードで、FTP/SFTPの認証情報(ホスト名、ユーザー名、パスワード、およびサイトファイルのパス)を入力し、サイトの復元コネクタを設定してください。

接続が正常に機能するか確認してください。コネクタの設定が完了すれば、今後の復元作業は数回のクリックで完了します。
災害が発生した場合は、Duplicator Cloudダッシュボードでサイトのストレージを開き、最新の正常なバックアップを見つけて、「フルバックアップを復元」をクリックしてください。

Duplicatorはインストーラースクリプトとバックアップファイルを自動的にダウンロードし、復元ウィザードを起動します。利用規約に同意し、処理が完了するまで待ち、正常に動作しているサイトに再度ログインしてください。

完全な復元だけに限定されるわけではありません。問題が特定の部分に限られている場合、Duplicator Cloudでは部分的な復元にも対応しています。サイトの他の部分には影響を与えずに、データベースのみ、メディアライブラリのみ、あるいは特定のファイルだけをロールバックすることができます。

ある1つの不適切な変更が問題の原因であり、完全に再構築すると最近のコンテンツが失われてしまうような場合に、これは役に立つと思います。
方法 2:クラウド上の WordPress バックアップを手動で復元する
WordPressのダッシュボードにアクセスできないものの、サーバーには接続できる場合は、FTPを使った手動での復元が代替手段となります。手順は多くなりますが、プラグインベースの復元ツールが動作しない場合でも確実に機能します。
まず、クラウドストレージからバックアップファイルをローカルマシンにダウンロードしてください。サーバー上の操作を行う前に、ファイルアーカイブとデータベースのエクスポートデータの両方が必要になります。
FTPクライアント(私はFileZillaを使っています)を開き、サーバーに接続します。public_htmlフォルダから古いWordPressファイルを削除し、バックアップファイルをアップロードします。ホスティングサービスによっては、ルートディレクトリは通常public_htmlフォルダ、あるいはその中のサブディレクトリになります。

ファイルの準備ができたら、ホスティングのコントロールパネルからphpMyAdminを開きます。適切なデータベースを選択し、インポート機能を使って.sqlファイルをアップロードしてください。

データベースの規模が大きい場合、この処理には数分かかることがあります。処理が完了するまでお待ちください。
インポートが完了したら、wp-config.php を開き、DB_NAME、DB_USER、DB_PASSWORD、DB_HOST の値が現在のデータベースの認証情報と一致していることを確認してください。移行やサーバーの移動の際にこれらの設定が変更されていた場合、復元されたサイトが接続に失敗し、フロントエンドにデータベースエラーが表示される原因となります。

サイトが復旧したら、「設定」»「パーマリンク」に移動し、「変更を保存」をクリックしてパーマリンクを更新してください。その後、サーバー側のキャッシュをすべてクリアしてください。

バックアップがDuplicator Proで作成されている場合、この手順はかなり簡単になります。WordPressのファイルそのものをアップロードしたり、別の.sqlファイルをインポートしたりする代わりに、「クラウドから復元」をクリックするだけです。
確実なWordPressクラウドバックアップと復元のためのアドバイス
クラウドバックアップを導入することは、あくまで出発点に過ぎません。こうした取り組みこそが、いざという時に機能するバックアップ戦略と、実際に必要になるまでは問題ないように見えるだけの戦略とを分けるのです。
バックアップを自動化して、バックアップがないという事態を未然に防ぎましょう
手動でのバックアップは省略されがちですが、自動スケジュールによるバックアップはそうなりません。
Duplicator Pro を使えば、バックアップのスケジュール、保存先、および保存期間のルールを1か所で設定できるため、あとは何も気にせず自動的に処理が進みます。
Duplicator Proでは、「バックアップのスケジュール」ページを使用して、時間指定のバックアップを作成し、Duplicator Cloudやその他の接続されたストレージ先に直接送信できます。

Duplicatorは、1時間ごと、1日ごと、1週間ごと、1ヶ月ごとの自動バックアップに対応しています。
少なくとも毎日自動バックアップを設定してください。アクセス数の多いサイトやWooCommerceを利用しているサイトでは、より頻繁にバックアップを行う必要があります。バックアップスケジュールでカバーされていない1時間ごとに、その時間帯に問題が発生した場合、データが失われるリスクが生じます。

バックアップには、必ずファイルとデータベースの両方を含めてください。不完全なバックアップでは復旧も不完全になり、実際に復元が必要になるまで何が欠けているのか分かりません。
Duplicator では、クラウドに保存するバックアップの数を設定できるため、手動で削除しなくても古いバックアップは自動的に削除されます。毎日のフルバックアップを実行していると、ストレージは多くの人が予想するよりも早く容量がいっぱいになってしまいます。

特にWooCommerceサイトの場合、サイト全体のバックアップの間に、データベースのみのバックアップをより頻繁に実行することを検討してください。注文情報や顧客データは絶えず変化しています。数時間おきに実行する軽量なデータベースバックアップであれば、毎回サイト全体のバックアップを行う際の負荷をかけずに、その変化を確実に反映させることができます。
実際に必要になる前に、復元テストを行ってください
テストしたことのないバックアップは、単なる「仮定」に過ぎません。ファイルが完全であること、データベースが問題なくエクスポートされていること、認証情報がまだ有効であること、そして復元ウィザードから質問された際にどう対応すべきかを知っていること――これらすべてを信頼していることになります。それはあまりにも多くのことを前提としているのです。
少なくとも四半期に1回は、ステージング環境で復元テストを実行してください。バックアップのダウンロードまたは検索、復元の開始、そしてサイトが正常に復旧したことを確認するという一連のプロセスをすべて実行してください。これにより、前回の確認以降に設定に何らかの変更が生じていないかをすぐに把握できます。
Duplicatorのステージング機能を使えば、テスト用にサイトのコピーを作成できます。

そこで復元を実行してください。サイトを少し確認してみてください。データベースに問題がなく、ファイルが所定の場所に存在することを確認してください。
複数の保存場所を使用する
単一のクラウドストレージに依存していると、たった1つのアカウントが侵害されただけで、すべてを失うことになりかねません。
ストレージプロバイダーがダウンする。アカウントがロックされる。請求上の問題でアクセスが遮断される。こうした事態が、不運なタイミングで発生すれば、万全なバックアップも利用できなくなってしまいます。
Duplicator Proは、複数のストレージプロバイダーへの同時送信に対応しています。Duplicator Cloudに加え、Amazon S3、Google Drive、Backblaze B2などの別の保存先を接続し、両方に送信されるよう自動バックアップを設定できます。

見落とされがちな実用的なポイントとして、バックアップ用ストレージの認証情報は、サーバー外からアクセスできる場所に保管しておくことです。パスワードマネージャーやセキュリティ対策が施された文書など、別のマシンからでもアクセスできる場所が適しています。
サーバーが利用できなくなった場合、バックアップにアクセスするにはその認証情報が必要になります。故障したマシンだけに保存しておかないでください。
バックアップの保護
バックアップファイルには、ユーザーデータ、データベースの認証情報、APIキー、設定ファイルなど、サイト上のあらゆる情報が含まれています。バックアップファイルは本番サイトと同等の保護を受けるべきですが、実際には、多くのバックアップ環境においてセキュリティ対策は後回しにされがちです。
バックアップアーカイブを暗号化してください。Duplicator Proはパスワード保護されたバックアップに対応しており、設定には約30秒しかかかりません。

バックアップワークフローに接続されているすべてのFTP/SFTPアカウントおよびクラウドストレージ先には、強固で固有の認証情報を使用してください。ホスティングアカウントやストレージプロバイダー間でパスワードを再利用すると、たった一度のセキュリティ侵害で全てのデータが流出する危険性があります。
Duplicator Cloudのダッシュボードおよび接続されたストレージアカウントへのアクセス権限を持つユーザーを定期的に確認してください。
チームメンバーは入れ替わります。代理店は契約を失うこともあります。半年前には理にかなっていたアクセス方法が、今では意味をなさなくなっているかもしれません。
四半期ごとの点検は数分で済みますが、問題が深刻化する前に未解決の課題を解消することができます。
よくある質問 (FAQ)
バックアップから復元した後、WordPressサイトが表示されない場合はどうすればよいですか?
まず wp-config.php を確認し、データベースの認証情報が復元先の環境と一致しているか確認してください。認証情報が正しい場合は、ファイルの権限を確認し、パーマリンクをリセットし、FTP 経由でプラグインを無効にして、競合の可能性を排除してください。
WordPressサイトをバックアップから復元するには、どれくらい時間がかかりますか?
ほとんどの中小規模のWordPressサイトでは、完全な復元が数分で完了します。メディアライブラリが膨大だったり、データベースのデータ量が多かったりする大規模なサイトの場合、サーバーの速度や接続環境にもよりますが、20分から40分程度かかることがあります。Duplicatorのような自動ウィザードを使った復元は、バックアップが作成されればプロセスがサーバー側で実行されるため、手動でのFTPやphpMyAdminを使った復元よりも常に高速です。
バックアップがない場合、WordPressサイトを以前の日付の状態に復元するにはどうすればよいですか?
まず、ホスティングのコントロールパネルを確認してください。ホスティング業者によっては、ダッシュボードにはすぐには表示されないものの、数日間サーバーのスナップショットを保持している場合があります。それ以外の手立ては限られています。「ウェイバックマシン」を使えば、場合によっては表示されているページの内容を復元できることもありますが、データベースのレコードやメディアファイル、設定情報は復元できません。バックアップなしで復元を行うのは「被害の最小化」であり、「完全な復旧」ではありません。また、復元できたとしても、不完全なものになるでしょう。
プラグインを使わずにWordPressサイトのバックアップを取るにはどうすればいいですか?
FTP経由でサーバーに接続し、WordPressのディレクトリ全体をダウンロードしてください。その後、ホスティングのコントロールパネルからphpMyAdminにログインし、データベースを.sqlファイルとしてエクスポートしてください。
これら2つの手順を組み合わせることで完全なバックアップが作成できますが、このプロセスは完全に手動で行われるため、自動化機能や復元ウィザードなどの支援はありません。手動バックアップは、大規模な更新を行う前の「その時点のスナップショット」としては有効ですが、定期的に変更が加えられるサイトにとっては実用的な方法とは言えません。
複数のクラウドストレージにバックアップすべきでしょうか?
はい、常にそうすべきです。最低でも2つの保存先を設定することをお勧めします。単一のストレージプロバイダーの障害、アカウントへのアクセス問題、あるいは請求処理の中断などが発生すると、最悪のタイミングでバックアップに一時的あるいは恒久的にアクセスできなくなる恐れがあります。Duplicator Proを使えば、複数の保存先を簡単に設定し、両方に自動バックアップを実行するようにスケジュールできます。
管理画面にアクセスできない状態で、WordPressを復元することはできますか?
はい、Duplicator Cloudのリモート復元機能を使えば可能です。このプロセスはすべて、FTP/SFTPの認証情報を使用してDuplicator Cloudのダッシュボードから実行されます。WordPressが稼働している必要はありません。リカバリコネクタを一度設定すれば、ワンクリックで任意のバックアップを復元できます。
あなたのサイトはいずれダウンするでしょう。その後に何が起こるかは、あなた次第です。
どのサイト運営者も、遅かれ早かれ、自分のバックアップ戦略が実際に機能しているかどうかを確かめることになる。
すでにテスト復元を実行し、クラウドストレージを設定し、リカバリコネクタを構成しておいた人は、いざその時が来ても慌てません。ただ、その手順を実行するだけです。
Duplicator なら、スケジュールされたバックアップ、複数のクラウドストレージへの保存、復元テスト用のステージング環境、そしてサーバーが完全にオフラインの状態でも機能する Duplicator Cloud によるリモート災害復旧など、必要な機能をすべて一か所で利用できます。
WordPressがダウンした瞬間、ほとんどのバックアッププラグインは役に立たなくなります。しかし、Duplicator Cloudは違います。
その最後の部分は、明確な解決策が見当たらないサーバーエラーに直面するまで、多くの人が思っている以上に重要なのです。
「Duplicator Pro」と「Duplicator Cloud」ストレージを導入し、リカバリコネクタを設定して、テスト復元を1回実行してください。これにより、バックアップが正常に完了しているか、また復元にかかる時間がどの程度かを確認できます。さらに、いざという事態でプレッシャーの中対応を迫られる前に、手順を文書化した体制を整えておくことができます。
このサイトをご覧になっているなら、以下の関連リソースも気に入っていただけると思います: