SeekerLab

BACKUP / RESTORE

テーマ設定の同期をバックアップとして使う前に

テーマ設定の復元と、サイト全体の復旧は別物です。保存対象を理解し、二つを組み合わせる方法を整理します。

テーマの「クラウド同期」や「設定バックアップ」は便利ですが、WordPressサイト全体のバックアップとは保存範囲が異なります。Lucca 1.0.13のクラウド同期は、ライセンス認証済みユーザー向けに、一般、高度、SEO、クラウド同期の各設定とカスタマイザー設定を扱う仕組みです。投稿本文、ユーザー、プラグイン設定、アップロード画像、テーマやプラグインのファイルそのものを丸ごと保存する機能ではありません。

この違いを理解せずに「同期済みだから戻せる」と考えると、障害時に必要なデータが残っていないことがあります。テーマ設定の同期は調整内容を素早く戻すためのもの、完全バックアップはサイトそのものを復旧するためのもの、と役割を分けて準備します。

テーマ設定の同期が役立つ場面

  • 設定を変更する前の比較用スナップショット
  • 同じテーマを再インストールした後の設定復元
  • ステージングで調整した設定の確認
  • 配色やSEO設定を誤って変えた場合の切り戻し

Luccaでは現在値とバックアップ値の差分を取得する処理があり、復元時は受け取った値を設定スキーマで検証してから保存します。何が変わるかを確認してから戻す運用に向いた設計です。

たとえばヒーローやモバイルDockを大きく組み替える前に同期しておけば、変更後の導線が分かりにくかった場合に設定単位で戻せます。スクリーンショットだけではカラーコードや選択値まで再現しにくいため、設定データとして残ることに意味があります。

ただし、バックアップ名や日時だけでは変更目的を思い出せないことがあります。「公開前」「SEOプラグイン導入前」「秋キャンペーン終了後」のように、復元判断に使えるメモを別途残します。担当者が変わっても、どの状態へ戻すべきか説明できる記録が理想です。

同期だけでは戻せないもの

投稿を削除した、メディアファイルが消えた、データベースが破損した、プラグイン更新でテーブル構造が変わった、といった事故はテーマ設定の同期だけでは復旧できません。サーバー側では、データベースとwp-contentをセットで保存するバックアップが必要です。テーマ更新前には、配布ZIPや直前バージョンも手元に残します。

WordPressの投稿、固定ページ、コメント、ユーザー情報の多くはデータベースに保存されます。一方、アップロード画像、テーマ、プラグインは主にファイルとして保存されます。どちらか一方だけでは、本文は戻ったが画像がない、ファイルはあるが設定が戻らない、といった不完全な復旧になります。

外部サービスの設定も別に考えます。DNS、メール配信、アクセス解析、CDNなどはWordPressのバックアップへ含まれない場合があります。サイト障害に備えるなら、契約先、管理画面のURL、必要な認証方法も運用資料へ記録します。ただし、パスワードや秘密鍵は記事メモと同じ場所へ平文で保存しません。

自動同期の頻度を決める

Luccaは毎時、1日2回、毎日、毎週の頻度を選べます。既定は自動同期オフ、頻度は毎日です。頻繁に設定を変えないサイトで毎時を選んでも、同じ状態の履歴が増えるだけです。一方、制作中に何度も配色や導線を調整する期間は、短い間隔が役立ちます。公開後は変更頻度に合わせて見直します。

頻度はサイトの更新頻度ではなく、テーマ設定を変更する頻度に合わせます。毎日記事を投稿していてもテーマ設定を月に一度しか変えないなら、毎時同期の必要性は低くなります。反対にリニューアル期間中は、短い間隔で状態を残すことで試行錯誤を戻しやすくなります。

自動同期には、誤った設定も保存される可能性があります。重要な変更の直前は自動処理だけに頼らず、正常な状態を手動で残し、日時を記録してください。保存世代数や保持期間が決まっている場合は、必要な時点が上書きされる前に別の記録も確保します。

復元テストを先に行う

バックアップは、取得成功の表示だけでは保証になりません。ステージング環境または影響の小さい設定で、バックアップ一覧の取得、差分表示、復元、公開画面の確認まで試します。復元後はキャッシュを削除し、トップ、投稿、スマートフォン表示、canonical、OGPを確認します。

最初のテストでは、サイト全体の印象を変えない小さな設定を選びます。変更前に同期し、値を変更し、差分を確認してから復元します。復元後に管理画面の値だけでなく、公開画面も元へ戻っていることを確かめれば、実際の障害時に迷いません。

完全バックアップについても、可能ならステージングや別環境へ復元します。復元時間、必要な権限、作業中にサイトを停止する必要があるかを測っておくと、障害発生時の見通しが立ちます。復元テストの結果と手順は、バックアップ本体とは別の場所にも残します。

二層のバックアップ運用

実際の作業では、テーマ設定とサイト全体の二層を同じタイミングで管理します。設定変更の切り戻しはテーマ同期、データ消失や更新失敗は完全バックアップというように、事故の種類から復元方法を選びます。

  1. ホスティングでデータベースとファイルの完全バックアップを取る
  2. テーマ設定をクラウド同期する
  3. バックアップ日時と変更目的を記録する
  4. 更新・設定変更を一項目ずつ行う
  5. 不具合が設定由来ならテーマ設定を復元する
  6. 投稿・ファイル・DBの事故なら完全バックアップから戻す
  7. 復元後に表示と主要操作を確認する

復元方法が決まったら、作業前に新しい投稿や注文、問い合わせが発生していないかも確認します。古い完全バックアップへ戻すと、その後に追加されたデータが失われる可能性があります。公開サイトでは、影響範囲を整理してから復元を開始します。

どこまで戻すかを決める具体例

たとえば10時にバックアップを取り、11時に記事を公開し、12時の配色変更で表示が読みにくくなったとします。配色設定だけが原因なら、テーマ設定を戻す方が11時の記事を保持しやすくなります。データベース全体を10時へ戻すと、その記事まで失われる可能性があります。以下は判断例であり、実際の復元テスト結果ではありません。

原因に合わせて復元範囲を選ぶ
起きたこと最初に確認する対象テーマ設定同期だけで足りるか
色やDockの設定を誤って変更変更前後のテーマ設定差分設定だけが原因なら候補になる
投稿本文を削除ゴミ箱・リビジョン・DBの保存時点足りない。投稿データの復旧が必要
画像ファイルを消したアップロードファイルと対応するDB情報足りない。画像の実体が必要
更新後にサイトが開かないエラーログ、直前の変更、DBとファイルの整合性原因次第。同期画面自体が使えない場合もある

別環境へ設定を移す場合、設定に含まれる画像IDやURLが移行先でも有効か確認します。設定値が戻っても、参照先の画像ファイルがなければ元の見た目には戻りません。WordPress全体の保存対象はWordPress公式のバックアップ解説でも確認できます。

バックアップ記録に残す項目

  • 取得日時と対象サイトのURL
  • LuccaとWordPressのバージョン
  • テーマ設定同期か、ファイル・DBを含む完全バックアップか
  • 変更予定の内容と、戻す判断基準
  • 保存場所、保持期限、復元担当者
  • 復元テストを行った日と結果

記録は長文である必要はありません。復元を担当する人が「何が入っていて、どの時点へ戻り、何を失う可能性があるか」を判断できれば十分です。定期的に不要な古い記録を整理し、最新の復元手順へリンクしておきます。

自動同期が有効でも、問題のある設定が次の同期で保存される可能性があります。大きな変更の直前には手動で状態を残し、どの時点へ戻すか判断できるようにしてください。

まとめ

テーマ設定の同期は、設定変更の切り戻しと再構築を速くする道具です。サイト全体のバックアップを置き換えるものではありません。保存対象、保持期間、復元方法を分けて理解し、両方を組み合わせてください。

バックアップの価値は、正常に戻せることを確認して初めて生まれます。小さな設定で復元テストを行い、結果を記録しておきましょう。更新作業全体の流れは安全に更新するためのチェックリストも参照してください。

この記事の確認範囲:SeekerLabが開発するテーマの対象バージョンのコード・設定定義をもとに記載しています。用途の提案や説明用の例は、実機での測定結果とは区別しています。サーバーやプラグインを組み合わせた全環境での動作を検証したものではありません。執筆元と制作方針記述の訂正を連絡する