いや〜、１週間くらい大変でした。
まさかプラグイン一つ入れただけでこんなにも苦労するとは…
今回は特殊な環境でWordPressをインストールした方に向けて、自分への戒めと注意喚起をかねて話を整理してみました。
SQLiteユーザーの方はご注意下さい…！
何があったのか
結論から言うと、高速化系のプラグインをインストールして設定画面を開き設定を保存したら、WordPress内の記事データだけマルっと削除されちゃいました。
しかし、検索エンジンのキャッシュとわずかな古い記事データのバックアップのおかげで、すべてとまでは行きませんでしたが9割ほど元通りに。
といった感じです。
詳しい経緯を書くと…
当時の環境について
サーバーは「さくらのレンタルサーバー」を使用しています。
しかし、サーバー代をケチりたかった私は、普通ではWordPressを導入できない一番安いプランに入っていたのです。
最初、ブログを持っていなかった私はポートフォリオのWebページ(https://maesuke.com/)だけ置いておこうと考え、もっと前に契約していたFC2レンタルサーバーから独自ドメイン含めさくらレンタルサーバーに乗り換えました。
これで十分…と思っていたのですが、ブログも持ちたいな！と思ったので、その契約したサーバー内の/blog/ディレクトリにブログを置こうと思いました。
しかしデータベースが使えないプランだったので、WordPress自体サーバーに組み込めないじゃん… なにかいい方法はないかと調べていたら、SQLiteを用いて無理やりWordPressを導入してしまおう！！という情報を発見。
方法や仕組みについては詳しくは「WordPress SQLite」などでググって頂くといくつか記事が探せますが、要するにデータベースサーバーのかわりにデータベースファイルをサーバー上に作成し、そこに記事データを保管させる、といった仕組みです。
Accessなんか触ったことのある方はイメージできると思いますが、外部に.accdbファイルを作り、そのファイル内にあるテーブルをリンクして編集する、といったイメージですね。
WordPressのファイル構造とデータベースの場所について
細かくは説明しませんが、大まかには次の通り。
- wp-adminフォルダー ･･･ 管理画面に関係するフォルダー
- wp-contentフォルダー ･･･ プラグインやテーマに関係するフォルダー
- wp-includesフォルダー ･･･ WordPressシステムそのものに関係するフォルダー
- その他、管理ページや設定ファイル、ユーザー情報など
この中で今回のSQLiteデータベースファイルのある場所が、wp-content内のdatabaseフォルダーです。
これです！この/wp-content/database/.ht.sqliteファイルこそが、記事のデータベースファイルとなります。
これは通常のWordPressでは生成されないファイルで、SQLite独自の仕様となっているのです。
そのような環境下で、ある日とあるプラグインを導入した
WordPressって便利ですよね…
やりたいことが大体プラグインで叶っちゃいますし…
しかしそもそも、ただでさえ格安サーバーで処理能力の遅い状態なのにプラグインを入れまくるのも良くないですが、とある高速化プラグインをいくつか入れてしまいました。
それが、
- Autoptimize (コードを最適化して読み込み負荷を軽減)
- W3 TOTAL CACHE (データベースやページなどのキャッシュを生成)
というWordPressプラグインの中ではメジャーなものとなっています。
おそらくですが、今回記事データを削除してしまったのはW3 TOTAL CACHEである可能性が高いです。
”可能性が高い”という言い回しをしたのは、あくまでこのプラグインを設定した直後にページが表示されなくなったためであり、このプラグインの挙動が絶対的な原因とは言い難いためです。
なお、ググれば分かる通りプラグインそのものはとても優秀なもので多くの人に使われていますが、相性や環境ってのがありますよね…
設定した内容とは
ここではもうざっくり書きますが、
Autoptimizeでは
- CSSコードを最適化
- HTMLコードを最適化
にチェックを入れて保存。
次にW3 TOTAL CACHEにて、
- Page CacheをEnableに
- Database CacheをEnableに
それぞれチェックを入れ保存しました。
ここで、です。
保存後に他ページに遷移しようとすると、データベース接続確立エラーが。
ん？どういうことだ？
しかも管理画面だけじゃなく、ブログトップページも非表示に。
これヤバいやつなのでは…と思い、ググっても大した情報を得られず。
ファイル構造を確認したところ、恐るべき事実を目の当たりに…！
SQLiteファイルが削除されていた。
何が起こったのかがさっぱりわからなかったが、あるはずのSQLiteファイル、つまり記事データがまるっと無くなっているのだ。
慌ててBackWPupプラグインで自動バックアップしたデータを確認した。
バックアップなら週一で実行されているし、最悪でも先週分までリカバリーできるだろう… そう考えていました。
しかしバックアップファイル内にも記事データだけがない… そんなバカな。
なんとBackWPupはSQLite環境を想定しておらず、設定ファイルくらいしかバックアップされていませんでした。
えぇ… バックアップされていないまま記事データ削除って、これ完全に詰んだのでは。
それなら手動でFTPソフトを使ってローカルにコピーでもしておけばよかった…
痛い勉強代でした。
サーバーを強化し、かつある程度データ復旧することができた
絶望している中、原因も分かったことだしとりあえず再発防止ということで、SQLite環境から抜け出すべくデータベースに対応したプランを契約し、そこで新しくブログを立て直すことにしました。(今のこのブログです)
ただ、今まで使っていた格安プランも既に年間料金を払ったばかりだし、SEO的にも消すのもあまり良くないかな、ということで、ポートフォリオとなるサイト(https://maesuke.com/)だけは旧サーバーに残したままにしました。
サーバー代は多少かさみますが、こうすることによって
- SQLite環境WordPressから通常のWordPressとなり、今回のようなデータ消失は起こらない
- バックアップがしっかりとれる
- サーバーのプランを上げた＝スペック向上したためアクセス速度も向上
といったメリットが。
最初からケチらずこうすればよかったぜ…
消えたはずの記事はどうやって復旧したの？
一から記事を書き直すことも考えましたが、「これInternet Archiveとか検索エンジンのキャッシュに残っているのでは？」とふと考え付き、早速確認してみました。
するとGoogle、Yahoo!、Bingの各検索サイトのキャッシュにある程度記事データが残っていたのです！
これはめちゃくちゃ嬉しかったですね。
これさえあれば多少手間ながらもコピペでなんとかなる…！ということで、いそいそ作業を行って9割ほど今のブログの記事に入れ込むことができました。
また、去年の6月時点のWordPressファイルがローカルに多少残っていて、その中から記事データを取り出すこともできました。(初期の頃のほんの数記事だけでしたが)
ただ、2〜3記事だけどこにも残っていなかったので、それはもう諦めるしかありません。
でもこれだけ戻ったら御の字です。ありがたやありがたや〜
まとめ
というわけで、問題発生から復旧まで約4日間かけました。
ここで学んだこと、皆さんにも注意していただきたいのは、
- サーバー代をケチってSQLiteでWordPressを構築しないこと(正式にWordPressに対応したプランに入ること)
- バックアップするときは記事データも含めてしっかり保存されているか確認すること
これらに尽きます。
SQLite仕様のWordPressも、アクセスを特に見込んでいなかったりプラグインをたくさん入れるつもりも無いなら悪くないとは思いますが、非公式の方法なのであまりオススメはできません。
データが消えたのも、サーバーのせいでもWordPressのせいでもプラグインのせいでもありません。自分の選択ミスでした。
同じような状況の方がいらっしゃいましたら、是非十分ご注意下さい。
