ホームページのバックアップで残すもの｜編集データと公開ファイル

情報確認：2026年11月9日 ／ SIRIUS2編集部

公開中のページを保存しても、作成ソフトで次に編集するときの原本や、問い合わせサービスの記録まで揃うとは限りません。自分のサイトで復旧したいものを「編集を再開する」「公開状態を戻す」「受付を続ける」に分け、保存先と復元の確認方法を決めます。

営業時間を来週から変えるときは、編集用データを開いて原稿を直します。間違った版を公開してすぐ戻したいときは、変更前に配信していたページと画像の控えが役立ちます。編集元が見つからない場合は次回の修正が難しくなり、公開ファイルだけ新しい場合は、編集中にどの版を基準にするかを確かめる必要があります。

SIRIUS2を使用する場合は、サイトの編集用バックアップを用意します。公開先に置かれたHTMLや画像の控えは、作成ソフトで編集を再開するためのサイトバックアップとは役割が異なります。運営に使うソフトの版、テンプレートや追加素材の条件、復元した後に再度公開する手順も、別々に確認します。

WordPressを利用するサイトでは、投稿などが入るデータベースと、画像やテーマなどのファイルを分けて取得します。クラウド型のサービスでは、契約中に使える履歴、書き出せる内容、別契約へ引き継げるものを提供元の説明で確認します。どちらも使う機能によって対象が変わります。方式ごとの更新の違いは、作り方と保守の比較を参照できます。

同じ日に更新した原稿と生成物が揃っていない場合は、どの版を配信中かを記録します。公開側を以前の版に戻したら、次の更新で古い編集元から再び異なる内容を出さないよう、編集担当へどの版を基準にするか共有します。複数方式を併用する場合は、本文は作成ソフト、予約記録は外部サービスのように、復旧先も分けます。

公開用ファイルの控えには、トップだけでなく、関連ページ、画像、スタイル、動作に必要なファイルが揃っているかを確認します。契約者、公開フォルダー、復旧を依頼する連絡先も整理します。共有台帳にはパスワードや秘密鍵を記入せず、事業内の承認された保管先とアクセスを申請する担当だけを記載します。

予約サービスなどの別契約で受付した情報は、そのサービスで取得と復旧の方法を確認します。取得できる範囲と、取得後に誰が閲覧するかを記録します。外部受付のデータを取り出せるからといって、同じ形式でサービスへ戻せるとは限らないので、必要な場合は提供元の手順を調べます。

素材には、画面に表示される写真だけでなく、後で差し替える元画像や、利用範囲を示す記録も含めます。テンプレート、追加機能、フォントなどを別に入れている場合は、同じ環境を用意するために、入手先や適用した版を控えます。再インストール時にライセンスや利用権を確認するものは、取得しただけで再使用できると判断せず、条件も残します。

更新する直前に一つ版を残し、大きく作り替える前後や担当を引き継ぐときにも保存します。ファイル名にはサイト、日付、何の前後かが分かる語を入れます。例えば架空の教室サイトなら、「教室案内_2026-11-09_料金改定前」のような名前にして、同じ日に複数の版を作ったら時刻や版番号も記録します。

編集に使う端末と同じ場所にしか控えがなければ、その端末の故障時に両方へアクセスできなくなることがあります。事業で管理できる別の保管先にも置き、更新に使う場所と復旧用の場所を分けます。同期フォルダーで削除や変更が別の端末へ反映される場合は、以前の版を取り出せる期間や、誰が操作できるかを確認します。

どの版を残すかは、更新頻度と、どの時点まで戻せれば営業できるかで決めます。日々変わる料金と、数か月に一度の写真では保存のタイミングも違います。予約情報を含むデータでは、閲覧できる人、保存する期間、不要になった版の取り扱いも合わせて決めます。

復旧担当が保存先を探す場面を一度想像してください。例えば「事業共有の復旧フォルダーに日付順、直近の更新前は印を付ける」と決めておけば、障害時に編集担当の個人用フォルダーを探す必要が減ります。版の取り違いを避けるため、ファイル名に加えて、直前に変えた内容と取得した担当も台帳に書きます。

1. 変更前の版を選ぶ対象のサイト、取得日、変更の前後を照合します。
2. 検証用の場所を用意通常使う編集元や公開先と区別します。
3. 開き直して確認代表ページ、写真、テンプレート、内部リンクを確認します。
4. できたことを記録試した版、対象、未確認の機能、確認した担当を残します。

ファイルがあることと、必要なページを開いて使えることは別の確認です。復元手順に上書きの選択がある場合は、検証用のコピーを使い、通常の編集データや公開先を選んでいないことを確かめます。画像を別フォルダーから読む方式では、復元先だけで表示できるかも確認します。

開き直しができたら、トップ、案内、更新頻度の高いページを一つずつ確認します。本文の見出しと画像、テンプレートによる見え方、関連記事へのリンクを点検し、別コピーで短い修正を保存できるかも試します。予約やフォームが外部で動く場合、外部の受付データと通知は別の検証項目として扱います。

検証用の場所へ戻す前には、公開や通知を行う設定が引き継がれる可能性も考え、作業対象と実行する操作を限定します。たとえば問い合わせページを開けるところまでを今回の確認範囲とし、送信まで試す場合は別の試験先と宛先を使います。確認済みの範囲を記録しておくと、担当が変わっても試験結果を読み違えにくくなります。

このガイドの編集部は、検証環境でSIRIUS2 1.3.1.0のサイト用バックアップ1点を専用領域に読み戻しました。復元先を開き直した結果、バックアップ時点の13ページを確認し、検証対象ファイルの照合が一致しました。確認の前後で元サイトの記録も一致しました。

この結果は、この記事の制作時に使用した1点のバックアップについての記録です。外部フォームの通知や公開サーバーへの転送は別の確認になります。読み戻した版で現在の受付が動くかは、テストデータと管理下の連絡先を用意してから確かめます。

自分の事業で記録を残すときは、「何を用意したか」「何が開けたか」「まだどこで試していないか」の三つに分けてください。確認対象が少ない場合でも、例えば写真や料金表があるページを選ぶと、文字だけのページとは違う不備を見つけられます。

復元の手順書には、対象のサイト、保管先、版の選び方、検証用の場所、復旧後に確認する人を書きます。新しい担当者が古い版を見つけられるか、認証が必要な保管先に自分の権限でアクセスできるかを、引き継ぎ時に確認します。ソフトを再入手する場合の利用条件と、バックアップファイルを開く条件も分けて整理します。

• 変更前の版を、編集データと公開用のファイルの両方から探せる。
• 復元を試した環境と確認したページ、未確認の機能を記録した。
• 受付サービスの記録、契約、連絡先をどこで調べるか決まっている。
• 戻した後に、表示・リンク・受付を確かめる担当がいる。

復旧が必要になったときは、現在の状態も保全し、戻したい版と対象ページを決めます。通常の変更手順はホームページを自分で更新する手順、戻した後の表示は公開前の確認表で点検できます。更新したのに表示が変わらないときの確認順序も、どの段階に問題があるか判断するのに使えます。

引き継ぎでは、誰が最後に保存したかだけでなく、誰が復旧の操作を判断するかを決めます。サーバーを管理する担当と、営業時間などの事実を確認する担当が違えば、戻した画面を両方で確認します。更新履歴の記録に、復旧後の内容を誰が確認したかも残します。

確認に使った資料

• SIRIUS2公式FAQ｜運用中のトラブルとバックアップからの復元
• WordPress公式｜データベースとファイルのバックアップ

2026年11月9日確認。条件や料金は、利用前に最新の公式案内を確認してください。