サーバーが飛んでからの経緯と復旧までの事（に愚痴みたいなもの）
2019年10月28日未明から2019年11月11日まで、このブログに使っているサーバーが見事にぶっ飛んでくれました。復旧まで時間掛かりすぎなんですけど、その辺の経緯ややったユーザー側の対策やサポート状況についてまとめたいと思います（クッソ長いです）。
また復旧までに色々とやっています。ここではざっくり「何やった」と言った概要だけにとどめ、具体的な操作等の細かい部分は別途掘り下げます。
また使っているサーバーは「このブログについて」でも触れていますが CORESERVER（コアサーバー）
を使っています。
正直な所、レスポンスや対応なども鑑みて今回で見限った人もいると思います。私は価格、速度、慣れと移行に掛かる負荷で考えた結果、切り替える気にはなりませんでした。
と言う事でコアサーバーの障害報告「一部サーバーで発生しました共有ストレージ障害の対応状況につきまして」を踏まえつつ進めていきたいと思います。
この件に関連する記事はこちら。
他社で取得したドメインを「さくらのメールボックス」で使う場合のDNS設定方法
https://sakura86.com/domain-setting-for-sakura-mailbox/WordPressで作ったサイトのバックアップを取るべき場所と取る方法、リカバリする方法について（概論）
2019/10/28 サーバーが飛んだ
最初に気がついたのはGmailでPOP3エラーが頻発していた事でした。
このサーバーに設定したメールアドレスをメインで使っており、Gmailで取得する様にしていたのですが、急にエラーが出たのは何かおかしい訳です。
そして念のためにGoogle アナリティクスとアドセンスを確認すると1/3以下に急減していました。
これは何かサーバーのハード側がおかしいんじゃないかと思い、サポートページを確認するすると案の定、ストレージ障害との告知が出ています。
大体この手の復旧は経験から長くて半日と考えていたのですが、半日経っても復旧のアナウンスはありません。あったのはなぜか「ハード手配中なので待ってください」のアナウンスでした。
微妙な回答ですが「予備ハードも無いのはおかしいけど安いからしゃーないし、サーバー側のバックアップからリストアすれば終わりでしょ」と軽く考えていたんです。
2019/10/29 エラー頻発
かくして翌日には復旧したのか、アクセス出来る様になりました。だけどアクセスできるのはトップページだけ。
リンクをクリックすると500エラー、WordPressの管理画面も同様でトップページ以外表示されない有様です。
この時とっさに「検索結果から来た人にエラーって出すのまずくね？」と考えました。
（善し悪しは分かりませんが） アクセス時にエラー表示の対策として、静的ページを表示する様に設定を変えています。
ですがこのサーバー自体の管理画面も操作中に500エラーとなったり、いつも以上に応答速度が遅いことも気になります。ですがroot権限のないユーザーにできる事はありません。
次の日もおかしければサポートへ連絡をすることにしました。
またメールはある程度は受信できていた様なので特に何もしていません。ただ今後の対策としてメール用の別サーバーを考え始めています。
余談。障害報告の時系列からすると、現場は朝からRAID含めファイルシステムが完全におかしな事がわかり阿鼻叫喚だった頃でしょう。
データやパソコンが飛んだ時は本当に気が遠くなります。これはプライベートでも、仕事のどちらでも体験済です。特にRAIDが飛んでリビルドもこけた、ってもうね。
2019/10/31 サポートからの提案
翌日になっても復旧しないのでどうなっているのかサポートへ連絡しました。
その時の回答を一部引用します。
本ストレージハードウェア障害につきまして、最新バックアップデータより復旧を行っておりますが、一部整合性の取れていないファイルがあり確認と復旧に時間を要しております。
バックアップファイルをさかのぼり、現時点で弊社にて整合性が取れていると判断いたしましたデータが、2019年6月5日時点でのデータとなっております。
この説明で「RAID障害起こしたみたいだし、まともに戻らないな。とりあえず頑張ってくれそうだし、ファイル整合性取って貰えればいいや」と脳天気に考えています。
そして「最新バックアップが6月って何言ってるんだ？大丈夫か？」と一気に印象も悪くなっています。
というのも障害発生は10月末日です。バックアップ間隔が空きすぎで言葉は悪いですが怠慢すぎるだろう、と。
それでもこちらとしては頑張ってもらうしか無いので、
①整合性の取れていないデータのみ、2019年6月5日時点でのデータに復旧
②全MySQLデータを2019年6月5日時点のデータで復旧
※①で正常に復旧しない場合は②での対応となります
という提案にまず１、ダメなら２とお願いするしか出来ませんでした。
余談。この時点では時系列の詳細が明かされていません。なのでサポート体制や対応内容にとても悪い印象を持っています。
明かされた今では「しゃーない」と理解できるのですが、なぜ後から詳細を言い出すのでしょうか。先に分かっている事を説明されれば印象違うんですけどね。
こう言った「悪い事をなかなか言わない」のは日本企業の悪癖だと思っています。
209/11/1 復旧したと言われても
翌日には私が定期的に取っていた2109/10/17のDBのバックアップから「戻せました」との連絡がありました。
「あぁこれで元に戻ったろう」とブログへアクセスしても前日同様、リンクをクリックしても、WordPressの管理画面にアクセスしても500エラーで正常動作しません。
さらにサーバーの管理画面もまともに動かず、FTPでデータの回収もまともにできない状況です。
どうにもおかしい、という事でサポートページの各サーバーの動作状況を確認すると、負荷が異様に高くどうも不安定な状況でした。
「こりゃハード全体が壊れたな」と感じたので長期化を覚悟し、動かないので「復旧できてない」とサポートに問い合わせし続ける事にしました。
また10/17以降に行った記事の追加や更新データは飛んだのですが、googleの検索キャッシュから上手くサルベージできる事が分かり一安心したのもこの頃です。
そしてメールはある程度動作していても負荷が高いからか不安定なままです。
全てを1台のサーバーでまかなえるのがベストですが、安全性を考えると分散した方が良くなります。ですが分散させると管理の手間とコストが掛かります。
コストと管理の手間から一度諦めたのですが、安全性からメールだけ別サーバーにする事を再検討し始めました。
余談。 この時、サポートは全てが戻ったと説明していません。あくまでも戻ったのはデータベースのみです。サーバーが動いていて、データベースも正常動作していれば他は関係無いのです。
ホスティング会社の本来の仕事はハードの提供と安定動作で、ユーザーデータのバックアップやリカバリは本来の仕事じゃ無いんですから。
だたなぜかユーザーデータは無視してもデータベースだけは頑張ってリカバリしてくれるんですよね。不思議です。
2019/11/1～4 動きの無い週末
この頃はとにかくデータのバックアップやベリファイの為、ローカルへのダウンロードを試し続けています。
ですがアクセス出来ないわ、サーバーの管理画面も500エラーになるわ、FTP使える様に設定しても途中で切断されるわ、と相変わらずまともに動きません。
そして週末だからか、サポートからの応答もなくなりましたがエラーは出続けます。もうどうにもできない不安や苛立ちを抱えたまま週末へ突入しました。
何もできない週末だったからか、何も応答がなかったからか「最初から作り直す気持ちで行こう」「ネタにしよう」と割り切る事もできました。
それとこのタイミングでバックアップもとれ、サーバー追加やプランの変更も含めたコスト計算も行っています。
余談。障害報告の時系列やサポートの応答も無いので何もしていない様に感じますが、多分現場では状況把握と報告、復旧手順の確認や具体的な補償や対応方法を管理職レベルと会議し続けたのかなと想像しています。
でもリアクションはゼロ。ユーザーからすれば何もしてないと同意です。もう少し考えて欲しい所です。
さらに余談。親会社のGMO社長は週末に実施された駅伝についてノホホンとツイートしてたらしく、それが一部ユーザーの火に油を注いた様で。 なんともいやはや。
2019/11/5～10 再構築
そして週明け、まずコスト計算したら大して変わらなかった事からメール用のサーバーを新たに契約、設定変更をしました。
候補も無い事からとりあえず「さくらのメールサーバー」を選び、余計な手間をかけつつどうにか設定完了。メールサーバーの切替は無事完了しています。
そして「復旧した」元のサーバーの動作は安定し始めました。11/7に改めて「復旧済」と連絡がありましたが、WordPressではどうやってもエラーがでます。
何かがおかしい事は明らかな事と、11/11にハード移行するとの事から動作検証と復旧用に新たにサーバーを契約しました。
また契約したのはこれまでのCORE-Aではなく、CORE-miniの最低スペックのものです。
CORE-Aではオーバースペック感があった事と、コストも下がる事からです。特に夜間の応答速度が変わらないなら全く問題ありませんし。
とりあえず11/11にリカバリが終わる事になるので、そこにむけ復旧作業を行う事にしました。
ちなみにサポートに11/5に問い合わせた所、反応は11/7で担当者名の表示もない、テンプレ回答とかなり酷い状況となっていた事にも触れておきます。
余談。かなり盛大なトラブルです。問い合わせの量もとんでもない事になって対応しきれなかっただろうし、個人攻撃も電凸も盛大だったのでしょう。
こういった「無記名、テンプレ」なやり方もサポートする側として理解はできますが、ユーザーとしては全く納得できません。
トラブル時ほど「報・連・相」って大事だな、と自身の仕事にも反面教師の事例として役に立つ事になりました。
2019/11/11～12 復旧完了
検証環境でいろいろ試した所、11/12に復旧できたといってよい状態にする事ができました。
ここで検証を丁寧にやったお陰である程度WordPressの構造を理解する事もできたのは良かった点なのかもしれません。
Search Consoleでは盛大にエラーが出続けているのでまだ完全復旧ではないものの、無事再稼働しています。
そして11/11の夕方にはハード移行完了の連絡もありました。
移行完了して復旧したはずの元のサーバー、結局WordPressはおかしいままです。なので検証環境を本番とし、そのまま使う事としました。
引っ越しが面倒なのと、盛大にケチ付いた物をまた使うのもなんかイヤですし。
おわりに
こうして10/28に起きたサーバートラブルは11/12と約2週間で解決となりました。
ほとんどのサーバーは10/29には復旧してた様なので運が悪かっただけかもしれません。
でもこういったサーバーやパソコンのディスク障害ってバックアップさえあれば大した話じゃないんですよ。ちゃんと取れたバックアップなら大して時間かけず復旧できたんです。
仕事柄、データベースがあればどうにかなるので元々データベースのバックアップだけは定期的に作ってローカル保存していました。
ですがWordPressはバックアップ方法どうしようかな、とノンビリ考えていたタイミングで今回のトラブルです。
WordPressのバックアップも無いし、どこがおかしいかも仕様もよく分からない所から調べつつ進めたので時間がかかりました。
もし両方のバックアップがちゃんとあれば、11/1位には新たにサーバー借りて復旧していたと思います。それ位バックアップは大事です。
そしてもうひとつ。データベースやSQLが分からなかったら積んでたでしょう。色々な意味で今回は運が良かったのだと思っています。
やはり共用だろうが占有だろうが、レンタルだろうが自前だろうが、サーバーだろうがパソコンだろうがバックアップです。とにかくバックアップをちゃんと取りましょう。
サーバー上とローカルと、ローカルの別ディスクと3箇所にあればまず消えません。ただのHDDかSSD上でも2～3箇所あればまず大丈夫です。
今回の件はネタになったり勉強になったりしました。「人間万事塞翁が馬」って事ですな。
