WordPressデータバックアップ方法の調査結果のまとめ

WordPress

WordPressのデータ移行について色々と調査したときの記録です。

スポンサーリンク

意外と無いね。移行ツール

ConoHaとKUSANAGIで月々630円の格安WordPressサーバを作る方法
ConoHaにKUSANAGIをインストールしてWordPressサーバを立ち上げるときの手順を一通り解説します。 このページが連載の目次ですので、ブックマークするならこのページをおすすめします。

をやっているときに、WordPressサイト単位の同期コピーをやりたいと思いました。

WordPressならきっと簡単操作の同期プラグインがあるに違いない、と。
甘く見てました。

無いんですね~(TдT)

具体的にはこんな仕様です。

  • ブログAとブログBの双方に同期用プラグインをインストールしておく
  • 双方に秘密の合言葉を入れておき、所有者の一致を確保する
  • 「同期」ボタンを押すと双方の更新日時を勘案して最新状態に同期
    (まあ、一方的なコピーでも良い)
  • 有料オプションでスケジュール同期出来るようになる

誰かァ!ビジネスチャンスだよ!作ってくれ!www

いやホント不思議だよ。
こんだけプラグインが充実してるWordPressにこの種類ものが無いなんて。

どなたか良い同期用プラグインご存知なら教えてください。

俺的WordPress移行最短手順2選

色々とやり方はあると思いますが、今回の案件では2つのやり方に行き着きました。

“All-in-One WP Migration”プラグイン

画面操作で完結させるならこのプラグインを使うのが一番簡単・確実です。

https://ja.wordpress.org/plugins/all-in-one-wp-migration/
  1. 正サイト・副サイトそれぞれにプラグインをインストール
  2. 正サイトをファイルにエクスポート(クリック一発)
  3. 副サイトでファイルをインポート(クリック一発)
  4. 副サイトにテーマをインストール

コレだけで良いです。実に分かりやすいです。

単にサーバを引っ越すだけならこのプラグインが最強と思っています。
ただ、スケジュール実行ができないので今回の目的(正サイトダウン時の代替)には使えませんでした。

wordmoveスクリプト

wordmoveはWordPressの本番機と開発機の同期を取るrubyスクリプトです。
シェル・git・rubyが必要。

wordmove pull --all

とやると本番機→開発機、

wordmove push --all

とやると開発機→本番機の向きでWordPress一式が被さります。

スクリプトなのでcronでスケジュール実行できるので、「普段から内容を同期させる」という今回の要件にマッチするのでコレで行くことにしました。

正直、黒い画面は極力見たくないのですが…。

実例

参考までに、KUSANAGIにwordmoveをインストールしたときの手順です。

KUSANAGIにwordmoveをインストールする
KUSANAGIにwordmoveをインストールするための手順です。

今回の場合、

  • ConoHa側にwordmoveをインストール(制限が無いので)
  • ConoHa側を「開発機」
  • エックスサーバー側WordPressを「本番機」とみなして
  • エックスサーバーからConoHaにpull

することで同期を実現しました。

こちらはUbuntuにインストールしたときの手順です。

Ubuntuにwordmoveをインストールする方法
Ubuntu Server 16.04にwordmoveをインストールしたときの記録です。 エックスサーバーにある本番サイトを、自宅内のUbuntu Server 16.04にwordmoveでバックアップを取りました。

余談

記事単位の同期はプラグイン有り

ちなみに実用はしていませんが、記事単位の手動で良ければ

https://wordpress.org/plugins/wpsitesynccontent/

があります。
「確認してから本番公開」みたいな運用ならピシャリとハマりますね。

バックアップの原理

WordPressは

  1. プログラム・デザイン・画像等の『ファイル』
  2. 記事本体を記録したデータベース

で構成されておりますので、

  1. rsync等のコピーツール
  2. はストアド・プロシージャやトリガの仕掛け

があれば原理的にはリアルタイム同期できます。

タイトルとURLをコピーしました