データベースは、情報を整理して保存し、必要なものを取り出す仕組みです。WordPressでは記事本文、サイトの設定、ユーザー情報などが保存されていて、普段の管理画面操作で読み書きされています。

一方、画像の実体やテーマのプログラムはサーバー上のファイルです。WordPressはこの二つを組み合わせて表示するため、データベースだけ保存しても、サイト全体のバックアップにはなりません。

WordPressはデータベースとファイルを組み合わせて表示する

訪問者がページを開くと、WordPressはデータベースから記事本文や設定を読み出します。次にテーマのテンプレートへ内容を当てはめ、画像やCSSを組み合わせてページを返します。データベースは表形式で情報を管理し、必要な情報を条件に応じて取り出せる仕組みです。

記事の公開やサイト名の変更は、管理画面を通してデータベースへ書き込まれます。担当者がSQLを直接操作しなくても、日常の更新作業はデータベースを使っています。フォームや予約のプラグインも、入力内容や受付状況を独自のテーブルへ保存する場合があります。

データベースの異常は、見た目の崩れだけでなく、記事が表示されない状態や管理画面へ入れない状態につながります。一方で、画像だけが見つからない場合はファイル側の問題も考えられます。障害時は最初から「データベースが壊れた」と決めつけず、どちらの保存場所に問題があるかを分けて確認します。

管理画面の情報は役割別のテーブルに保存される

WordPressのデータベースには、役割ごとに複数のテーブルがあります。標準構成でよく見る名称と役割を知っておくと、バックアップ対象や調査箇所を確認しやすくなります。ただし、先頭の wp_ は設置時に変更できるため、実際の名称はサイトごとに異なります。

主なテーブル保存される情報の例
posts・postmeta記事、固定ページ、添付情報、記事ごとの追加項目
optionsサイト全体の設定、テーマやプラグインの設定
users・usermetaユーザー情報、権限に関する追加情報
terms関連カテゴリーやタグと記事の関連付け
comments関連コメント本文、投稿者情報、承認状態
プラグイン独自テーブルフォーム、予約、ECなどの機能固有データ

一つの記事でも、本文と追加項目は別のテーブルへ分かれることがあります。特定のテーブルだけをコピーすると関連情報が欠ける可能性があるため、仕組みが分からない状態でバックアップ対象を間引くのは危険です。通常はWordPressが使うテーブルを一組として扱います。

画像とテーマはデータベースの外にある

メディアへ画像を登録すると、タイトルや説明などの情報はデータベースへ保存されます。画像ファイルの実体は通常、wp-content/uploads の下に置かれます。データベースを復元してメディア一覧に項目が戻っても、対応するファイルがなければ公開ページに画像は表示されません。

テーマやプラグインも、基本的には wp-content の下にあるファイルとして動きます。テーマ設定の一部はデータベースに保存されるため、どちらか片方だけで完全に復元できるとは限りません。WordPress本体のファイルと wp-config.php も、データベースの外にあります。

この構造を知っていると、バックアップ画面に「データベース」と「ファイル」が別々に表示される理由が分かります。取得日時が大きくずれた二つを組み合わせると、記事には画像があるのにファイルが存在しないといった食い違いが起こります。

wp-config.phpにはデータベースへの接続情報がある

wp-config.php には、データベース名・ユーザー名・パスワード・接続先などが設定されています。このファイル自体がデータベースではなく、WordPressが正しいデータベースへ接続するための情報です。移転後に「データベース接続確立エラー」が出ても、直ちに記事データが消えたとは限りません。

まずは接続先や認証情報が新しいサーバーと一致しているかを確認します。データベースが存在していても、利用者の権限が不足していれば接続できません。反対に、接続設定を不用意に書き換えると別のデータベースを参照する可能性があります。

接続情報にはパスワードが含まれるため、画面のスクリーンショットや作業メモをそのまま社外へ送らないようにします。調査を依頼するときは、秘密情報を伏せたうえでエラー内容と作業時刻を共有します。

日常の管理画面操作もデータベースを書き換える

記事の編集だけでなく、ユーザー追加やメニュー変更もデータベースへの書き込みです。プラグインの有効化によって設定や独自テーブルが追加されることもあります。通販や予約サイトでは、新しい注文が入るたびに事業上重要な情報が増えていきます。

そのため、公開中のデータベースへ直接SQLを実行する作業には慎重さが必要です。文字列の一括置換や不要データの削除は効率的に見えますが、条件を誤ると広い範囲を一度に変更します。実行前に対象を確認し、バックアップと検証環境を用意します。

データ量が増えたからといって、テーブルを手作業で削除するのも避けます。不要になったプラグインのデータか判断できない場合は、提供元の削除手順を確認します。表示速度の問題はデータ量だけで決まらないため、測定せずに最適化を始めないことも大切です。

バックアップと移転では二つを一組にする

復元可能なバックアップには、データベースとWordPressのファイルが必要です。できるだけ近い時刻に取得し、同じバックアップセットとして管理します。複数サイトのバックアップがある場合は、取得日時と対象サイトが分かる名前にすると、取り違えを減らせます。

サーバー会社の自動バックアップは便利ですが、保存される範囲と世代数はサービスによって異なります。データベースだけが対象なのか、メールやファイルも含むのかを管理画面で確認します。復元が有料であったり、申請に時間がかかったりする場合もあるため、取得だけでなく復元の条件も確認すると、必要なときに使えるか判断しやすくなります。

サイト移転でも考え方は同じです。データベースを移したあとにURLを変更する場合、シリアライズされた設定を単純な文字列置換で壊すことがあります。WordPress向けの移転機能やWP-CLIなど、データ構造を扱える方法を選びます。

分からないままDBを初期化したり、古いバックアップで上書きしたりすると、残っていた情報まで失う危険があります。通常の記事更新でSQLを直接操作する必要はありません。データベースとファイルの違いを知っておくと、移転やバックアップの画面に出てくる項目を理解しやすくなります。