サイトバックアップ環境整備

サイトの危機が起きた時に対応すべき事を、徹底的に調べ・検証・確信しましたので、ご確認よろしくお願い致します。

見出しは以下の内容になります。

  1. バックアップ
  2. 復元
  3. トラブルシューティング
  4. 提案

なお、具体的な対応方法についても、メモとして残す意味と、鈴木様へ提供する意味で掲載してまいります。

目次

1.バックアップについて

バックアップはとても大事です。これがなければ最悪の事態ですが、きちんと取れさえいてれば、基本的には完全に戻るという確信も得ました。

バックアップに必要となるデータは、「ディレクトリファイル」と「データベース」の2組です。

「ディレクトリファイル」のバックアップの方法

「ディレクトリファイル」のバックアップの方法は、以下の3つの方法で対応可能です。

  • A.プラグイン
  • B.手動(FTP)-(結論・不採用)
  • C.手動(エックスサーバー)

A.プラグインで「ディレクトリファイル」のバックアップを取る方法

プラグインでバックアップを取る場合は、「All-in-One WP Migration」(現在導入済み)を利用します。

なお、最初に注意点ですが、特に「SiteGuard WP Plugin」は、All-in-One WP Migrationと相性が悪いそうですので、必ず無効化してからエクスポートが必要になります。

普通にバックアップをとる

プラグイン→エクスポートにて、緑の「エクスポート先」をクリック

指定の場所に保存の意味なので、「ファイル」を選択します。

クリックすると生成されますので、画面通りにダウンロードすればOKです。

「バックアップ」というものを利用する

プラグインにある「バックアップ」という項目は、上記でエクスポートまたは、緑の「バックアップ作成」ボタンを押せば作成されます。

これは、いつでも、その時にバックアップした状態に戻れるというもので、いちいちPCにバックアップファイルを残しておかずとも、ここでバックアップをしておけば理論上はいつでもバックアップできるという事になります

ただし、このバックアップはファイルは、FTP画面にて、public_html → wp-content → a1wm-backups 内に自動で保存されていきます。

ですので、闇雲にバックアップだけを行うと、サーバーの使用容量がどんどん圧迫されていきますので、計画性のあるバックアップが必要になります。

検証結果

FXmegabankで実際の作業をした結果、プラグインのボタン操作のみで約15分かかりました。

6GBのデータが作成され、そのダウンロード自体に18分かかり、合計で33分かかりました。

これは、PCが開いた状態の話ですので、何も起動していない状態やその他諸々を考えると約40分ほどかかると見積れます。

また、PCへファイルのダウンロード途中でネットワークエラーが出ましたが再開できたので、最後までダウンロードはできたのですが、このデータが使えるかどうかを検証するのは実サイトに影響するところですので、確認しておりません。

もし、使えない場合は、「ネットワークエラーが出た場合は再度やり直す」という時間も時間を見積もる必要があります。

また、ダウンロードファイルでは、6.18GB、プラグイン画面では、5.75GB、FTP画面では、6.2GBとバラツキがあり、どれが正しい数値なのかも不安なところです。

このPCへのダウンロード作業は、上記を考慮し、頻度や必要性なども検討したいところです。(要検討案件)

とても簡単に操作できるので、大変便利だと思いますが、所詮プラグインですので、サポート切れ、WordPressのバージョン変更による動作不良なども考えると、これだけに頼るのはかなりリスキーかと感じます。

そもそもダッシュボードに入れない状態になっていると操作自体ができないので使えないので、その辺はかなり弱いです。

ただ、やっておくに越したことはないので、バックアップルーティーンに加えるのはアリだとは思います。(要検討案件)

B.手動(FTP)で「ディレクトリファイル」のバックアップを取る方法(結論・不採用)

手動(FTP)で「ディレクトリファイル」のバックアップを取る方法では、サイバーダックというソフトを利用します。

方法は簡単で、サイバーダックにログインし、対象ファイルを右クリックでダウンロードするだけです。

ただし、ダウンロードする時間が以下の結果となり、不採用という判断にしました。

[FXメガバンク(6GB)ダウンロード結果]

wp-contentフォルダ以外は、6分程度で完了しましたが、wp-contentフォルダは、2時間40分かかりました。

さらに、一部完全にダウンロードできていない様子があり、「転送未完了」となります。

このままでは完全に復元できるかはわからない状態なので、追加でエラーファイルを個別にダウンロードしなおすという選択肢も一応はありますが、手間がかかりすぎるのであまり現実的ではありません。

[当社サイト(728MB)ダウンロード結果]

34分経過後、エラーの為に失敗。

サイトガード(ダウンロードの際に複数エラーがあった)の停止と転送履歴を削除(ネットに書いてたおまじない程度)し再挑戦したところ、 特に止まることなく44分でダウンロード終了。

手動(エックスサーバー)で「ディレクトリファイル」のバックアップを取る方法

ディレクトリファイルのバックアップは、エックスサーバーでも対応可能だとわかりました。

そして、エックスサーバーでのダウンロード時間は、当社サイト(728MB)で調べたところ、圧縮時間・3分、ダウンロード・1分の合計4分で完了できました。圧縮してからダウンロードするというのが大事なポイントでした。

なお、FXメガバンクではどれだけかかるのかは、コントロールパネルにログインできていないので未検証です。

エックスサーバーの自動バックアップを利用

上記の事から、手動のバックアップについては、エックスサーバーで行う事を推奨したいと思いますが、実は、エックスサーバーでは、そもそも自動でバックアップが1週間分保存されております。

サーバーパネルのバックアップから、「自動バックアップデータ取得・復元」というところで、サーバー内の全てのドメイン・ディレクトリファイルを一括でダウンロードすることが可能です。

ただし、結構作成に時間がかかり、私の全データで15分程度要しましたので、鈴木様の場合はもっとかかると思います。

生成したバックアップファイルは、サーバーディレクトリのホーム(/)直下の「userbackup」にて保存されます。

こちらは、日付が書かれてフォルダ分けされませんので、おそらく、上書き保存されていくように思います。(実際は、この方法はとらないと思いますので、詳細は未検証です)

ただ、特定のドメイン毎に分けてダウンロードすることも可能で、ダウンロードする目的が決まっているならこちらの方が早いです

こちらは通常通り、PCにダウンロードされます。

ただし、ファイル形式が「.tar.gz(ター・ジージップ)」というものになります。この形式は、今後も結構でてきますので、以下で補足しておきます。

ですので、最悪の話だけでお話をしますと、わざわざバックアップを取るという措置を行わなくても、基本的には対応可能という事も言えます

もちろん、バックアップを取るに越した事はないと思いますので、こちらは、この後別で相談予定の保守契約の再検討相談案件として考えております。

圧縮ファイル形式について

・Gzip(ジージップ)

gzとはGNU zipの略です。gzipは、圧縮を行う事なのですが、複数のファイルを1つにしたり、フォルダごと圧縮することは出来ません。要は、圧縮はできるが、まとめては行えないという事になります。

・Tar GZip(ター・ジージップ)

「tar」とは、まとめるという意味です。「tar」でまとめたファイルを、「gzip」で圧縮したファイルという事になります。要は、まとめて圧縮する、という事になり、基本的にはこの形で利用する事が多いと思います。

ちなみに、一般的なzip形式は複数のファイルをまとめて圧縮できます。なぜ、似た機能で複数種類があるのかというと、プラグラミングに適した形式がそれぞれあるようです。

「データベース」のバックアップの方法

「データベース」のバックアップ方法は、以下の2つの方法で対応可能です。

  • A.手動(phpMyAdmin)
  • B.手動(エックスサーバー)

A.手動(phpMyAdmin)での「データベース」バックアップ方法

phpMyAdminにログイン(データベースのパスなどの情報が必要です)をし、上部のエクスポートボタンを押します。

方式は「詳細」で、対象は全選択にしておきます。

以下はなにもせず、そのままで実行します。

なお、「簡易」で出力すると、サイトは表示されましたが、システム上のエラーが見受けられましたので不採用とします。

B.手動(エックスサーバー)での「データベース」バックアップ方法

エックスサーバーからもデータベースのダウンロードは可能です。

ダウンロードの際は、重すぎるとダウンロードできないので、必要に応じて圧縮(gz形式)でダウンロードします。おそらくFXメガバンクは圧縮しなくてもいけるのではないかとは思います。

とっても簡単にダウンロードできますので、基本的にはこちらのエックスサーバー経由でバックアップすれば問題なさそうです

エックスサーバーの自動バックアップを利用

上記の事から、手動のデータベースバックアップについては、エックスサーバーで行う事を推奨したいと思いますが、ディレクトリファイルと同様に、そもそも自動でバックアップが1週間分保存されております。

ですので、最悪の話だけでお話をしますと、わざわざバックアップを取るという措置を行わなくても、基本的には対応可能という事も言えます

ですので、こちらも再検討案件となります

また、そもそも私はエックスサーバーへログインできませんので、その情報を私に公開するのか?しないのか?で、私にできる事、鈴木様しかできない事が別れてきます。要相談案件になります

2.「復元」について

バックアップは結構簡単ですが、復元は少し繊細になり、ややこしくなります。

ただし、どれだけ失敗しても、完全なバックアップができていれば必ず戻す事ができます

復元の際の注意点

各バージョン

・復元してもphpのバージョン移行はされませんので、必ずサーバー設定で、バックアップ時と同じPHPバージョンしておく必要があります。なので、こちらはphpバージョンをアップした際などは要注意となります。
バッアップ取得前後でphpやワードプレスバージョンの変更をした場合などは、一旦過去のバックアップは別フォルダに分けておくなどしておいた方が、わかりやすく管理できるのではないかと思います。

・復元しても、WordPressのバージョンは復元されないので、復元前(ダメな状態)のままです。

・復元しても、プラグインのバージョンは復元されないので、復元前(ダメな状態)のままです。

パーマリンク

復元するとパーマリンクの再設定が必要になりますので、事前にどのパーマリンク設定をしているのかを調べておきましょう

・復元後は、必ずパーマリンクを何もしなくていい(おかしくなっている場合は要修正)ので「更新」ボタンを押すようにします。そうすることで、.htaccess が生成され、正しく認識できるよう初めて動き出します。

ディレクトリファイルの復元方法

WordPressのアップデートに失敗した場合は、ディレクトリファイルの復元だけで元に戻ることが多いです。

なお、WordPressでは、wp-contentファイル以外が、WordPress本体(バージョンアップ関連)にあたります。逆に言うと、バージョンアップでは、wp-contentフォルダは関係ない事になります。

サイトのオリジナル部分は wp-contentフォルダに全てありますバージョンアップ関連はそれ以外で、プラグイン関連は、wp-content内の「plugins」です。

ですので、悪いのがプラグインなのか、WordPressのバージョンなのか、phpなのかなど、状況によってはデータを全入れ替えしなくても、パーツの差し替え作業で対応できる場合がありますので、冷静に対応しましょう。

ディレクトリファイルの復元方法は以下の3つになります。

  • A.プラグインを利用する
  • B.手動でファイルをバックアップファイルを差し替える
  • C.エックスサーバーのバックアップを利用する

A.プラグインを利用する

「All-in-One WP Migration」のプラグインでバックアップをとっている場合は、そちらを使って復元が可能です。

ただし、ダッシュボードに入れる事が前提になり、入れない場合はこの方法は使えません。

インポートする

プラグインに、対象ファイルをドラッグドロップしてインポートすればOKです。

「インポート処理により、データベース、メディア、プラグイン、テーマを含むサイトのデータが上書きされます。次の手順に進む前に、必ずデータのバックアップを作成してください。」という警告が出ますが、大前提で、すでにサイトが壊れている状態が想定できますので、ここは再度バックアップをとる必要はないと思います。

「開始」を押します。

サイトをインポートしました。
» パーマリンク構造を保存する (新しいウィンドウで開く)。→→→→→→→→これを押すとログイン画面になるので押しましょう。

変更をしていなくても、パーマリンクの更新を行いましょう。

復元を利用する

「All-in-One WP Migration」の復元ボタンを押します。

開始ボタンを押したあと、「サイトをインポートしました」の画面で、「パーマリンク構造を保存する」を必ず押します。

するとデータベースの再構築が行われます。(行われない時もあり)

実際のところ、わざわざインポートせずとも、バックアップファイルからの復元ボタンを押す方が手っ取り早かったりもします。対応はどちらでもいいと思います。

B.手動でファイルをバックアップファイルを差し替える

単純に、データを復元したいのであれば、バックアップファイルをFTPで差し替えればOKです。ただし、原因がどこかわかっているのであれば、その箇所だけを差し替える方がよいでしょう。

また、バックアップ一式をサーバーにアップする場合は、そのままFTPにドラッグドロップしてしまうとかなり時間がかかりますので、まずFTPにて、ダウンロードしているZIPファイルを設置し、そして、「エックスサーバー内」で展開する事がポイントになります。

C.エックスサーバーのバックアップを利用する

エックスサーバーにある、バックアップ復元機能を利用します。

日付と「対象を指定して復元」を押すだけです。

データベースの復元方法

サイトが改ざんされたりすると、ディレクトリファイルを差し替えても復元しない事もあるので、その時はデータベースの復元も必要になります。

復元方法は以下の方法になります。

  • A.プラグインを利用する
  • B.手動(phpMyAdmin)でバックアップファイルと差し替える
  • C.エックスサーバーのバックアップを利用する

A.プラグインを利用する

実は、「All-in-One WP Migration」のプラグインのバックアップには、データベースも含まれます

ですので、プラグインを利用すると、ディレクトリファイルの更新と共に、データベースも自動でバックアップ時のものに変更されます

B.手動(phpMyAdmin)でバックアップファイルと差し替える

手動(phpMyAdmin)でバックアップファイルと差し替える方法としては、phpMyAdminで作成したバックアップのsqlファイルを、phpMyAdminでインポートします。(別に、エックスサーバーでダウンロードしたsqlファイルでも問題ないと思います)

特に、ファイルを突っ込む以外に、設定などを変える必要もありません。また、一部のファイルの変更でも、全部ファイルを突っ込めば上書きされます。

C.エックスサーバーのバックアップを利用する

エックスサーバーのバックアップを利用する場合は、管理画面にて操作します。

とっても簡単にでき、特に問題なく、動作確認しました。

3.「トラブルシューティング」について

こちらで想定できるトラブルを考えましたので、お話ししてまいります。

  • A.WordPressのバージョンアップ
  • B.プラグインのバージョンアップ
  • C.外部からの攻撃
  • D.作業時
  • E.テーマトラブル
  • F.データーベース破損

を大きく考えられるトラブルとして想定しました。

A.WordPressのバージョンアップ

WordPressのバージョンアップの際には、トラブルが起こる可能性が高いです。

これは常に起こる可能性を秘めており、事前に対処できる事としては、バックアップ環境などを再確認した上で作業に取り組む事が大事になります。

そして、アップデートで問題が起こるのであれば、ダウングレードする方法を理解しておく事が大事です。

アップデートの際は、プラグインを一度全部切っておいてからアップグレードすると、何が原因でエラーになったのかの切り分けができるようになりやすいです。

また、WordPressのバージョンによっては、対象PHPバージョンが不適合の場合がありますので、事前に対象バージョンのphpバージョンの確認が必要です

WordPressバージョン推奨PHPバージョン
5.7 – 5.87.4以上
5.67.4以上
5.57.4以上
5.3 – 5.47.3以上
5.27.3以上
5.0 – 5.17.3以上

参考:https://tcd-theme.com/2021/09/wordpress-php-version.html

WordPressバージョンのダウングレード

ワードプレスのダウングレード方法は以下の2つです。

  • a.プラグインを利用
  • b.手動
a.プラグインを利用

ワードプレスのダウングレードには以下のプラグインが有効です。

WP Downgrade | Specific Core Version
(使用時に、「自己責任です」と警告されて怖いが、2個の信頼できそうなサイトで紹介があり、私も実績あり)

設定→wp downgrade から 任意のバージョンを選択します。

ダッシュボードの更新画面のアップロードボタンが任意のバージョンに変更されるので、ここの画面で実行する

b.手動でダウングレード

1-まずは、欲しいWordPressのバージョンを用意します。(大前提で、トラブルの起こる前のバージョンを知っておく必要がある

バージョン一覧:https://wordpress.org/download/releases/

そのファイルを元に、ファイルを差し替えていきますが、トラブルがあった元データから絶対に消してはいけないファイルがあります。

  • □ wp-content(フォルダ)
  • □ .htaccess(隠しファイル)
  • □ wp-config.php

これらは、そのサイトのコア(オリジナル性の部分)になります。

さらに、サブディレクトリのurlをindex.phpなどで変えている場合は、それを残すかどうか要検討しなければなりません。FXメガバンクは検討しなくて大丈夫です。

2-ダウンロードしたWordPressの

  • □ wp-content(フォルダ)
  • □ .htaccess(隠しファイル)
  • □ wp-config.php

「除いた」ファイルをFTPでアップし、トラブルデータの上書きをしていく。

.htaccessとwp-configは、ダウンロードファイルに、おそらく入っていないので、作業的には、実質「wp-content以外」を投入することになる。もし、上記があった場合はきっちり削除しておく。

その後ログインを行い、「データベースの更新」が出た場合は、そのまま更新をします

B.プラグインのバージョンアップ

プラグインのバージョンアップでトラブルが起こる事も多いです。

もし、エラーが起きた場合は、

管理画面にて無効化
バージョンアップ後にエラーが起きれば、ダウングレード(事前に、以前のバージョン確認必須
管理画面に入れなければ、FTPにて、「wp-content/plugins」の名前を「plugins_old」などに変える事で無効化される

などの対応が考えられます。

また、WP Rollbackというプラグインでプラグインを更新前の状態に戻す事もできる。

C.外部からの攻撃

これも常に起こる可能性を秘めている。事前に対処できる事としては、以下のような事があります。

  • WordPressバージョンの管理(最新を意識)
  • 不要なプラグインの削除
  • 定期的なバックアップ
  • ログのチェック
  • パスワード管理
  • セキュリティ用プラグインの導入
  • 管理画面へのアクセス制限
  • セキュリティソフトを従業員の端末に導入
  • WAFの導入

上記は、ほぼほぼ実践済みだと思います。

また、エラー番号の理解や、エラーログの確認(デバッグ機能)など、原因を特定できそうな作業を理解しておく事や、アクセス制限などの緊急対応も候補として考えておく事も大切です。

エラー番号の理解

エラー番号の理解をしておく事はとても大事です。

400番台-HTTPクライアントエラー

サイトの訪問者が使用しているブラウザとサイトのサーバーの間での通信中に問題発生。要は、閲覧の仕方に問題あり、という事です。閲覧者が対応して解決していくものです。

400 Bad Request

URLが間違っていたり、キャッシュのクリアなど

403 Forbidden

権限がなかったりして、見れなくなります。ファイルの権限のリセットや新しい.htaccessファイルが必要になったりします。

500番台

サーバーでエラーが起きている。

など、その番号によってエラーを予測していきます。キリがないので、その都度調べていきます。

エラーログの確認(デバッグ機能)

デバッグ機能とは、そのサイトで起こっている問題のログを出力し、問題箇所を特定していく方法です。

wp-config.php

にて

85行目くらいのを

if ( WP_DEBUG ) {
// debug.log ファイルに記録
define( 'WP_DEBUG_LOG', true );
// ブラウザ上に表示しない
define( 'WP_DEBUG_DISPLAY', false );
// ブラウザ上に表示しない
@ini_set( 'display_errors',0 );
}

と書き換えると

wp_content/debug.log ファイルにログ出力されるようになるらしいが、原因不明で、今回は見つけられなかったので、サイトにエラーコードを表示する形をとる上のコードにしている。

解決したあとは、元に戻す事

アクセス制限

例えば、リアルタイムで明らかにアクセスが急騰している場合は、一時的に強制的なアクセス制限をしてもよいかもしれません。

ただし、今アクセスできているから攻撃しているのか、アクセスできなくなったら攻撃を停止するが、またアクセス可能になれば再び訪れるのか、そのbotの動きは判断・断言できません。もちろん、後者である場合は、アクセス制限をしても意味がありません

今回できる提案としては、前者の、時間がすぎると攻撃をやめてくれると想定した場合で、以下の方法が考えられます。

  • A.プラグインを利用
  • B.手書きコードで対応
  • C.エックスサーバーから根こそぎ遮断する
A.プラグインを利用

プラグインの「WP Maintenance Mode」を利用することで、ページにアクセス制限をかける事ができます。ただし、ここに関してはやや疑問があります。

表向きはもちろんアクセスできませんが、私たち権限者はログインし、サイトを閲覧する事が可能です。

すなわち、入り口を変えれば入る事ができるという事になります。でしたら、もし、その経路からの侵入がある場合は阻止できなくなります。

上記はネットの記事のみの情報で確信が持てず、実際の検証ができないので、不安が残ります。ネット記事では、あくまで攻撃回避ではなく、サイトの更新の際の対応がメインになるものばかりでした。

実際、スマホで4G回線で検証したところ、プラグインを有効にしてもダッシュボードにアクセスする事ができます。

もしかすると、回避できる方法はあるのかもしれませんが、ざっくりは見当たりませんでした

B.手書きコードで対応

まず、maintenance.htmlというファイルを作り、FTPで、最上層の階層に放り込む

そして、以下のコードを

.htacceesに記載する

ErrorDocument 503 /maintenance.html

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} !=/maintenance.html
RewriteCond %{REMOTE_ADDR} !=126.80.118.111
RewriteCond %{REMOTE_ADDR} !=192.168.0.5
RewriteRule ^.*$ - [R=503,L]
</IfModule>

<IfModule mod_headers.c>
Header set Retry-After "Sun, 14 Jun 2009 6:00:00 GMT"
</IfModule>

補足

---RewriteCond %{REMOTE_ADDR} !=126.80.118.111

こちらは、アクセスを許可するIPアドレスで、このIPだけはサイトにアクセスできる事になります。許可されていないIP(スマホ4G回線検証)でアクセスしても、ダッシュボードは表示されませんでした。

---Header set Retry-After "Sun, 14 Jun 2009 6:00:00 GMT"

これは、終了予定時刻を、コンピューターに知らせるものだが、そこまで重要ではないので、なんとなくの終了時刻をいれておきましょう。

こちらのコードでは、サイト閲覧者に503コードを見せるものになりますが、503エラーを出す事で一時的な接続不良として検索エンジンにアピールする事ができます

もし、他のステータスコードを返してしまうと、このページには何もない(真っ白)としてインデックスされるので、かなりSEOに悪影響になります

C.エックスサーバーから根こそぎ遮断する

エックスサーバーのアクセス制限設定にて、すべてをONにするとサイトが完全にアクセスできなくなります。ボタンひとつなので、元に戻す事も一番簡単です。

この際、エラーコードは500になるのですが、このエラーコードはSEOにとってかなり良くない事とされています

ウェブサイト全体を無効にすることは可能です。ただし、非常に短い期間(長くても 2~3 日)のみに適用できる最終手段です。それ以上の期間になると、適切にサイトを実装した場合でも、ウェブサイトの検索に甚大な影響が及びます
引用:https://developers.google.com/search/docs/advanced/crawling/pause-online-business

との事です。

現在の想定トラブルでは、悪いアクセスは短時間のものでしたので、最悪この方法も取る事はできるのではないかと思いました。

サイトが真っ白でインデックスされるのも怖いですが、攻撃されたまま放置して、悪いサイトと認識インデックスされるのも相応に良くない結果となります。さらに、放置する事でサイトの修復作業にも時間を要します。

アクセス制限(まとめ)

今回、紹介した対応方法は一長一短です。簡単なのはプラグインを使う方法ですが、ややセキュリティに不安が残ります。

B.が一番良さそうですが、これは私が完全に着席している時じゃないと対応できないので、緊急対応性には欠けるかと思います。

即座に、鈴木様でも簡単に対応できるのは、A.かC.になります。

ただ、どれもリスクがあるものになるので、サイトに攻撃され続けるリスクとインデックスを失う可能性のリスクのどっちをとるかを少し考えておく必要があると思います。

もちろん、これは冒頭でお話ししたように、攻撃が一時的なものである必要があり、オープンの出待ちをされている状況では一切効果は見込めません

D.作業時

作業時にもトラブルは起こりますが、基本的には何かをやったからトラブルは起こります。ですので、元に戻せば理論上は必ず戻ります

作業前に元データを残す(バックアップする)のはルーティンワークなので、もしエラーが出てても対象作業ファイルだけを差し替えれば元に戻ります。

最悪、元のデータを取り忘れたとしても、バックアップからファイルを抽出すれば対応も可能です。

E.テーマトラブル

テーマでトラブルが起こっていそうであれば、

・管理画面にて、デフォルトテーマ(twenty系)に変更して、どうか確認します。

管理画面に入れない場合は、

・FTPにて、有効にしているテーマの名前をプラグイン同様に名前を変えると無効化され、デフォルトが当てられますので、その確認で、トラブル原因の切り分けができると思います。

F.データーベース破損

データーベースが破損したりすることがあるらしいのですが、私にその経験はありませんので、具体的に何をすればそうなるのかは不明ですが、サイト侵害などもその原因のひとつにあたるとのことです。

WordPress本体のプログラム、プラグインの脆弱性、管理者が利用する端末のマルウェア感染によっても、管理画面への不正アクセスは引き起こされる可能性があるようです。

データベースが破損した場合は、phpMyAdminにて、「テーブルの修復」というのが行えますので、そちらをまずやってみるのもひとつです。

無理な場合は、バックアップとデータベースを差し替えれば大丈夫です。

提案

それでは、今回の検証を踏まえた上で、以下の提案をしたいと思っております。

データファイルの保存

バックアップデータに関しては、保存しておくに越した事はありません。

ですので、HDD保存と、クラウドサービス保存の併用が望ましいと思います。HDDに関しては、過去なんども私は破損しています。

クラウドサービスに関しては、無料のものでも構いませんが、現時点でFXメガバンクだけで6GBになっていますので、それを何個も保管していき容量もかなりのものになりそうですので、有料クラスのサービスを利用する必要が出てくると思っております。

そちらのクラウド保管サービス契約に関しては、鈴木様の方でご用意いただければと思っております。

容量を抑える努力をする

サイトの容量はできるだけ抑えるように、私も含めて努力していった方が良いかと思います。

特に画像のアップロードは容量が大きくなりがちなので、訂正なサイズにした上で、さらに圧縮した状態で、EWWW Image Optimizerのプラグインを当てるような感じが理想だと思います。

バックアップの容量も、今でも6GBとかなり大きいので、あまり良い傾向ではないと思います。

場合によっては、現在のファイルも画像を精査し、リサイズしていくのも一つかと思いますが、なかなか難しいところもありますので、今後の制作に関しては意識してもいいかもしれません。

圧縮方法は、
https://designerbrg.com/image_optim/
の記事に記載しております。

ちなみに、私がしている作業に関しては、基本的に上記の圧縮状態で作業をしていますが、特にサムネイルなどはそのような対応をしていなかったので、今後は心掛けようと思います。

エラー番号を控える

エラー番号を共有しましょう。

実は、前回のトラブル時、私のPCにはエラー番号が表示されていませんでした。でも、鈴木様はエラー番号をご存知だったようでしたので、そのあたりも共有していければと思います。

もちろん、前回、私のPCにエラー番号が表示されていない事は、鈴木様はご存知なかったと思いますが。(鈴木様とエックスサーバーのメールで気づきました)

検討案件

いろいろ実際の作業も見えてきましたので、今一度保守の契約内容を見直しても良いと思っています。

バックアップの頻度であったりや、誰が、どの範囲で行うかなど。

また、エックスサーバーのアカウント情報を私に公開するかどうかでも、私にできる事、鈴木様にしかできない事が分かれてしまいます。

ですので、一度鈴木様の望む、保守契約の形・範囲を、お教えいただければと思いました。

また、今回の内容を、1から説明する形で電話連絡させてもらっても問題ありませんので、解説が必要でしたら、そのようにお伝えください。

それでは、どうぞ、よろしくお願い致します。

Copyright© デザイナーブリッジ , 2022 All Rights Reserved.