【寄稿】MySQLのデータベースを誤削除して壊れたWordPressサイトをバックアップ無しで復旧するまでの方法論

mysql

こんにちは、ウキクです!

さて、今日は特別編です。以前、31eyesが崩壊の危機に陥りました。一言で言えば、私の凡ミスと管理体制の甘さが原因でした。そこで、助けていただいた際の話で、寄稿というかたちで投稿していただきました。

かなり上級者向けの記事です。同じような状況な方の助けになれば、私も著者も嬉しいです!以下、本編です。

 

目次

本編

以前、当31eyes.netはMySQLデータベースの誤削除により「サイト崩壊」の悲劇に見舞われました。

上の記事にある「復旧にあたっての協力者」である私が、今回記事を寄稿という形で筆を取っております。以前管理人ウキク氏が書いている通り、サイト崩壊時は

  • MySQLのデータベースを間違って削除した。
  • データベースのバックアップが取得出来ていなかった。

という状態にありました。

システム的な観点で一般的に言って、当時の31eyes.netの状態は復旧不可能な状態でした。

しかし、あの手この手で策を弄し、悲劇的な状態からなんとか6割弱の記事を復旧させました。悲しいことですが、今後「同じ悲劇」に見舞われる人は恐らく他にも出てくることでしょう。

そういった方々のために復旧までの方法論を記録しておきたく、記事の寄稿を申し出ました。寄稿の許可をくれた管理人ウキクさん、感謝です。

一万文字を超える長文になってしまいましたが、日本の何処かで泣いている誰かの助けになったなら嬉しいです。

 

前提事項

本記事内容の前提事項を先にまとめます。辛辣な内容だらけですが、大事なことなので最初に書いておきます

実践にはコンピューターの知識が必要

記事の内容に沿って復旧を実践するためには、コンピューター関連の知識が一定量必要になります。

自身のサイトに合うように応用したり、考えて補完しなければならない情報が多く、いわゆる「コピー&ペースト」的な発想でなぞれる内容にはなっていません。

かなり辛辣な言い方ですが、「バックアップ無しでMySQLのデータベースを誤削除してしまう」レベルの理解度だと恐らく内容について来れないと予想します。

協力者が必要です。

自分が泣きつける範囲で一番のコンピューターオタクを捕まえて下さい。

他人に頼ることは悪いことではありません。適材適所です。出来ないことはアウトソースしましょう。

自分がそうだからわかるのですが、いわゆる「ギーク」「コンピューターマニア」といわれる人々は往々にして、「世話焼き」で「おせっかい焼き」だったりします。頼ると力を発揮してくれることが多いと思いますよ。

 

本当にDBバックアップが残って無いか、死ぬほど探すこと。

データベースのバックアップがあるならば、バックアップを使って復旧する方法が安心・安全・最速です。

最新断面のバックアップが残っていればもちろんベストですが、古い日付のバックアップだけでも残っていればそこからの更新分を手動で修正していけば良いわけです。

データベースを誤削除してしまった皆様は、「よくわからない」ままにデータベースを削除してしまったことと思います。
であれば、「よくわからないうちにバックアップを取っていた」ということもあるかもしれません。

  • 他のサイトの情報を真似て知らずしらずのうちに設定していた。
  • オールインワン的なプラグインに気付かないうちに含まれていた。

などのラッキーがあるかもしれ無いので、事実確認をするまで可能性を捨てないで下さい。

データベースのバックアップが残っていないかどうかについても、コンピューターに強い人に協力を要請して探すことを勧めます。

 

筆者の知識も不完全。丸々鵜呑みにするべからず。

私の本職はシステムエンジニアですが、WEB関連の知識は正直言って「薄っぺら」です。

システムエンジニアの世界では同じコンピューター技術の中でも色々とエリアが別れており、「サーバインフラ」と呼ばれるような領域が私の専門です(UNIXを得意としています)。

本職では使わないため、Webの知識もWordPressの知識も「個人的に軽くお勉強しました」程度の中途半端なレベルです。例えて言うなら、「ヘビーメタルが好きなミュージシャンがジャズを演奏する」程度のミスマッチ感があるわけです。

偏った意見や遠回りなやり方が含まれている可能性があるので、実践の際には検証と事実確認を取りながら進めて下さい。

 

WordPressサイトをバックアップ無しで復旧するまでの方法論

前置きがかなり長くなりましたが、復旧までの道のりを順を追って見ていきましょう。文量がとても多いですが、状況に応じた最適解を見つけるために根気よく追いかけてみて下さい。

 

キャッシュされた情報から記事データを復旧する

データベースのバックアップが無い以上、どこか他の場所からデータを復旧する道筋が無いかを探す必要があります。

WordPressブログに限らずですが、Webサイトにおいてはコンテンツこそが命です。

時間をかけて紡ぎ出した文章こそが一番の価値を持っており、復旧において第一優先です。HTMLタグでのマークアップやリンク構造などの情報を含めたハイパーテキストが復旧できればなお良いでしょう。

ホームページ・ビルダーやAdobe Dreamweaver、SERIUS等のウェブオーサリングツールを使用して静的なWEBサイトを運営している場合は、レンタルサーバにアップロードしているファイルそのものがコンテンツです。ファイルレベルでバックアップして、ファイルレベルで戻せばコンテンツが元に戻ります。

しかしWordPressの場合、コンテンツの大事な部分は基本的にMySQLのデータベースの中にあると思って下さい。

もちろん、画像ファイルなどはファイルとしてWebサーバ上に保管されていますし、装飾や体裁の部分を司るスタイルシートはCSSファイルとしてテーマ用のディレクトリの中にファイルとして保管されているでしょう。

誤解を恐れずにざっくり言いますが、上述のような一部のものを除いて、大事なデータはほぼ全てデータベースの中に入っています。

データベースをドロップ(削除)したということは即ち、一番大事なデータを捨てたことに等しいのだと心得て下さい。

この状態から復旧するためには、かなりイレギュラーな方法でデータをサルベージしていくしかありません。

その際にサルベージ元として活用出来るのが、「キャッシュされた情報」です。

「キャッシュ」とは本来、サーバやシステムへの負荷を軽減するために生み出された考え方です。

本来、WordPressのPHPプログラムとMySQLのデータベースを使用して動的に生成される情報を、「頻繁にアクセスされる情報は静的に保持しておくことで負荷を減らしましょう」というような話がキャッシュの本来の役割です。

  • 本来データベースに入っているはずの情報が、負荷軽減のために静的にキャッシュされている場合がある
  • 裏を返せば、静的にキャッシュされている情報からデータベースに入っていた情報を引っこ抜けるはず

というのが今回のサルベージの考え方の概要です。

サルベージに使用するキャッシュは、すぺてのページをなるべく網羅した形でキャッシュされていることがベストです。
その前提で、可能性を模索していきましょう。

 

キャッシュ系プラグインがサーバローカルにキャッシュを残している可能性

WordPressを運用していれば「応答速度を高速化したいな」といった事を一度は考える人が少なく無いはずです。「高速化したい」という欲求に対する答えとして、キャッシュ系のプラグインが良く利用されています。

「W3 Total Cache」といったプラグインを使われいる方が多いことでしょう。詳細は良くわかっていなかったとしても、他サイトの見よう見まねで「ページ・キャッシュ」の機能を有効化していたりしませんか?

「ページ・キャッシュ」を有効化していて、かつ正しく機能している場合、サーバ上にhtmlの形でキャッシュされた情報が残っている可能性が高いです。

例えば、「W3 Total Cache」のページ・キャッシュを有効化していて、「Page cache method」に「Disk: Enhanced」を指定していると仮定します。(「よくわからずにググって設定した場合、きっとこの設定になるだろうな」という仮説に基づいています。)

その場合、「wp-content/cache/page_enhanced/」の配下を探して見て下さい。階層を少し下ったあたりに、「_indexほにゃらら」的なファイルが作られていませんか?

このファイルがある場合、ページ・キャッシュが取れていると考えてOKです。この場合、これらのページ・キャッシュを元にサルベージする方法で高い網羅度が期待出来ます。

では31eyes.netの場合どうだったかというと、残念ながらページ・キャッシュのプラグインは使用していませんでした。余談ですが、キャッシュ系プラグインを導入して設定していてもレンタルサーバの制約で正しく動作しないパターンがあります。

「W3 Total Cache」を初めてとしたキャッシュ系プラグインのページ・キャッシュが動作するための大前提として、Webサーバのリライト機能を使用していることが多いです。

多くの場合、ApacheをWebサーバに使っているでしょうから、Apacheのmod_rewriteモジュールが使用できることが動作要件として必要です。

レンタルサーバ事情は詳しく無いですが、レンタルサーバのなかにはmod_rewriteを使用できないパターンがたまにあるようです。

「正しく設定している=正しく機能している」では残念ながら無いので、キャッシュされたページのファイルが存在していることの事実確認を持って判断するようにして下さい。

 

CloudFlare等のCDNにキャッシュされている可能性

「応答速度を高速化したい」という欲求に対する他の策としてCloudFlare等の無料CDNを使用している人も多いと思います。CloudFlareにはAlways Onlineという機能があリます。

これはサイトがオフラインになった場合に自動的にキャッシュされた情報を返す機能です。このCDNのキャッシュも利用できる可能性があります。

結論からいうと31eyes.netではレンタルサーバのネームサーバー関連の制約でCDNを使えていなかったので、この方法論は早い段階で選択肢から外れました。

キャッシュの保持期間の設定によってはあまり長い期間キャッシュが保持されないかもしれないので、この方法論に現実性があったかどうかは未検証です。ですが、もしキャッシュが長期保持されるのであれば、「wget -r」などを利用してトップページから再帰的に根こそぎhtmlデータを引っこ抜いてこれるかもしれません。

wget -r -linf -R jpg,png,gif --wait 5 --random-wait  http://www.example.com/

といったような形ですね。

 

オフラインブログエディタを使用している人はPCローカルにキャッシュがあるかも

他のキャッシュを使う手法と異なりますが、オフラインで使えるブログエディタの中には記事データの写しをPCローカル上に持っている可能性があります。

あまり知識がないので細かいことを書けなくて残念ですが、ブログエディタ上にデータが残っている場合もしかすると復旧が楽かもしれません。

 

【奥の手】Googleキャッシュを利用する

他のキャッシュと違って負荷軽減を元の目的としたものではありませんが、Googleはサイトをクロールした際に、ページ内容をキャッシュとしてGoogle側に保持します。

普段からGoogleキャッシュを積極的に活用している人はあまり多く無いと思いますが、このGoogleキャッシュも復旧のための元データとして選択肢の一つです。

Googleキャッシュはサイト内の全てのページを網羅しているわけでは無い点が欠点です。細かいルールやカラクリは明らかにしていないと思いますが、キャッシュされないページもあります。

(検証していないですが)恐らくnoindex指定してるページなどはキャッシュされ無いでしょうし、Googleの検索エンジンからみて「価値が低い」と判断されたページもキャッシュされにくい傾向を感じます。

「サルベージに使用するキャッシュは、すぺてのページをなるべく網羅した形でキャッシュされていることがベスト」と前述しましたが、Googleキャッシュは網羅度の観点では高くありません。

網羅度が高くない代わりに、「他のキャッシュは全部なかったけどGoogleキャッシュはあった」というパターンは多いはずです。

 

【注意点】Googleキャッシュは日数が経つと消えるので時間との勝負

Googleキャッシュは永続的には保存されません。

具体的な保存期間や保存ポリシーが明文化されたものは恐らくありませんが、保存される期間は「削除されたURLに再びクローラーが訪れるタイミング」に左右されると言われています。

メンテナンスや障害等でサイトが一時的にオフライン状態になることはそう珍しい話では無いので、「クローラーが再訪した際にページにアクセスできなかったら即削除」とは恐らくならないでしょう。

しかし放っておくといつかは消えてしまいますし、いつまで残っているのかの明確な目安もありませんので、「Googleキャッシュからサルベージする」と選択したならばなるべく早く拾い集める必用があります

 

Googleキャッシュから記事データを拾い集める

では、Googleキャッシュを使用して記事データを拾い集める時の方法論を順を追って見ていきましょう。

 

Twitterにパブリサイズした履歴から記事URLを取得

サイトマップから各記事のURL一覧を持ってこれればよかったのですが、残念ながらサイトマップ自体がWordPressのプラグインを使用してデータベースを参照して動的に生成される仕組みになっていたため、データベース破損時にサイトマップ自体が機能しませんでした。

※前述の通り、サイトが壊れてからクローラーが訪れるまでの間が勝負でしたので、サイトマップやRSS Feedがぶっ壊れてくれたことは結果的に延命に繋がったのかもしれないと考察しています。

31eyes.netの場合は、

  • 記事投稿時にtwitterに自動でパブリサイズする設定にしていた
  • 過去記事を定期的にtwitterにポストするプラグインを入れていた

とのことだったので、twitterの過去ツイートのデータを元に記事URLのリストを作りました。自身のtwitter過去ツイートのデータは、公式にtwitterのサイトよりダウンロード可能です。

ダウンロードした過去ツイートのzipファイルの中に、tweets.csvというファイルがありますのでこれを使用します。tweets.csvは文字コードがutf8でエンコードされているため、Excelで処理する場合はshift-jisに直してから開いて下さい。

csvの中にexpanded_urlsという項目があり、各ツイート内に存在したリンクのURLが格納されています。

このURLの中から自サイトのURLをフィルターし、並び替えと重複削除をすることで記事のURLを取り出す事が出来ました。

ブログ運営開始後に途中でパーマリンク設定の変更を行ったのか記事のスラッグを設定し直したのか一部重複コンテンツが出ましたが、リストの時点の網羅度は100%にかなり近い数字になりました。

固定ページなどパブリサイズされていなかったページはリストの段階でロストしましたが、重要度が低いと判断し割り切りました。

URLリストを作る元データは「どうすれば網羅度がもっとも高くなるか」を指針に適したものを選択して下さい。アクセス解析の履歴なども、網羅度が高いソースとなるでしょう。

元ネタからURLリストを作る部分はテキスト処理のセンス次第です。

基本的にはごく簡単な正規表現くらいのレベルで出来るはずです。grep,sed,sort,uniq等の古典的なUNIXコマンドでやっても良いですし、Excelでも十分処理できます。簡単なプログラムを書いても良いです。

前述の通り「時間との勝負」なので、スピードが重要事項です。

やり方の美しさとか再利用性とか可読性とかはこの場においては価値が低いので、自分の得意な方法をうまく組み合わせてサクっと終わらせて下さい。

 

技術的に自信のない人は、まず愚直に手動で集めること

記事URLのリストが出来たら、記事URLを元にGoogleキャッシュを取ってこなければなりません。

機械的に拾い集める事ができればもちろん楽で速いのですが、コンピューターの知識と技術が必用なので、すぐに用立てられるとは限りません。一方で時間と手間はかかりますが、「手動で1件・1件取得」する方法は誰にでも簡単に出来ます

具体的には、Googleの検索窓で

cache:http://31eyes.net/blog2/

のような形で検索すれば、キャッシュされたページが開きます。ブラウザの「規定の検索エンジン」をGoogleにしている場合は、アドレスバーに直接入力してもアクセス出来ます。

ページが開いたらCTRL+Sで保存すればPCローカルにダウンロードされます。

以降の章で一括ダウンロードの手法は紹介していきますが、「ちょっと自信ないな」という方は、まずは愚直に手動でダウンロードして下さい。

31eyes.netを復旧した際にも、私が機械的な復旧対応をすすめる裏で、管理人には手動でのダウンロードを進めて貰いました。

こういった復旧は私も初めてだったので、復旧を開始した段階では一括で取得できる保証がどこに有りませんでした。
そのため「時間と手間はかかっても出来ることから確実に」という考えに基いて、2つの復旧アプローチを並行して進めたわけです。

結果的に、手動でダウンロードしてもらったデータは使用しませんでしたが、必用なステップだったと考えています。

 

記事URLからGoogleキャッシュURLを生成

では、機械的に一括ダウンロードしていく手法を見ていきましょう。

機械的に一括でダウンロードするためには、GoogleキャッシュのページURLを知る必用があります。
GoogleキャッシュのページURLは元の記事URLから機械的に導き出すことが出来ます。

具体的には以下の通りです。

http://webcache.googleusercontent.com/search?site=&source=hp&q=cache%3A[URLエンコードした元の記事URL]

URLエンコードはperlかphpかなにかでワンライナーで処理してしまうのが速いでしょう。

例えばphpこういった形ですね。

php -r 'echo urlencode($argv[1]);' http://31eyes.net/blog2/

perlなら多分こうでしょうか(未検証)。

perl -MURI::Escape -e 'print uri_escape($ARGV[0]);' http://31eyes.net/blog2/

日本語URLを含まない場合、基本的にコロンとスラッシュだけエスケープ出来れば良いので、エディタで愚直に置換しても良いですね。

コロンは%3A、スラッシュは%2Fです。

入力したテキストをURLエンコードしてくれるようなWEBのサービスもあるので、そういったものを活用してもOKです。

 

Googleキャッシュを一括ダウンロード

GoogleキャッシュのページURLを用意できたら、HTMLファイルを一気に持ってきましょう。

iriaとかirvineみたいないわゆるダウンローダーを使ってもおそらくダウンロードできると思います。(例えが古くてすいません)

私はwgetを使って、

wget "[GoogleキャッシュのURL]" -O [ファイル名]

というような形で一括でダウンロードしました。

バッドノウハウですが、–user-agentオプションでUAを変更しておかないとおそらく「403 Forbidden」エラーを喰らいます。

また、GoogleからBotだと思われないように、あまり大量に一気にダウンロードしないほうが良いでしょう。「Botだ」と判定されるとCaptcha入力を求められることになり、バッチ的に処理することはできなくなります。
(正確には、今の時代なら出来ないことは無いでしょう。Captchaを解除するようなサービスが今は存在しますが、私はこれを明確に「悪だ」とみなしていますので、深く言及はしません。)

ファイル名はそれぞれの自身のサイトのパーマリンク構造を考慮しながら、一意になるように適切に選択して下さい。

大概の場合、post-idかpostnameをパーマリンク構造に入れている人が多いと思うので、そのあたりを使うと良いでしょう。

私は以下のような形で関数を作って実行しました。(Debian GNU Linux上のkshとbashで動作を確認。)


function gcachewget {
  urlEnc=`php -r 'echo urlencode($argv[1]);' $1`
  fileName=`echo $1| awk -F'/' '{print $(NF-1);}'`.html
  wget "http://webcache.googleusercontent.com/search?site=&source=hp&q=cache%3A${urlEnc}" --user-agent="Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" -O ${fileName}
}

gcachewget http://31eyes.net/blog2/

取得したhtmlからのスクレイピング

この辺りから難易度がちょっと上がってきますが、もう一息頑張りましょう。

さて、HTMLの形でデータが取得出来たら今度は「Wordpressのデータベースにどうやって書き戻すか」を考えなくてはいけません。

理屈の上から言えば、取得したhtmlをブラウザで開いてプレーンテキストの情報を愚直にコピー&ペーストして手動で記事を投入して行っても構いません。ですが、これは想像以上に骨の折れる作業です。

見出しをつけたり文字を装飾したりリンクを貼ったり…一記事だけでもやってみればわかりますが、泣きそうになると思います。

HTMLタグ付きで、必用な情報を機械的に引っ張ってこれると、復旧までのスピードがグッと上がります。そのためには「取得したHTMLから欲しい情報をピンポイントで引っ張り出す」作業が必用になります。

この作業を「スクレイピング」と呼びます。

この「スクレイピング」と呼ばれる作業を目でみて手作業でやるのはかなり大変です。ただ、プレーンテキストから作り直すよりかはずっと現実的なので、ここから後ろの内容についていけそうにない場合は、

  • 1ページずつhtmlをエディタで開く
  • 必用な部分を探し、いらない部分を削る

といった形で、HTMLソースの形でWordPress投稿画面のテキストモードのところに投入していくのが良いでしょう。

 

スクレイピングに有用な技術

スクレイピングを機械的に行うためには、基本的にプログラムやスクリプトを書いて処理して行くことになりますがスクレイピングを楽に実施するためのツールが世の中には存在します。

私はpythonでスクレイピング用のスクリプトを書いたのですが、「Beautiful Soup」というスクレイピングのためのライブラリを活用させていただきました。

python向けにも他に色々なライブラリがありますし、python以外のプログラミング言語でもスクレイピング用のライブラリが存在します。

私の場合たまたま昔に「Beautiful Soup」を使ったことがあったので「慣れ」の問題で選択しました。なので「このライブラリが特別おすすめ!」という訳ではありません。

サッと調べ直した範囲では、今だと「lxml」というライブラリの方が使いやすそうには感じます。

スクレイピングであまりこったことをやりだすと時間が掛かるので、「正規表現を使って抽出したり置換したりしたほうが速いな」と感じた部分は正規表現を使用して処理しました。

 

 

BeautifulSoup等での要素の抽出

使用してWordPressのテーマなどによって出力されるHTMLの形を変わると思いますので、考え方や方法論のみ整理します。

例えば、titleタグが必ず記事タイトルになるのであれば、titleタグに囲まれた部分だけを引っばって来れれば記事タイトルを機械的に抽出出来ます。

timeタグから投稿日を持ってこれたとすれば、ここから投稿日を機械的に取り出せます。以下はイメージ伝えるためのただのサンプルコードですが、こういった形で必用な情報を取得していきましょう。


#!/usr/bin/python
# coding: UTF-8
from BeautifulSoup import BeautifulSoup

#ファイルリスト読み込み
listf = open('./list.txt')
line = listf.readline()

while line:
    f = open(line.replace('\n',''))
    data1 = f.read()
    f.close()

    soup = BeautifulSoup(data1)
    published = soup.find("time").string
    title = soup.find("title").string

    print published + u',' + title

    line = listf.readline()

listf.close()

正規表現でのアプローチ

私の場合は記事本文の内容を取り出す部分は、正規表現を使用してアプローチしました。

  • 記事本文の中身はどこから始まるか => ファイルの頭から本文始まりまでを消せば良い。
  • どこで終わるか => 本文終わり以降を全て消せば良い
  • 始まりと終わりの間に、自動挿入されたような不要箇所は無いか => 残る不要箇所を消せば良い

といった流れで考えると良いでしょう。

31eyes.netの場合は、以下の整理になりました。

■始まり(ここより前は不要)

<div class="entry-content">

■終わり(ここから後ろは不要)

<div class="sharedaddy sd-sharing-enabled">

■間の不要部分
目次用プラグイン(ToC+)が挿入した目次部分

これらにマッチするようにpythonの正規表現でパターンマッチさせると以下のような形になりました。

rpatt1 = re.compile(r".*<div class=\"entry-content\">", re.MULTILINE | re.DOTALL)
rpatt2 = re.compile(r"<div class=\"sharedaddy sd-sharing-enabled\">.*", re.MULTILINE | re.DOTALL)
rpatt3 = re.compile(r"<div id=\"toc_container\" class=\"no_bullets\"><p class=\"toc_title\">目次</p>.*</li></ul></div>\n<h" , re.MULTILINE | re.DOTALL)

data1の中に1ページ分のhtmlソースの全量が入っているとすれば、以下のような形で置換を掛けることで本文データを取り出せました。

res1 = rpatt1.sub( "" ,data1)
res2 = rpatt2.sub( "" ,res1)
content = rpatt3.sub( "<h" ,res2)

スクレイプした情報をWordPressに戻す

本文データやメタ情報をHTMLから取り出せたら、仕上げの作業として今度はそれをWordPressに戻していく必用があります。
その際の方法論について見ていきましょう。

 

【前提】崩壊前と同じURLに戻すべし

SEO的な観点で考えて、元々ページが持っていたSEO的な力を元に戻したいですよね。Googleが言うところの「ページランク」というやつですかね。

そのためには、復旧時に「サイトが壊れる前と同じURLに戻すこと」に注意を払って下さい。Googleに「重複コンテンツだ」と判断されることを避ける狙いもあります。

一点補足すると、同じURLに戻したからといってページランクが必ず元に戻るということを私は保証できません。しかし、戻ることを期待することは出来るでしょう。

元のURLと同じURLに戻すための難易度は、正直なところパーマリンク構造次第です。

スラッグを使ってpostnameをパーマリンク設定に使っていた場合は比較的難易度が低いです。31eyes.netは幸いこのパターンでした。

post-idを使って使っている場合は、難易度がグっと上がります。本来、post-idは記事投稿時にWordpressによって自動で割り振られる数字のため、Wordpressの管理画面からは変更が効きません。

必然的に、データベースの中のデータをSQLで修正していくことが必須になります。プラグイン等でできると良いんですけどね。

多数の記事・多数のテーブルを修正することになるので、なかなかシビアな作業になるでしょう。大変ではありますが、やってできない作業では無いです。私は実施していないですが、十分に調査してバックアップをちゃんと取った上で挑めばたどり着けるゴールだと考えます。

検証していないため不確定事項ですが、理屈の上ではURLが変わっても301リダイレクト適切に使用してリダイレクトしてあげれば、元のページが持っていたページランクを転送できるようには思います。

301リダイレクトはブラックハットなSEOに使用されることもあるようなので、「301リダイレクトを多用していること」自体が検索エンジンからの評価を落とす一因にならないだろうかという懸念は感じます。

 

100記事・200記事くらいだったら「根性で手作業で投入する」ことを勧める

地味な単純作業にはなりますが、ここからはWordPressの管理画面で記事を個別投入する形を私は取りました。

投入用のSQLを生成して、データベースに投入することも考えました。しかし、複数のテーブルにまたがって複雑にデータを持っているため、正しい形でSQLを作る難易度が高いと判断しました。

記事量が多い場合は、SQL生成を視野にいれても良いと思います。

 

デッドリンクを確認して個別修正

前述した通り、Googleキャッシュを元データとした場合、網羅度が100%ではないため復旧できない記事が出てきます。そのため、ブログ内の他の記事に内部リンクを記事中で貼った際など、デッドリンクが発生する可能性があります。

WordPressにはデッドリンクを確認するプラグインがありますので、そういったものを使ってデッドリンクを探して個別修正しましょう。

 

今回の悲劇を受けての教訓

データベースバックアップファイル無しでのWordPressサイト復旧を通じて、学んだ教訓を最後にまとめておきます。

バックアップは死ぬほど大事で、リストア出来て初めて価値がある。

31eyes.netを復旧するために、色々なアイデアと技術を駆使して色々な部分を妥協しながら100記事ほどのデータをWordPressに投入するところまでで丸一晩・12時間くらいは掛かりました。

正直言って「二度はやりたくない」作業です。ゴールまでの道筋が見えるまでは特に精神的につらい。

ある意味「自分の持ち物」ではないサイトだったので落ち着いて考えることも出来ましたが、仮に自分のものだった時の精神状態はちょっと想像もしたくないですね。

下書きとして投稿するところまでを私が行い、管理人が最後に一記事一記事チェックしたり細かい修正をしたので、トータルではもっとたくさんの時間がかかっています。

これらは全て、データベースのバックアップがあれば防げた事態です。

また、「バックアップから確実に復旧できること」とそのやり方も押さえておくべきです。「バックアップ、取ってたつもりが取れてませんでした」では目も当てられないですよね。

 

一時的にサイトが死んでも、同じURLで復旧出来ればページランクも戻る模様

ここは感覚ベースの部分ですが、SEO観点でも壊れる前の水準に戻ったように感じました。管理人としてもそのように感じているようです。

ゼロリセットにならないのは精神的にも良いですね。

定量的な観点のデータを取っていれば自信を持って「ページランク戻ります」と言えたんですけどね。実験としては誰もやりたくない内容だと思うので、事後だけでももう少しデータを取っておけばよかったかもなと今考えると思います。

ちなみに今回サイトがオフラインになった期間は10日間ほどでした。

 

記事作成に集中できる環境を整えるべし

今回、技術の観点からサイト復旧劇について記事を書きましたが、ブロガーが一番時間をかけるべきことは「記事を書くこと」だと思っています。

記事の中でも書いたとおり、サイトの価値はコンテンツに宿るというのが私の持論です。コンピューター技術や仕組みの部分は道具であり、土台であるわけです。

WordPressの管理運営に余計な時間を取られずに済むように、自身の城の土台は固く丈夫になるように予め手を打っておきましょう。壊れた城の修復に時間をかけるのは虚しいですからね。

技術的に理解の追いつかないことを、無理して自力でやる必用はありません。例えば「WordPressのバックアップ・リストア」という観点で見ても、例えば有料のサービスを使用することでアウトソース出来ます。

軽く調べて見ましたが、例えば「VaultPress」とうサービスであれば最小で月5ドルから利用できるようです。自身のWordPressブログに月5ドルをペイできる価値を見いだせるのであれば、こういったサービスを利用することも視野にいれると良いでしょう。

この記事が気に入ったら
いいね ! しよう

  関連記事

no image

ブログを始めて良かったこと このブログについて 100記事目投稿に代えて

おはようございます、ウキクです。 さて、今まで何も考えずに記事を書いてきましたが、気付けば間もなく100記事目になろうとしています。 100記事目に何を書こうかなぁ、と思いつつもきっとうっかり普通に更新してしまいそうなの […]

31eyes

3月1日は31eyesブログの日ということにします。毎年秘密を暴露していきます。

こんばんは、ウキクです! 3月になりましたね。ブログを始めて1年が経とうとしています。正確には、1歳の誕生日(初投稿日)は3月5日です。 31歳の時に始めたものの、今年は33歳になってしまいます。そろそろあまりにも適当に […]

HTMLやCSSの知識がなくてもブログはできる。

こんばんは、ウキクです! ブログを初めて1年2ヶ月が経ちました。もうすぐ300記事目になります。1日1記事投稿の目標はなかなか果たせていませんが、ここまで継続できたことは自分でも褒めてあげたいと思います。 最近、ブログに […]

8月はブログのアクセス数が過去最大(2万PV)に まだまだですね

こんにちは、ウキクです! サッカー日本代表やってくれましたね!期待予想の2-0で勝利!本命予想の1-1が外れて良かったです。 さて、今日は先月(8月)にこのブログのアクセス数が過去最大になり、ほぼ2万PVでした。(正確に […]

感謝 気づけば200記事を超えていました。ブログ開始から10か月が経過。

こんにちは、ウキクです! 昨日はFacebookにて、このブログで紹介をした本の著者ご本人からコメントをいただきました。かなりびっくりしましたが、嬉しかったです。後ほど詳しくご紹介します。   目次1 もう直ぐ […]