WordPressのバックアップとリストア検証

WordPressのバックアップがきちんとできているのか検証した。Qiita初投稿。

## 環境
* WordPress 4.6.1
* 旧環境: [さくらのレンタルサーバ スタンダード](http://www.sakura.ne.jp/standard.html) にクイックインストールしたWordPress
  * FreeBSD 9.1, MySQL 5.5, PHP (CGI) 5.6.18, 
* 新環境: Windows 10上のVirtualBox 
  * CentOS 7.2, MariaDB 5.5, PHP (cli) 5.6.26, 

### カスタマイズ
* Custom Post Type UI (CPT UI)([Webデザインレシピ](http://webdesignrecipes.com/wireframe-with-wordpress-post-type/#p5))を使用
* 子テーマ作成、twentysixteenを継承

## 手順概要
* バックアップ 
  1. [WordPress初心者でも簡単にできるバックアップ方法 - Natfix](http://naifix.com/backup/) を参考
  * テーマやプラグインなどの外観を入れたテーマディレクトリを保存、記事やコメントなどのデータベースをxmlファイルで保存
  * パーマリンクやCPT UIなどのページリンク構造をテキストデータとして保存
* リストア
  1. バックアップ同様 [バックアップデータを使ってWordPressを復旧・移行する方法](http://naifix.com/wordpress-recovery/) を参考
  * 新環境の準備、PHP、MySQL(MariaDB)、Apache(httpd)をインストール
  * WordPressをインストール
  * バックアップしていたテーマディレクトリを上書きコピーし、テーマやプラグインを有効にし、リンク構造を復旧する
  * データベースのxmlファイルをインポート
  * 固定ページやウィジェット、メニューを前と同様に

### 注意点
#### リストア時
1. xmlファイルをインポートできない！「読み込みに失敗しました」
    *  wp-config.php に1行追加
* トップページ以外404!
  * ページのパーマリンク、.htaccess

## 手順詳細
### バックアップ
対象は3種類

1. テーマやプラグインなどをダウンロード
  * FTPでwp-contentディレクトリ以下にあるplugins、themes、uploadsの３つのディレクトリをダウンロード
* 記事やコメント(データベース)などのデータベース内情報をエクスポート
  * WordPressの管理画面 > ツール > エクスポート > すべてのコンテンツ
  * XMLファイルがダウンロードされる
* その他の設定をメモ
    * タイトルや投稿設定以下にある「更新情報サービス（ping）」一覧
    * 設定 > パーマリンク設定
        * これがないとXMLをうまく読み込めない
        * 下の例だと「カスタム構造」のテキストフィールドに**/%category%/%postname%/**と入れている
![permalink.png](https://qiita-image-store.s3.amazonaws.com/0/14508/12e9e185-bf8f-9d7b-69b9-1c79ad6c71de.png)
        * CPT UIなどでカスタム投稿タイプ(Post Types)を作っている場合にはカスタム構造と同様に設定を保存しておく。CPT UIだと Import/ExportのExport Post Types欄にJSONと思しきコードがあるので、これをテキストファイルに保存する
        * メニューの構造(外観 > メニュー)や、Facebookのページプラグインをサイドバーに表示するためのテキストウィジェット (外観 > ウィジェット)、固定ページ(外観 > カスタマイズ > 固定フロントページ)なども手動で保存しておいた
* 以上のファイルをDropboxとかbitbucketなど適当なところに置いておく

#### バックアップのタイミング

* テーマに変更を加える場合は、FTPソフトで「themes」をダウンロードしておけばOK
* 更新時に記事をバックアップするなら、「エクスポート」しておけばOK
* cronなどで自動的、定期的に

### リストア
つまり、なんらかの問題発生時にテーマを戻したりデータベースを消して入れ直したり、あるいは他のサーバに移転したり。バックアップがうまくできたかどうかの確認は仮想環境を使ったりDockerなどを使ったり。以下は仮想環境に移したときの記録。

1. こちらもこのサイトを参考: [バックアップデータを使ってWordPressを復旧・移行する方法](http://naifix.com/wordpress-recovery/)
* 新環境にApache、php、MariaDB/MySQLをインストール
* MySQLにデータベースユーザとデータベースを作成(mysql -u root -p とかcreate databaseとかgrant allなどのコマンドをメモっておく)
* WordPressを/var/www/html/new-siteに置き、http://localhost/new-site にブラウザでアクセスしてインストールし、データベース情報を入力すれば空っぽの新しいWordPressサイトができる
* ログインしてダッシュボードにタイトルなどを入れる
* バックアップしておいた「plugins」「themes」「uploads」をwp-contentsに上書きコピー
* プラグインを有効にする。更新は後回しにしたほうがよいかもしれないけど、まあ失敗したらやり直せば良い
* 子テーマを作っていた場合はそのテーマを有効にする
* パーマリンク構造を設定する。上記バックアップの例を使うと、設定 > パーマリンク設定から カスタム構造のテキストボックスに 「/%category%/%postname%/」を入力して変更を保存
* CPT UIなどでカスタム投稿を設定していた場合は CPT UI > Import/Export でImport Post Typesに バックアップしておいたJSON情報を貼り付けてインポート
* データベースを復旧する。
    * ダッシュボードの、ツール> インポート から WordPressの「今すぐインストール」を選択
    * WordPressのFTP接続情報(ホスト名と、FTPユーザー名、FTPパスワード)を要求される場合がある。wp-config.php 最下部に 
```php
    define('FS_METHOD','direct');
```
の1行を追加して再試行するとFTP情報を訊かれずに先に進むことができる
        * 参考: [WordPress更新時にFTP情報入力画面が表示される場合の対処方法3つ | sand a lot Web & Music Create [札幌]](http://www.sandalot.com/wordpress%E6%9B%B4%E6%96%B0%E3%81%A7ftp%E5%85%A5%E5%8A%9B%E7%94%BB%E9%9D%A2%E3%81%8C%E8%A1%A8%E7%A4%BA%E3%81%95%E3%82%8C%E3%82%8B%E5%A0%B4%E5%90%88%E3%81%AE%E5%AF%BE%E5%87%A6%E6%B3%95/)
    * インポーターを実行。xmlファイルを選択して(2MBの制限はphp.iniに由来)、投稿を「既存のユーザー」に割当て、「添付ファイルをダウンロードしてインポートする」 にチェック
        * これは旧サイトにある添付ファイルを新サイトに持ってくる という意味
* これで成功 のはずだが、トップページはちゃんと表示されるがそれ以外が404になることがある
    * /etc/httpd/conf/httpd.conf の/var/www/html/ にある AllowOverrwide をNoneからAllに変更。上のフォルダ(/var/www にも .htaccessを作っておく)
    * Apache httpdのmode_rewriteはオンだったが、リダイレクトを記述する.htaccessが読み込めていなくても404になる
        * 参考: [mod_rewriteの設定(パーマリンク形式を変更した場合にエラー表示された場合) - WordPressの使い方](http://www.adminweb.jp/wordpress/permalink/index2.html)
        * 参考: [WordPressに作成される.htaccessの動作を改めて確認しておこう | ええかげんブログ(本店)](http://algorhythnn.jp/blg/2014/08/25/wordpress-htaccess-check/)
    * ちなみに /var/www/htmlのAllowOverwrite をAllにすると、上位フォルダの /var/www をNoneにしていたとしても.htaccessが必要になるらしい。また、その.htaccessはグループとオーナーをapacheにしないと怒られた



## Future Work
* Stagingサイトを作って本番環境(Production)前に出来具合を確かめる