WordPressのバックアッププラグイン Updraft でバックアップから復元するときに罠に落ちて台無しになってしまった話です。
WordPressのバックアッププラグインといえばUpdraftとBackWPupが有名でしょうか。バージョン履歴に応じて両者は改善や改悪も経てきて、一概にどっちがいいとか悪いとか言えなくなっています。
UpdraftPlus
今回はUpdraftPlus v1.16についてです。バックアップと復元を簡単に行える優れもの。以前は異なるサーバーへの復元なども行えていましたがバージョンが上がるごとに機能縛りを強化し、現在では以前できていたことの多くが有料版でしかできなくなってしまいました。基本のバックアップと復元は無料版でできます。
Updraftのバックアップ
データベースとテーマをそれぞれバックアップできます。設定はきわめて簡単
バックアップファイルはUpdraftの特殊なファイル形式ですか？基本的にバックアップファイルはUpdraftの画面から操作する以外にどうにもできない特殊な形式のファイルに思えます。思えますというのは詳しくわからないからですが、普通に汎用的に利用できる形式でないことだけは確かです。
Updraftのバックアップからの復元
復元も基本的には簡単です。バックアップされたものがリストされているので「復元」をクリックします。
復元するものを選びます。
簡単ですね。このあたりまでは。
復元したいものを選択すると必要なファイルが準備され、ちょっとした警告と同時にここいらあたりから罠が始まります。
Updraftの復元の罠
復元するのがデータベースの時、「すべてのテーブルを復元したくない場合は、ここで除外するテーブルを選択してください（…）」とあります。
データベースにはいろいろなテーブルがありますし、相互に関連していますから多くの場合はここで除外する設定をしないと思います。でも除外する必要がある特殊な事情もあり得ます。今回はこれにやられました。
復元テーブルを選択する理由
特殊な事情とはなんぞや。例えばあるテーブルだけを弄っていて失敗してしまったとか重要なものを消してしまったとかそういうパターンです。そのテーブルだけがおかしくなったので復元したいと。
例えば私はFileMakerとWordPressのデータベースを連携させて作業しています。そして時に大きなチョンボをやらかします。
個人的な人為的ミスのトラブル
連携させながらも安全策を取って、テーブルの複製をローカルに作成していまして、たまにリモートからインポートしてごっそり入れ替えてリフレッシュしたりします。この度、あろうことかローカルのpostsテーブルを開いているつもりでリモートのpostsを開いていて、これにすべてのデータをセルフでインポートしてしまったんです。まあ自分自身をインポートしたものだから多くエラーが出て更新できなかったんですが、でもよく見るとIDと中身がズレてしまい、1万レコードがすべてぐだぐだになりました。これは修復が厄介な作業となりそうでくらくらします。
丸ごとpostsテーブルを戻そう。と、Updraftのバックアップデータを確認しますと、幸いなことに2日前のバックアップがありました。でもバックアップファイルを解凍してもsqlのファイルが見当たりません。独自ファイルのようです。Updraftの画面から復元するしかありません。
除外するテーブルを選択
という特殊な事情で、バックアップされたデータベースから特定のテーブルだけを復元します。そのために「すべてのテーブルを復元したくない場合は、ここで除外するテーブルを選択してください（…）」の(…)をクリックします。
するとこのような画面が出てきます。すべてのテーブルを復元したくないので、指定の通り除外したいテーブルを選択します。この場合postsだけを復元したいわけですから、図のようにposts以外を選択しました。
選択
選択するということを考えてみましょう。チェックボックスがあります。普通の常識では、選択するとチェックマークが付きます。逆に言うと、チェックマークが付いているものは選択されています。
そうですよね？違いますか？
除外するテーブルを選択してください。とありますので、除外するテーブルを選択します。
除外するテーブルを選択するんですよね？違いますか？
図のように、復元したいpostsテーブル以外を選択しました。これで、postsテーブル以外が復元から除外されます。・・・・そのはずです。その理解のどこが間違っているというんですか。
すべて逆であった
そして機嫌よく「復元」をクリック。postsテーブルが復元されるのを待ちます。どう考えても一瞬で終わると思っていたらこれが意外と時間が掛かって、ログが表示されますから何が起きているのか一瞬で理解できました。
復元から除外を指定したテーブルがすべて復元され、復元させたいテーブルだけが復元されませんでした。
ぽかーん。
何の問題もないすべてのテーブルがバックアップ時点に戻され、壊れたテーブルが壊れたまま放置されました。
結局、復元をやり直してすべてのテーブルがバックアップ時に戻されてしまったわけですが、まあ、2日分というのが不幸中の幸い、大きな被害ではありませんでした。しかしこれは腑に落ちないし、重大な瑕疵であると言わざるを得ません。
「今からあなたをパージします。よろしければはい、やめてほしいならいいえを選択してください」といわれて「いいえ」にしたらパージされたというに等しい。
翻訳の間違いなのか
「すべてのテーブルを復元したくない場合は、ここで除外するテーブルを選択してください」
この一文、「ここで除外するテーブルの選択を解除してください」あるいはもっと簡潔に「復元するテーブルを選択してください」が正しい表現となります。
バックアップや復元という重大な機能なのに全く逆の指定を促すというあってはならないミスです。なぜこのような恐ろしい事が起きてしまったのか。翻訳の間違いなのでしょうか。理由はわかりませんが、UpdraftPlus v1.16.25時点において、このような致命的な欠陥があることがわかりましたのでご報告申し上げる次第であります。
復元するテーブルの注意点
UpdraftPlus v1.16では、復元テーブルの選択で嘘をつかれますので逆のことを行う必要があります。
即ち、テーブルを選んで復元したいときは、「復元したくないテーブル」の「選択を解除」します。
選択してチェックマークを付けたテーブルが復元され、選択を解除しチェックマークを外したテーブルが復元されません。
バックアップ/復元の信頼
バージョンアップでこの表現が修正されることを望みますが、でもね、もし仮にバージョン某かでこの表現が是正されたとしましょうよ。それって、我々は気づくんでしょうか。バージョンがわずかに上る度に、更新ログを隅々までチェックしますか？しませんよね普通。であるからして、もし仮にこの不具合が修正されたとしてもそれに気づかぬまま、「文言と逆の対処」を行い、結果同じ事故に見舞われる可能性が非常に高いです。
この信頼性の欠落は半端じゃありません。バックアップ機能の信頼の欠如は深刻です。
BuckWPupと併用・・・
バックアップの手段を複数持つことがよりよい対処かもしれません。そこで候補に挙がるのがBuckWPupです。
このプラグインも、過去にやらかしていて信頼していませんでした。バックアップしているふりしてファイルを残さなかったという、さようならMovieBooという読む価値のないブログ投稿でぐだぐだ書いたこともありますが。
でも今ではいろいろ修正されていて信頼性が向上していると思います。BuckWPupはバックアップされるファイルが普通のファイルです。データベースならsqlで、ですので復元することができます。ワンクリックで復元、みたいな簡単さはありませんが何を行うか理解しながら己の責任においてやり遂げられます。
バックアップはこまめに
てなわけで、結論としてはバックアップはこまめに取りましょうという当たり前の一言で終わるしかないわけですが。自前でやるのが最も安心確実ですが、ついついプラグインに頼ります。
UpdraftPlus はテーブルを指定して復元できるという利点がありましたが、修正されてもされなくてもどっちにしろ恐ろしいので二度とこの機能を使うことはないでしょう。選択せず丸ごと全部バックアップ・復元する分にはいいと思います。
BuckWPup も細かく指定できていい感じかもしれません。
あと、サイトの引っ越しで役に立つDuplicator というプラグインがあります。細かく設定できませんが、まるごとすべてドカッとバックアップするにはとてもいいです。
