WordPressのバックアップ方法|初心者向けに保存・自動化・復元テストまで解説
※本記事にはPRを含む場合があります。
こんにちは。『脱会社員』脱サラを応援し続けるブログ、運営者の『なかびー』です。
WordPressのバックアップは、記事などが入るデータベースと、画像・テーマなどのファイルをそろえて保存し、サイトとは別の場所でも保管するのが基本です。さらに、保存したデータで本当に戻せるかを練習用の環境で確かめると、トラブル時に選べる対応が増えます。
副業ブログでは、仕事の合間に積み上げた記事や設定を失うと、書き直しだけで休日が終わってしまうこともあります。ただ、バックアップ用のプラグインを増やせば安心というわけではありません。この記事では、保存する対象、方法の選び方、初回の取得、頻度と世代管理、復元テスト、日常点検までを順番に整理します。
対象は、レンタルサーバーに設置した一般的なWordPressの単一サイトです。WordPress.com、複数サイトをまとめたマルチサイト、受注・予約・会員情報を頻繁に扱うサイトでは条件が異なります。サービスの仕様は2026年10月3日に公式情報を確認しました。画面名、無料版の範囲、保存期間は変更されるため、実行時は契約先の案内も確かめてください。
先に取り組むことを一つ選ぶなら、「最後に成功したバックアップの日付と、その保存先を確認する」です。これからブログを開設する方は、副業ブログをWordPressで始める手順も合わせて読むと、開設時に用意するものを整理できます。
WordPressのバックアップで残すものはファイルとデータベース

記事と画像は同じ場所に保存されているとは限らない
WordPressでは、投稿や固定ページの本文、コメント、多くの設定情報などをデータベースで管理します。一方、アップロードした画像やPDF、テーマ、プラグイン、設定ファイルなどはサーバー上のファイルです。フォルダーを丸ごとパソコンへコピーしても、別の仕組みで動くデータベースまで自動的に入るとは限りません。
反対に、データベースだけを保存しても、画像そのものやテーマのファイルが欠ければ、元の表示を再現できないことがあります。まずは「本文の記録」と「表示を支えるファイル」が必要だと覚えましょう。基本的な区分はWordPress公式のバックアップ解説でも確認できます。
※表は横にスクロールできます。
| 保存対象 | 主な中身 | 見落としたときの例 | 確認すること |
|---|---|---|---|
| データベース | 投稿・固定ページ・コメント・各種設定など | 記事や設定が以前の状態に戻らない | 対象サイトのDBか、必要なテーブルが含まれるか |
| 画像・テーマ・プラグイン | 主にwp-content内のアップロードや拡張機能 | 画像欠落、見た目や機能の不一致 | 除外指定、独自フォルダー、分割ファイルの有無 |
| ルートの設定・追加ファイル | wp-config.php、.htaccess、独自に置いたファイルなど | 接続情報や転送設定を再設定する必要が出る | 利用機能の保存対象か、別途保管が必要か |
| WordPress外の設定 | DNS、メールサービス、外部ストレージ、外部フォームなど | サイト復元後も関連サービスが動かない | サービスごとの設定記録と復旧方法 |
この表は保存対象を調べるための分類です。実際の構成は利用するサーバーやプラグインで変わります。例えば画像を外部ストレージに置く構成なら、その画像は通常のサーバーファイルの中にない場合があります。「画像が記事に見えている」という理由だけで、バックアップへ含まれると判断しないでください。
エクスポート・自動保存・リビジョンとの違い
管理画面の「ツール」から行うエクスポートは、投稿などのコンテンツを別サイトへ取り込むときに役立ちます。しかし、サイト全体のファイルやすべての設定を一式保存する機能として扱うことはできません。XMLに添付情報が含まれても、画像の実データを丸ごと保管したことにはならないためです。対象は公式のエクスポート画面の説明で確認できます。
記事編集中の自動保存やリビジョンも便利ですが、同じサイトのデータベースが失われれば、一緒に使えなくなる可能性があります。文章の編集ミスを戻す手段と、サーバー障害などに備えるコピーを分けて考えましょう。一本の記事だけの誤編集なら、まずリビジョンを確認し、サイト全体を巻き戻す必要があるか見極めます。
同じ時期に取得した一式を一つのセットとして管理する
記事を保存した直後に画像を追加し、その途中で別々にバックアップすると、本文と画像の時点がずれる場合があります。普段の小規模ブログでも、手動で一式を取る間は投稿の更新を控え、取得開始・完了時刻を記録すると確認しやすくなります。注文や予約が入るサイトでは、短時間のずれも業務へ影響するので、専門の運用設計が必要です。
保存用のメモには、サイト名、取得日時、方式、対象、除外項目、WordPress・PHPのバージョン、保存先を残します。ファイルが複数に分かれる方式では、共通の日時や識別名を手掛かりに同じ回のデータをまとめてください。新しいデータベースと古いファイルを、理由が分からないまま混ぜないことが大切です。
WordPressのバックアップ方法は三つを比較して選ぶ

サーバー機能・プラグイン・手動保存の役割
初心者は、最初に契約中のサーバーのバックアップ機能を確認するのが取り組みやすい順番です。自動保存がすでに動いていれば、その対象と復元手順を理解するところから始められます。そのうえで、自分でも取り出せるコピーを別に用意すると、サーバーの管理画面へ入れない場合への備えがしやすくなります。
※表は横にスクロールできます。
| 方法 | 向いている場面 | 利点 | 導入前に確認する弱点 |
|---|---|---|---|
| サーバーのバックアップ機能 | 契約先の標準機能を活用したい | WordPressの管理画面が開かないときも対応できる場合がある | 保存期間、復元単位、ダウンロード可否、契約終了後の扱い |
| バックアップ用プラグイン | 対象や頻度、外部保管を自分で管理したい | WordPressから保存と復元を操作できる製品がある | 実行条件、負荷、無料版の対象範囲、復元に必要な環境 |
| 手動でファイルとDBを保存 | 独自構成の確認や予備のコピーを作りたい | 中身と保存先を把握しやすい | 取得漏れや時点のずれ、復元操作の難しさ |
| 組み合わせて使う | 一つの障害で全コピーを失いたくない | 異なる保存経路を確保できる | 同時実行の負荷、重複容量、どれを使うかの混乱 |
方法を増やすほど管理の手間も増えます。例えば二つのプラグインが同じ時間に全ファイルを圧縮すると、サーバーの負荷や空き容量の問題が起こりやすくなります。まず主に使う方法を一つ決め、予備をどこに持つかを追加する順番にすると、設定が重なりにくくなります。
サーバーの自動バックアップは保存日数だけで選ばない
確認するのは、「いつからいつまで戻せるか」「ファイルとDBのどちらを扱うか」「自分でダウンロードできるか」「復元が有料か」「復元対象が他サイトに及ばないか」です。同じサーバー契約で複数のサイトを運用しているなら、一つだけ戻す操作なのか、データベース全体なのかを特に確かめましょう。
例として、ConoHa WINGの公式案内では、確認時点で過去14日間分のバックアップと、Web・Mail・DBそれぞれの復元項目が案内されています。ただし、この日数を他社・他プランにも当てはめることはできません。また、同社FAQには、サーバー削除後の復元には使えない旨が記載されています。
「自動で残るから解約後も取り出せるだろう」と考えず、契約変更の前にデータを確保します。各社の料金や機能を含めて見直す場合は、副業ブログ向けレンタルサーバー6社の比較を参考に、現在の契約で足りない機能を整理してください。バックアップだけのために、急いで乗り換える必要はありません。
プラグインは保存機能と復元機能の両方を見る
この記事では例としてUpdraftPlusを使いますが、すべてのサイトに同じ製品が最適とは限りません。選ぶ際は、現在のWordPress・PHPへの対応、更新状況、保存先、復元手順、サポートの範囲を比較します。評判の星の数だけでなく、困ったときに自分が読める公式手順があるかも重要です。
確認時点のWordPress公式ディレクトリの製品説明では、無料版でも手動・定期バックアップ、復元、Google Driveなどへの保存が案内されています。一方、保存先の種類や指定時刻、更新前の自動バックアップなどには有料版の機能があります。外部ストレージ自体の容量や料金も別に確認してください。
特に重要なのは保存範囲です。開発元の対象範囲の説明では、無料版はWordPressのデータベースとwp-content内のファイルが基本で、wp-config.phpや通常の構成外のディレクトリーなどはPremiumの対象として説明されています。「無料版でサーバー内の全ファイルが必ず保存される」と読み替えないようにしましょう。
初回バックアップを取り保存先と中身を確認する手順

手順1:現在の保護状況と作業対象を確認する
まず対象のサイトURLと、作業している管理画面が一致しているかを確認します。複数ブログを運営していると、似た名前の画面で別サイトを操作することがあります。初回作業のメモの先頭にURLと日時を書くと、あとからバックアップを探すときにも役立ちます。
次に、サーバー側にすでにある最新のバックアップを確認し、空き容量を調べます。プラグインで圧縮ファイルを作る場合は、保存元のサイト容量に加えて作業用の空きが必要です。必要な余裕は分割方法やサーバーの制限で変わるため、「元データと同じ容量だけあれば必ず十分」とは考えないでください。
これからプラグインを追加する場合も、先に使えるサーバーバックアップがないかを確認します。バックアップを作るためのプラグイン追加で、既存環境を変更することになるためです。インストールは公式ディレクトリや開発元の正規配布先から行い、名前の似た別製品や出所不明の有料版配布物は避けましょう。
手順2:保存対象とリモート保存先を設定する
UpdraftPlusの例では、管理画面の設定メニュー内からバックアップ画面へ進み、設定タブでファイルとデータベース、保存先を確認します。初回の案内画面や日本語表記はバージョンにより異なります。迷ったら画面を推測して進めず、Learn WordPressのバックアップ手順と利用中の製品案内を照らし合わせてください。
Google Driveなどを使う場合は、どのアカウントのどの領域へ保存するかを先に決めます。個人の非公開フォルダーと、仕事の共有フォルダーを取り違えないようにします。連携の許可画面では、対象アカウントと要求される権限を読み、管理を許されている保存先だけを使ってください。
設定を保存しただけで、外部へのコピーが完了したわけではありません。認証が最後まで終わったか、設定画面にエラーが残っていないかも確認します。管理画面上の「接続済み」という表示と、実際にバックアップファイルが保存された事実を別々に確かめるのがポイントです。
ファイルの除外設定にも目を通します。キャッシュなど再生成できるデータを除外して容量を抑える方法はありますが、よく分からないフォルダーを大きいという理由だけで外すのは避けます。独自の画像保存場所や追加ファイルがあるなら、制作者へ確認するか、別経路で保存する対象として記録します。
手順3:初回は手動実行して完了まで確認する
初回は自動スケジュールを待つだけにせず、手動のバックアップを一度行います。UpdraftPlusでは「今すぐバックアップ」などの操作から、データベースとファイル、設定済みのリモート保存先への送信を確認して進めます。表示される対象を読み、意図せずデータベースだけになっていないかを見てください。
処理中は連続して開始ボタンを押さず、進行状況とログを確認します。通信画面が閉じたことと、バックアップが失敗したことは同じではありませんが、成功したと決めつけることもできません。再度開いたときに、完了表示、実行日時、各構成要素の有無を確認し、警告が出ていれば内容を記録します。
完了後は、保存先のサービスへ入り、同じ時刻のファイルが存在するかを確かめます。プラグインの表示だけで終わらず、可能なら一式を手元へダウンロードして、サイズが不自然に小さくないか、分割されたデータがそろっているかを見ます。フォルダー名を変える前に、復元時に必要なファイル名の規則も確認しましょう。
手順4:手動保存をする場合はDBとファイルを取り分ける
プラグインを使わない場合は、サーバーのファイルマネージャーやSFTPで対象サイトのファイルを取得し、phpMyAdminなどの管理機能で対応するデータベースをエクスポートする方法があります。データベース名が分からない場合、似た名前を勘で選ばず、契約先の説明や設定情報で対象を照合してください。
操作の詳細はWordPress公式のファイル保存手順とデータベース保存手順が参考になります。通信方式はサーバーが案内する暗号化された方法を選びます。この段階で必要なのは取得・エクスポートであり、削除・上書き・インポートをする必要はありません。
保存したSQLファイルには読者や利用者の情報が含まれることがあり、設定ファイルには接続情報も含まれます。中身を質問サイトや公開共有フォルダーへそのまま置かないでください。取得できたら、パソコン側の保管場所とアクセス権も確認します。圧縮を開けることは確認の一つですが、それだけで復元成功を保証するものではありません。
自動バックアップの頻度・保存世代・別保管を決める

頻度は「どこまで失っても書き直せるか」から考える
更新が毎日あるブログを週一回しか保存していないと、タイミングによって数日分の作業がバックアップに入りません。反対に、更新が月一回の小さな紹介サイトを必要以上に短い間隔で全件保存すると、容量と負荷ばかり増える場合があります。記事の本数だけでなく、コメントや設定変更も含めて考えます。
次の表は公式の必須設定ではなく、個人ブログが自分の条件を決めるための例です。実際には許容できる損失、データ量、サーバー制限、予算に合わせて調整してください。受注や予約など、一件の欠落でも利用者に迷惑が掛かる用途では、この表の設定をそのまま使わず、専門家や契約先へ相談します。
※表は横にスクロールできます。
| 運用の例 | 検討する取得タイミング | 残す時点の考え方 | 追加で確認すること |
|---|---|---|---|
| 週末にまとめて記事を書く | 執筆・画像追加が終わった後と定期取得 | 直近の作業前後を複数残す | 平日のコメントや設定変更もあるか |
| ほぼ毎日更新する個人ブログ | 少なくとも日々の変更を意識して設計 | 最新だけでなく数日前にも戻れるようにする | 一日分の損失を許容できるか |
| 更新前・テーマ変更前 | 変更直前の手動取得 | 通常の自動循環とは分けて変更前を残す | 変更後に不具合が分かるまで確保できるか |
| 受注・会員・予約を扱う | 業務要件に応じた短い間隔などを専門的に設計 | 取引データの整合性を優先する | 外部決済や通知との食い違い、復旧手順 |
ファイルとDBの頻度を分けるときの注意点
UpdraftPlusではファイルとデータベースのスケジュールを別々に設定できます。例えば画像が少ない文章中心のサイトでは、DB側の取得頻度を高める設計も考えられます。ただし、DBだけ新しくても、記事が参照する新しい画像が古いファイルのバックアップに入っていなければ、表示の欠けが生じます。
設定を分けるなら、画像・テーマ・プラグインを変更した日にファイル側も取得するなど、整合性を補うルールが必要です。初心者のうちは、まず同じ作業の区切りで両方を取得できる運用を作るほうが把握しやすいでしょう。指定可能な間隔や有料版との差は開発元のスケジュール設定説明で確認できます。
最新一個だけでなく複数の世代を残す
「世代」とは、異なる時点で取得したバックアップのまとまりです。毎回一つのファイルを上書きするだけでは、壊れた状態で新しいバックアップが作られたときに、正常だった頃のコピーがなくなります。直近の複数回と、少し前の区切りのコピーを残すなど、発見が遅れた不具合にも対応できるか考えます。
ただし、何世代でも無制限に保存すればよいわけではありません。個人情報を含む古いデータを必要以上に残すことにも注意が必要です。保管目的と期間を決め、定期的に見直します。古い世代を削除する前には、新しい正常な一式があること、別保管先へも届いていることを確認しましょう。
容量の見積もりは、初回の実測値から始められます。例えば一式が2GBで、同程度の完全バックアップを7世代残すなら、単純計算の保存量は約14GBです。これは圧縮率や差分保存、作業用領域、将来の画像増加を含まない例なので、契約容量をこの数字ぴったりに合わせないようにします。
サイトと同じ場所だけに置かない
サーバー内にしかバックアップがないと、サーバー障害や契約削除、同じアカウントへの不正アクセスの影響を一緒に受けるおそれがあります。クラウドストレージや外付け媒体など、サイトとは別の場所で持つコピーを用意しましょう。クラウドを使う場合も、共有設定が非公開かを確認します。
単なる同期フォルダーは、元データの削除が同期先へ反映されることがあります。削除後に戻せる履歴の有無、保持期間、アカウントを失った場合の復旧方法まで確認して、バックアップとして使えるか判断します。パソコンと外付け媒体を同じ場所に置けば、盗難や災害の影響は共通するため、保管場所の分離も検討してください。
復元は本番に触る前に別の環境でテストする

バックアップの成功表示と復元成功は別に確かめる
保存できたように見えても、必要なファイルが除外されていたり、ダウンロードが途中で終わっていたりする可能性があります。復元テストは、保存したコピーからサイトを動かし、どこまで再現できるかを確かめる作業です。初回設定後や保存方法を変えた後に一度試すと、障害が起きる前に不足へ気付きやすくなります。
練習には、サーバーのステージング機能やローカル環境など、本番から切り離した場所を用います。「本番」というタブを閉じ、テスト先のURLとデータベースを確認してから始めてください。コピー先が本番のデータベースへ接続する設定になっていれば、別URLでも安全な練習環境とはいえません。
別URLへの再現は、同じURLへ戻す復元とは手順が異なる場合があります。URLの書き換えやライセンス、PHPの違いなどが関わるため、使用する機能の移行・複製手順に従います。サーバーを実際に引っ越すことが目的なら、WordPressのサーバー移行チェックリストで、切り替えやメールなどの確認も行ってください。
練習環境からメール・決済・通知が出ないようにする
本番のコピーには、問い合わせ先、会員情報、メール送信設定、外部サービスの連携情報まで含まれる場合があります。復元しただけで、定期処理や通知が動く可能性も考えておきます。テスト先はアクセス制限で保護し、実際の利用者へのメール、決済、注文処理、外部への自動投稿などを停止できる構成にしてください。
検索エンジンへの表示を抑える設定は、非公開にするアクセス制限と同じではありません。個人情報が入るコピーを置くなら、認証などによって閲覧できる人を絞ることが必要です。外部連携の停止をどう設定すればよいか分からない場合は、公開サーバーに練習用コピーを作る前に、管理者や制作会社へ相談しましょう。
UpdraftPlusで同じ場所へ戻す場合の流れを知っておく
同じサイトURLに戻す例では、対象のバックアップセットを一覧から選び、復元対象を確認して進めます。ローカルにデータが残っていなければ、リモート保存先から取得するか、保管していた一式を読み込ませます。開発元の復元ガイドでは、管理画面に入れる場合と入れない場合が区別されています。
復元ボタンを押す前に、日時、対象サイト、ファイルとDBの組み合わせを再確認します。データベースを戻すと、バックアップ後に追加した記事、コメント、設定などが失われる可能性があります。練習であっても、この影響を言葉で説明できるようになるまで、安易に本番へ同じ操作を繰り返さないでください。
設定ファイルの扱いも重要です。別のデータベースへ接続する環境で古いwp-config.phpをそのまま戻すと、接続先が合わなくなることがあります。開発元の設定ファイル復元に関する説明を読み、必要なら内容の違いを専門家に確認してもらいましょう。初心者向けの一般記事だけで、すべての環境の上書き判断はできません。
※表は横にスクロールできます。
| 復元後の点検対象 | 確認する例 | 合格の目安 | 気を付けること |
|---|---|---|---|
| 記事と画像 | 新旧の投稿、固定ページ、添付PDF | 対象時点の本文と画像が対応して表示される | 新しい記事だけで判断しない |
| 表示と設定 | スマホ表示、メニュー、テーマ設定、内部リンク | 普段使う経路をたどれる | キャッシュで古い表示を見ていないか |
| 管理画面と拡張機能 | ログイン、プラグイン一覧、編集画面 | 必要な機能がエラーなく使える | 本番用の外部連携を不用意に動かさない |
| フォームなどの動作 | テスト用送信先での入力確認 | 意図したテスト処理が完了する | 実利用者へのメール・課金は発生させない |
| 運用の再開条件 | バックアップ設定、通知先、次回実行 | 復元後も保護する仕組みが確認できる | テスト側から本番の保存先を上書きしない |
本当の障害ではまず現状を保全し戻す範囲を決める
サイトに問題が起きたら、最後に正常だった時刻と、その前後に行った変更をメモします。ログを確保し、安全に取得できるなら現在の状態も残します。不正アクセスが疑われる場合は、通常の更新失敗と区別してサーバー会社へ連絡し、ログなどを消す操作を控えてください。
一つのプラグイン変更や一記事の編集が原因なら、サイト全体の復元より小さな範囲で解決できる場合があります。全体を戻す必要があるときも、バックアップ後の更新をどこから回収するか、問い合わせや注文への影響をどう扱うかを決めます。利用者のデータが動くサイトでは、受付停止や差分の反映を含めた手順が必要です。
復元後にトップページが開いたら終わり、とはしません。上の表に沿って実際の機能を確認し、必要なキャッシュの更新や監視も行います。侵害が原因なら、古いバックアップへ戻しても侵入口や混入データが残るおそれがあります。原因を特定し、安全な更新や認証情報の見直しを専門家と進めてから再開してください。
バックアップを続ける点検ルールとよくある疑問

自動化した後は「成功した日」を定期的に見る
自動化の目的は、毎回の取得操作を減らすことです。動作確認まで不要になるわけではありません。自分が確認する曜日を決め、最終成功日時、外部保存先のファイル、空き容量、警告の有無を一緒に見ます。「予定日は表示されているが、最後に成功したのは一か月前」という状態を見逃さないようにしましょう。
通知機能を使う場合は、受信先が普段確認するアドレスか、迷惑メールへ入っていないかも確かめます。成功通知を大量に受けて読まなくなるなら、失敗や未実行を見分ける方法を整理します。通知が来ないことを、そのまま問題がない証拠にはしないでください。
管理メモは難しい形式にせず、「10月3日、手動で取得、DBとファイルあり、外部保存確認、次のテスト日を決めた」のように結果が分かれば十分です。ここにパスワードや接続キーを直接書き込む必要はありません。復旧担当者がいる場合は、秘密情報の保管場所と連絡先を安全に引き継げるようにします。
バックアップが進まないときは何を確認する?
最初に、どの段階で止まっているかを分けます。ファイル作成中なら、サーバーの空き容量、実行時間の制限、大きなファイル、ログのエラーを確認します。外部送信中なら、ストレージの残量、連携認証、通信エラーなどが確認対象です。一度に多くの設定を変えると原因を追いにくいため、一項目ずつ記録します。
手動実行は成功するのに自動実行だけ動かない場合は、スケジュールの仕組みも確認します。UpdraftPlusはWordPressのスケジュール機構に依存し、アクセスが少ないことなどで実行が遅れる場合があります。開発元のアクセス不足の警告説明を読み、必要な対応を契約先へ確認してください。
よく分からないままWP-Cronを無効化したり、設定ファイルを書き換えたりするのは避けましょう。予約投稿など別の処理にも関係するためです。サーバー側の定期実行へ変更する場合は、対象サイトと実行間隔、二重実行の有無まで管理できる人に依頼するのが安全です。
問い合わせるときは、製品名とバージョン、WordPress・PHPのバージョン、実行日時、エラーの該当部分、手動と自動のどちらで起きるかをまとめます。バックアップ全体や設定ファイルをいきなり送らず、ログにメールアドレスや接続情報が含まれていないかを確認し、指定された安全な窓口で必要な範囲だけ共有します。
無料版だけでもバックアップできる?
一般的な個人ブログで必要な保存・復元に対応する無料プラグインはあります。ただし、自分の構成で保存したいファイル、保存先、日時指定、通知やサポートなどが無料範囲に入るかは別です。価格だけで決めず、初回取得と復元テストを通して不足を確認しましょう。
有料版を検討する目安は、「必要な保存対象が無料版では扱えない」「運用したい保存先に対応しない」「復旧時のサポートが必要」など、具体的な条件が見えたときです。購入すれば設定ミスがなくなるわけではなく、契約更新や外部ストレージの料金も含めて管理する必要があります。
バックアップファイルが大きいときは画像を消してよい?
容量を減らす目的で、本番の画像やバックアップ内のファイルを安易に削除しないでください。記事の中で使っていないように見えても、別ページや古い記事から参照されている場合があります。まず何が大きいのかを調べ、過去のバックアップが新しいバックアップへ重複して含まれていないかも確認します。
動画を直接大量に置いている場合や、独自に追加した大きなファイルがある場合は、通常の記事画像とは分けて運用を考えます。除外するなら、そのデータをどこで保管してどう戻すかを決めてからです。圧縮・分割の設定を変えるときも、一式が復元可能かを再度確認してください。
更新前はどのタイミングで取ればよい?
WordPress本体、テーマ、プラグインの更新や大きな設定変更の前に、その直前の正常な状態を残します。前日の自動バックアップだけでは、その日に書いた記事や変更した設定が含まれていない場合があります。WordPress公式の更新手順でも、作業前のバックアップが案内されています。
更新前の一式を取得したら、成功と保存先を確認してから更新します。可能なら練習環境で変更を試し、本番では変更した項目と時刻を記録します。変更後に不具合が分かるまで、更新前の正常なコピーをすぐに削除しないことも大切です。バックアップを理由に更新を長期間放置せず、戻せる準備と更新の習慣をセットにしましょう。
今日決めておく三つのこと
最初に、今あるバックアップの日時と対象を確認します。次に、サイトとは別の場所へ一式を保管する方法を決めます。最後に、本番と切り離した環境で復元を試す日を予定に入れます。難しい操作を一日で全部終わらせるより、どこまで確認できていて何が未確認なのかを明らかにすることが、次の行動につながります。
副業ブログを長く続けるには、記事を書く時間と同じくらい、積み上げた内容を守る仕組みも大切です。方法の数ではなく、「必要なデータがそろっている」「別の場所にある」「戻す方法を確かめた」という三点を軸に、自分で続けられる運用を作っていきましょう。
参照した公式情報
以下は2026年10月3日に確認した公式情報です。本文中の運用例や点検表は、各資料を踏まえた本記事の整理であり、各社がすべてのサイトへ同じ設定を指定しているものではありません。
WordPress:バックアップの基本 / ファイルのバックアップ / データベースのバックアップ / エクスポート機能 / WordPressの更新
Learn WordPress:サイトのバックアップ / UpdraftPlus公式ディレクトリ / UpdraftPlusの保存対象 / 自動スケジュール
UpdraftPlusの復元 / 設定ファイルを復元する際の注意 / 自動実行とアクセス不足の警告 / ConoHa WINGの自動バックアップ / ConoHa FAQ