WordPress のバックアップ完了 ( WP-DB-Backup )
前のエントリでサイトのバックアップをしていないことに気づいた問題について、調べてみて無事目処がついたのでメモ程度にエントリしておきます。
説明なしにいくつかのツールが出てきますが、技術紹介が目的ではない(というよりも説明しきれない)のでご勘弁を。
バックアップ対象。
WordPress は動的生成タイプの CMS なのでコンテンツの本尊としては DBMS (データベース)のデータそのものが最も重要です。それとは別にサーバにアップロードされているファイル群(主に画像)があり、これもとても重要です。それら以外にも、サーバ上にある PHP や CSS や JavaScript のファイル、プラグインやテーマなどのファイル群もサイトを復元するためには必要になります。
DBMS のデータとアップロードしたファイルは何かで失われればもう戻っては来ませんので、確実にバックアップする必要があります。それ以外は自分が作り出したコンテンツというわけではないので、再度インストールしプラグインも全部入れ直して設定しなおせば原則は元通りになります。とはいえ、どうなっていたか、何を入れていたか、微妙に違うがどこが違うか、などを調べるにはフルバックアップしておくに越したことはありません。
ということで、DBMSのデータだけでなくサイト上にあるファイル群もまるっとバックアップする方針にしました。両者は別々の方法でバックアップする形になるようです。
DBMS のデータのバックアップ。
DBMS のデータを吸い出すメジャーなプラグインは以下の二つのようです。
まず最初に情報を見つけたWP-DB-Backup を使ってみて、特に不都合もなかったので WP-DBManager は試しませんでした。ものぐさです。
インストールするとダッシュボードの「ツール>バックアップ」に設定が現れます。
とりいそぎ即時バックアップで直接ダウンロードする方法を試してみましたが、落ちてきたファイルを開くと中身が空というか先頭のファイルヘッダしかなく、うまくいきませんでした。このプラグインはだめかなあと思いつつ、サーバ上でバックアップをとって FTP で落としてくると、今度はばっちりデータが詰まっています。出力されているのはまんま mysqldump の SQL ファイルでした。
設定については、定期バックアップを毎日にしてメールでは投げないようにしました。SQL ファイルが gzip で圧縮されているだけなのでなんとなく不用心かな、と(FTP は不用心じゃないのか…ってのも考えていかなければ)。
サーバ上のバックアップファイルは週一ペースでFTP で手動で落としてきます。ToDo管理で繰り返しアイテムとして登録してあるので漏れないと思います。
サーバ上のファイルのバックアップ。
サーバ上にあるファイルは、単純に FTP クライアント でダウンロードしてきてバックアップするだけです。
FTP クライアントは Cyberduck というフリーウェアを使っています。これにサーバとのミラーリング機能があるので、ローカルの特定のフォルダとサーバの内容をミラーリングします。
単純に FTP でローカルに取ってきていても今ひとつ芸がないので SVN (subversion) で構成管理もしてしまいます。DBMS のバックアップは肥大化しそう(と勝手に思っている)なので含めず、それ以外のファイルを SVN 上 に入れます。
FTP クライアントで決まった場所(svn のチェックアウト先)にミラーリングして、 svn satus で変更ファイルを確認の上 commit するような流れです。ミラーリングはうまくいっていないような節もあるので少々注意深くやる必要がありそう。毎回ダウンロードがいいのかもしれない。もう少し試行錯誤します。
晴れて 2.8.2 へアップグレード。
というわけで、バックアップの運用が決まり手順も確認できたので満を持して 2.8.2 にアップグレードしました。
ダッシュボードからの作業であっけないほど一瞬で終わりました。
すかさずバックアップ作業を実施です。
これで安心です。よかったよかった。