phpMyAdminが使えないWordPressのバックアップ方法｜Adminerを使った実際の対応事例

先日、XML-RPCの無効化対応について記事にまとめました。外部からWordPressを遠隔操作できる機能が攻撃に悪用されやすいため、サイトの管理会社からの指摘を受けて停止した、という作業です。この作業には前段があります。サイトの構成ファイルに手を入れる以上、作業前のバックアップが必須ですが、今回の案件ではphpMyAdminにもサーバーパネルにもログインできず、手元にあるのはFTPの接続情報だけでした。

結論から言うと、この条件でもデータベースのバックアップは取得できます。Adminerという1ファイルで動くデータベース管理ツールをFTPでアップロードし、ブラウザからエクスポートする方法です。ただし今回は、サーバーの容量不足が原因の「セッションの期限切れ」エラーと、対処コードの追記位置が原因の500エラーという2つのつまずきがありました。本記事では、手順とあわせて、このエラーの原因と解決までを実際の流れで解説します。

前提となる状況

今回の案件の条件を整理すると、次の通りです。

• サーバーパネル（コントロールパネル）にログインできない
• phpMyAdminにもログインできない
• FTPの接続情報はある
• サーバーのディスク容量が逼迫しており、サーバー内に大きなファイルを作る余裕がない（バックアッププラグインが使えない）

長く運用されてきたサイトの保守を途中から引き継ぐと、こういう状況は珍しくありません。サーバー契約時の書類が見つからない、前の担当者と連絡が取れない、サーバーは別の会社が管理していてログイン情報を入手できない、といった事情で、FTPの情報だけが引き継がれているケースです。同じ環境で起きやすいトラブルはWordPressのプラグインが更新できない原因はファイル所有者のズレ｜FTPでの解決手順でも扱っています。

FTPが使えればファイル一式のダウンロードはできますが、WordPressのバックアップとしてはそれだけでは不完全です。投稿・固定ページ・各種設定などサイトの中身はすべてデータベースにあり、データベースはFTPでは取得できないためです。主なバックアップ手段と必要なアクセス権を整理すると、次のようになります。

この条件で使えるのが、Adminerです。

Adminerとは

Adminer（アドミナー）は、phpMyAdminと同等のデータベース操作ができるオープンソースのツールです。最大の特徴は、たった1つのPHPファイルで動作すること。サーバーへのインストール作業は不要で、FTPでファイルを1つアップロードするだけで使えます。公式サイトから最新版をダウンロードできます。

もう1つ、今回の状況で重要だった特性があります。Adminerのエクスポートは、サーバー内に一時ファイルを作らず、ブラウザへの直接ダウンロードとして実行されます。バックアッププラグインの多くはサーバー内に一度バックアップファイルを生成するため、容量が逼迫したサーバーでは実行自体が失敗しますが、Adminerならその心配がありません。

手順1：wp-config.phpから接続情報を控える

データベースへのログインには、データベース名・ユーザー名・パスワード・ホスト名の4つが必要です。これらはすべて、WordPressのルート階層（wp-adminなどと同じ階層）にあるwp-config.phpに書かれています。FTPでwp-config.phpをダウンロードし、テキストエディタで開いて次の4つの値を控えます。

define( 'DB_NAME', 'データベース名' );
define( 'DB_USER', 'ユーザー名' );
define( 'DB_PASSWORD', 'パスワード' );
define( 'DB_HOST', 'localhost' );

DB_HOSTはlocalhostの場合もあれば、サーバー会社指定のホスト名が入っている場合もあります。書かれている値をそのまま使います。

手順2：Adminerをリネームしてアップロードする

公式サイトのダウンロード一覧から、「Adminer for MySQL」のPHPファイルを1つダウンロードします。リンクは多言語対応の通常版と、軽量な「英語のみ」版の2種類がありますが、機能は同じなのでどちらでも構いません。通常版であれば、設置後の画面で表示言語を日本語に切り替えられます。

次に、ファイル名を必ず推測されにくいランダムな名前に変更してください。たとえば adminer.php を db-backup-a1b2c3.php のような名前にします。adminer.phpのままアップロードすると、第三者にURLを推測され、データベースのログイン画面を外部に晒すことになります。ファイル名の変更は、一時的な設置における最低限の防御です。

リネームしたファイルを、FTPでWordPressのルート階層（wp-config.phpと同じ階層）にアップロードします。ブラウザで「https://サイトのドメイン/変更後のファイル名.php」にアクセスすると、Adminerのログイン画面が表示されます。

ここで手順1で控えた4つの値を入力します。「サーバー」欄にはDB_HOSTの値、それ以外はそれぞれ対応する値です。

……となるはずでしたが、今回はここで2つのエラーに遭遇しました。

つまずき1：ログインすると「セッションの期限切れ」になる

認証情報は正しいのに、ログインした瞬間に「セッションの期限切れ。ログインし直してください。」と表示され、ログイン画面に戻されてしまう症状が出ました。

原因はサーバーのディスク容量不足でした。PHPはログイン状態を保持するために、セッションファイルという小さなファイルをサーバー内に書き込みます。ディスクに空きがないとこの書き込みが失敗し、ログインした直後にセッションが消えてしまうため、「期限切れ」というエラーになります。認証は通っているのにログインできない、という一見不可解な症状の裏側はこれでした。

対処は、セッションファイルの保存先を自分で用意した場所に変えることです。まず、FTPで、先ほどアップロードしたdb-backup-a1b2c3.phpと同じ階層にフォルダを1つ作ります。こちらも名前はランダムにします（例：sess_a1b2c3）。パーミッションは755です。次に、Adminerのファイルに次の1行を追記します。

session_save_path(dirname(__FILE__) . '/sess_a1b2c3');

コード内の sess_a1b2c3 の部分は、先ほど作成したフォルダ名に合わせてください。セッションファイル自体は数百バイト程度なので、大きなファイルは置けない容量でも書き込める可能性が高い、という考え方です。ただし、この行を「どこに」書くかが次のつまずきにつながりました。

つまずき2：追記したら500エラーになる

session_save_pathの行をPHPの開始タグの直後（1行目の直後）に追記してアップロードし直したところ、今度はページ全体が500エラー（Internal Server Error）になりました。

原因はPHPの仕様です。Adminerは内部で名前空間の宣言（namespace Adminer;）を使っており、PHPの仕様として、この宣言は宣言文（declare）とコメントを除いてファイルの最初に書かれていなければなりません。開始タグの直後に追記すると、session_save_pathの行がnamespace宣言より前に来てしまい、PHPが起動時点でエラーを出していたのです。

正しい追記位置は、namespace宣言の直後です。Adminerの配布ファイルは圧縮されていて先頭部分が読みにくいのですが、「Adminer;const」と書かれている行を探し、Adminer; と const の間に挿入します。修正後の先頭部分は次のようになります。

*/namespace
Adminer;
session_save_path(dirname(__FILE__) . '/sess_a1b2c3');
const
VERSION="5.5.1";

なお、namespace宣言が「namespace」と「Adminer;」で行が分かれて見えるのは、配布ファイルが圧縮版で機械的に改行が入っているためで、異常ではありません。

修正して上書きアップロードすると、今度こそログイン画面が表示され、ログインも通りました。

手順3：エクスポートを実行する

ログイン後、左メニューの「エクスポート」を開きます。設定は次の通りです。

• 出力：gzip
• 形式：SQL
• テーブル：全選択のまま

「エクスポート」ボタンを押すと、ブラウザのダウンロードとして .sql.gz ファイルが手元に保存されます。サーバー内には一切ファイルを作らないため、容量不足のサーバーでも完結します。ダウンロード後は、ファイルサイズが0バイトになっていないか、展開してSQL文が含まれているかを軽く確認しておくと安心です。

作業後は必ずAdminerを削除する

エクスポートが完了したら、その場で必ず、アップロードしたAdminer本体（この記事の例ではdb-backup-a1b2c3.php）と、作成したセッション用フォルダ（sess_a1b2c3）の両方をFTPで削除してください。

Adminerを置いたままにすると、データベース操作の入口をインターネット上に公開し続けることになります。ファイル名をランダムにしてあるとはいえ、それは一時的な作業のための最低限の防御にすぎません。もともとセキュリティ対応のためのバックアップだったのに、その作業で新たなセキュリティホールを作っては本末転倒です。「エクスポートが終わったらその場で削除」を鉄則としてください。なお、本記事の作業で使用したファイルとフォルダは、すべて削除済みです。

ファイル一式のバックアップも忘れずに

データベースの .sql.gz が取得できたら、あわせてFTPでWordPressのファイル一式（テーマ、プラグイン、アップロード画像など）をダウンロードします。データベースとファイル一式の両方が揃って、はじめて作業前の状態の完全な控えになります。今回のようにこの後XML-RPCの無効化など構成ファイルの変更を行う場合は、この2点セットを取ってから作業に入ります。

まとめ

• phpMyAdminにもサーバーパネルにも入れなくても、FTPが使えればAdminerでデータベースのバックアップは取得できる
• Adminerのファイル名は必ずランダムなものに変更してからアップロードする
• 容量不足のサーバーでは「セッションの期限切れ」エラーが出ることがあり、session_save_pathで保存先を用意すると回避できる
• session_save_pathの追記位置はnamespace宣言の直後。開始タグ直後に書くと500エラーになる
• 作業が終わったら、Adminer本体とセッション用フォルダをその場で削除する

引き継ぎ案件では、理想的な環境が揃っていないところから作業を始めなければならない場面が多くあります。制約のある環境でも安全にバックアップを確保する手段として、Adminerは覚えておく価値のあるツールです。

よくある質問

AdminerはphpMyAdminと同じことができますか？

データベースの閲覧・編集・エクスポート・インポートなど、日常的な操作はほぼ同等にできます。phpMyAdminが多数のファイルで構成されるのに対し、Adminerは1ファイルで動作するため、サーバーパネルが使えない環境での一時的な作業に向いています。

FTPでファイルを全部ダウンロードすれば、バックアップとして十分ではないのですか？

不十分です。FTPで取得できるのはテーマ・プラグイン・画像などのファイルだけで、投稿や固定ページの本文、各種設定はデータベースに保存されています。ファイル一式とデータベースの両方が揃って、はじめて完全なバックアップになります。

Adminerをサーバーに設置したままにするとどうなりますか？

データベース操作画面への入口を公開し続けることになり、重大なセキュリティリスクになります。URLとデータベースの認証情報が知られれば、サイトの全データを操作されます。作業が終わったら、その場で必ず削除してください。

「セッションの期限切れ」エラーはAdminerの不具合ですか？

不具合ではなく、多くの場合サーバー側の問題です。今回のケースではディスク容量不足でPHPがセッションファイルを書き込めないことが原因でした。session_save_pathで書き込み可能な保存先を指定すると回避できます。

取得したバックアップからの復元も、phpMyAdminなしでできますか？

できます。バックアップ時と同じ手順で一時的にAdminerを設置し、インポート機能で .sql.gz を読み込めば、データベースを取得時点の状態に戻せます。ファイル側はFTPでバックアップ一式をアップロードします。ただしAdminerのインポートにはサーバーのアップロードサイズ上限が適用されるため、データベースが大きい場合は分割などの工夫が必要です。復元作業の後も、Adminerは必ず削除してください。

バックアップやサーバー環境の整理にお困りの方へ

ENVY DESIGNでは、Webサイトの制作・保守運用の一環として、既存サイトの引き継ぎやサーバー環境の整理を含むご相談を承っています。認証情報が不明なまま運用されているサイトの現状把握からでも、お気軽にご相談ください。

バックアップ体制の整備を含む継続的な保守は、ホームページ保守・運用サポートのページでご紹介しています。