WordPressのバックアップは何を残す？ファイルとDBを一組で備える方法

更新の前に保存していても、必要な中身がそろっているかは別の確認です。

画像などのファイルと、投稿・設定を保存するDBを、同じサイトの保存一組として残します。保管先から取り出せるかを確かめ、完了表示だけで復元できるとは判断しません。

残すサイトと、戻したい時点を決める

バックアップは、不具合や誤った編集などに備えて、あとで戻すための複製を残す作業です。まず、公開サイトなのか作業用サイトなのかを確認し、対象のサイトと保存する日付・時刻を決めます。似た名前の別サイトを保存しても、必要なサイトの備えにはなりません。

更新作業の前の状態を残したいのか、日々増える投稿や注文を定期的に残したいのかで、必要な保存時点が変わります。最後の保存からどこまでの変更を失ってよいかを、運営側と作業担当で確認します。保存の間隔を短くするだけで、取得の失敗や保管先の問題が解消するわけではありません。

保存した時点、対象サイト、取得方法、含めたもの・除外したものを一緒に残します。ここでいう「保存一組」は、一つの圧縮ファイルという意味ではありません。同じサイトの対応するファイルとDBを、あとで組み合わせられるように扱う単位です。

ファイルとDBを一組として取得する

DB（データベース）は、投稿本文や各種設定などを保存している場所です。画像、テーマ、プラグインなどのファイルとは別に存在します。WordPressのフォルダーをダウンロードしただけでは、通常はDBの複製まで取得したことにはなりません。

ファイル側では、使用中のテーマやプラグイン、アップロードした画像、サイト固有の設定ファイルなどが対象に含まれるかを確認します。DB側では、そのサイトが使っているDBと必要なテーブルを対象にします。テーブルはDBの中で情報を分けて保存する単位です。別サイトとDBを共用している場合は、ほかのサイトまで混ぜないよう担当者が対象を確かめます。

ファイルとDBは、同じ保存時点を表す一組として取得する計画を立てます。サイトで注文や投稿が続いていると、取得中にも内容が変わります。近い時刻に別々に取得しただけでは、中身が完全にそろっているとは証明できません。更新をどう扱うか、利用中の保存機能がどのように整合性を保つかを、管理会社や担当者に確認します。

手動の場合は、契約先が用意したファイル取得機能やSFTPなどで対象のファイルを取得し、DB管理機能から対象DBをSQL形式で書き出す方法があります。SFTPはサーバーとの間でファイルを転送する方法、SQLファイルはDBの内容を読み戻すための書き出しです。画面や選べる範囲は契約・製品で異なるため、利用している機能の説明に従い、取得対象と結果をそれぞれ確認します。

取得したファイルとSQLの書き出しを、同じ保存分だと分かるフォルダー名や記録で結び付けます。DBを分割して取得する方式なら、必要な部分をすべて同じ一組へ含めます。ファイル名が同じことや容量があることだけで、内容が正しいとは判断しません。

ファイルとDBが別であること、対応する複製をそろえる考え方は、WordPress公式のバックアップ案内で説明されています。ここでは複製を残すところまでを扱い、別サーバーへの接続変更や移転は行いません。

自動保存と手動取得で、中身と結果を確かめる

管理会社の自動バックアップを使う場合は、対象サイト、ファイルとDBのどちらを含むか、除外対象、保存の実行時点、保存期間、利用者が取り出せる方法を確認します。「自動保存あり」という契約名だけでは、必要な日時の複製が現在残っているかまでは分かりません。

プラグインなどを使う場合も同じです。実行した作業の記録を開き、ファイル側とDB側の取得結果、エラーや除外の表示、保存された場所を読みます。別の部品として保存される方式では、DB・画像・テーマなど必要な部品を一つずつ取得する場合があります。すべてを選ぶ操作がダウンロードとは限らないため、削除など別の操作を選ぶ前に、その画面の説明を確認してください。

架空の店舗サイトAには、DBを09:00、ファイルを09:02に取得した時刻と、同じサイトを対象にした記録があります。それでも、取り出しや復元試験は未確認です。相談サイトBは「バックアップ完了」という表示の記録だけで、各取得時刻や保管先は未確認です。二つは別の記録で、BはAを修正した結果ではありません。

PC用の図を原寸で開く / スマホ用の図を原寸で開く

完了表示と、取得した中身の確認を分けると、次の不足が具体的になります。Bならまず、その表示がどの対象・保存時点・部品・保管先を指すかを調べます。Aなら、同じ保存分として必要な中身がそろうかと、保管先から取り出せるかを続けて確認します。どちらも、この記録だけから復元成功とは言えません。

保管先から、同じ一組を取り出してみる

保管先では、対象サイトと取得日時から必要な保存分を選べるようにします。どの担当者がアクセスできるか、保存がいつまで残るかも確認します。公開サイトと同じ場所だけに複製があると、その場所を利用できなくなったときに一緒に取り出せなくなるおそれがあります。契約と情報の扱いに合わせ、別の保管先へ取得する方法も決めます。

次に、予定した保管先からファイルとDBの両方を取り出します。取得が終わったか、必要な部品が欠けていないか、圧縮ファイルが使われている場合は開けるかを確認し、対応する保存日時の一組として識別できるかを読みます。取り出せたことは記録しますが、それを「復元できた」へ書き換えません。

保存先の同期は、過去の版を残すバックアップと同じとは限りません。元のファイルの削除や変更がそのまま反映される方式なら、必要な古い版が残っているかを別に確認します。新しい保存分で古い保存分を上書きする前に、必要な保持範囲を確かめます。

ファイルの保存対象はWordPress公式のファイルのバックアップ説明、DBの書き出しはDBのバックアップ説明でそれぞれ確認できます。DBの説明には過去の製品画面の例も含まれるため、現在の契約先と画面が同じだとは決めつけず、対象を読み取るための資料として使います。

戻す前に、保存後の注文や編集を守る

復元は、保存した内容を読み戻す作業です。取り出した一組でサイトが動くかを試す確認と、公開サイトを実際に戻す操作も分けます。試験をする場合は公開先と切り離した環境を担当者が用意し、必要なデータと確認対象を決めます。実際の試験手順や公開先への上書きは、この保存作業と別に扱います。

古いDBを公開先へそのまま戻すと、その保存時点よりあとに増えた注文や投稿、変更した設定を失うおそれがあります。「前の状態へ戻せる」だけで、最新の取引も守られるわけではありません。実復元の前に、現在の状態を別に保全し、保存後に何が増えたかと残す必要のある情報を確認して、担当者と戻す範囲を合意します。

架空の注文サイトCでは保存物の取り出しを確認していますが、復元試験は未確認で、後日の注文の有無も未調査です。AやBのその後の結果ではありません。この段階では、取り出し済みを理由に公開先へ上書きせず、後日分の保全が必要かを先に調べます。部分的な復元で安全だと判断したり、DBの一部を自己判断で削除したりしないようにします。

制作会社を変える際に受け取るものや権限を整理したい場合は、制作会社変更時の引継ぎの確認順が対応します。サーバーやURLも変える作業は、WordPress移行の手順へ進んでください。ここで説明している継続保存と、引継ぎ・移転の完了条件を混ぜないための案内です。

次に保存する時点と、担当を決める

次回の保存は、投稿・注文などの更新量、失ってよい範囲、利用しているサービスの保持条件を基に決めます。公式資料の一般的な保存頻度や世代数を、そのサイトの保証値として写さないようにします。更新作業の前に追加で保存する場合も、普段の定期保存と区別して記録します。

担当する人を決め、実行予定だけで終わらせず、その回の取得結果と保管先を読みます。取得に失敗した部分や、まだ取り出していない部分があれば、そのまま未確認として次の作業に残します。古い保存分の削除は、保持条件と必要な版が残ることを確認してから担当者が扱います。

今回の完了条件は、対象サイトと保存時点が分かり、ファイルとDBの対象・取得結果・保管先を結び付け、取り出しを確認したかどうかを区別して残せることです。復元の可否、契約に含まれる範囲、後日増えた注文の安全性まで確認済みにはしません。次の保存でも同じ確認を繰り返せる状態にします。

全三記録は図の下の補足で、項目ごとに読み比べられます。「バックアップ完了」の表示だけから、ファイル・DB・保管先や復元試験の結果を補いません。

まとめ：対応する保存一組から確かめる

バックアップは、画像などのファイルと、投稿・設定を保存するDBを対応する一組として残し、必要な日時の保存分を保管先から取り出せるかまで確認します。完了表示や近い取得時刻だけでは、中身の整合性や復元の成功は判断できません。

まず、いちばん新しい保存分を一つ選び、対象サイト・取得時刻・ファイル側とDB側の保存先を照合してください。部品や時点が分からなければ、使っている保存機能の実行記録と対象設定を確認します。公開サイトへ戻す前には、その後の注文や編集を別に保全し、戻す範囲を担当者と確かめます。