WordPress手動バックアップの欠点

こんばんは。からあげです。

昼過ぎに降り始めた雨は、先ほど上がってくれた。
このまま晴れるかどうか、暗くて空がよく見えないので分からない。
昼間、一人皮剥祭をすると、かなり疲れたので、2時間ほど昼寝をした。
起きるとかなり疲れがとれて体がシャキッとした。
先ほど、晩ご飯を食べ終えて再びパソコンを弄りだしたところだ。
この調子なら夜更かししても大丈夫!

2016-03-28-185711

雨の日にストーブを焚くと湿気が飛んで小屋の中が快適になる。
多少暑くなるが、薄着をして乗り切る。
パソコンのようなハイテク機器を扱っていると精神的に疲れるので、こうした原始的な道具に癒やしを求めてしまう。

今回のネタはサイト運営関連のWordPressネタで、読者の多くは興味がないだろう。
なので、先ほど別個に皮剥祭の記事をアップしておいた。
これから書くことが本日の本命のネタなのだ。
ノートに書くだけだと、自分で分かるように書くだけなので、結局何がどうしたのか分からなくなることが多い。
ブログの記事にすると、他人が読んでも分かるようにしなければならないので、考えて書くことになる。
これが理解を深めることになる。
だから、これからもこのブログはおっさんの備忘録として機能してゆくことになる。

昨日のWordPressネタの記事で書いたように、これまで行っていた手動バックアップに欠陥が見つかった。
欠陥が見つかる以前から、記事数が増えてデータのサイズが大きくなり、バックアップに不便を感じるようになった。
それらの欠点をいろいろ挙げて手動バックアップの限界について説明することにしよう。

参考記事 WordPress手動バックアップ~ロリポップ編(2016/1/6)

スポンサーリンク

WordPressの手動バックアップの欠点

データ量が増えてバックアップに時間が掛かるようになった。

今現在の当ブログの記事数は1,069で、この記事を含めると1,070となる。
これからも毎日更新し続けるので、今後さらに増えてゆくことになる。
同じサーバーのスペースにHPも作成している。
HPの記事数は62

出来るだけ分かりやすくするため、画像を多用するようにしている。
画像は圧縮処理を行って1つ50kB前後としてはいるが、枚数が多いのでトータルではかなりの容量となっている。

2016-3-28-3

ロリポップサーバーのディスク使用量

ライトプラン 容量 50GB

ファイル使用量   1857.074MB 約1.8GB
データベース使用量 221MB

(ブログ・HPの記事総数は1131、画像を多用した場合のディスク使用量)

データ量が増えるにつれて、バックアップにかかる時間が長くなってきた。
手動なので、1回1回その都度、自分でやる必要がある。
ファイルのバックアップは、FTPソフト(File Zilla)、データベースのバックアップは、phpMyAdminでMySQLエクスポートにより行っている。
ネット回線はMVNOで、バックアップ時には高速に切り替えて行っている。
全て行うと1時間近くかかるようになった。
それなので、いつの間にか月1回程度のバックアップとなってしまった。

最近はWordPressの運用にも多少慣れて不具合が出ることが少なくなって来た。
それでも月1回程度では障害が発生した場合、一月分のデータが消失してしまうこともあり得る。
バックアップを取らないことに慣れてしまって危機意識が薄れてしまったようだ。
これではいけない。早急に改善する必要がある!

高速通信分(クーポン)を消費してしまう。

私のネット回線は、IIJmioの音声通話付きミニマムスタートプラン(バンドルクーポン3GB)とmineoデータ通信専用Dプラン500MB(SMS付き)(バンドルクーポン500MB+フリータンク1GB)の2種類だ。
どちらもMVNOで回線の安定性に欠ける。
回線が空いている時なら低速通信でも十分だが、混みあう時間帯だと高速通信にしないと、表示スピードが遅くてストレスを感じることが多い。
バックアップする際は、低速通信だと時間が掛かるし不安定になるので、高速通信に切り替える。
そうでなければまともに作業出来ない。
しかし、高速通信可能なデータ容量は限られている。
限られたクーポンで行う必要がある。
バックアップを頻繁にすればするほど、高速通信分の消費が多くなる。
サイトのデータ量の増大も消費を多くする原因となっている。
無制限に高速通信できる回線に変えればいいだろうが、かなりの費用がかかる。
高速通信分をなるべく消費しないためにバックアップの頻度が少なくなっていった。

サーバーに負荷をかけて表示スピードが落ちる

2016-3-28-1

このグラフは3月26日から27日まで(2日間)の1時間毎のリクエスト数だ。
最高は、昨日27日20時から21までのリクエスト数1466だ。
リクエストとはページビューと同じ意味、ページの表示回数。
逆にリクエスト数が少ないのは、午前3時から5時前までの早朝の時間帯だ。

私がブログのメンテナンス作業をするのは、夕方から夜にかけての時間帯が多い。
アクセスが増える時間帯と重なってしまっている。
その日の出来事をアップするため、遅い更新とならざるを得ない。
アクセス数が増える時間帯に手動でバックアップを行うとサーバーに負荷をかけて、表示スピードの低下や動作の不安定を招くことになる。
これらを回避するには、アクセスが少ない早朝の時間帯に自動でバックアップする必要がある。

2018-3-28-2

手動バックアップは確実な方法だが、このような欠点がある。
どれもこれも悪循環の原因となっている。
やはり自動バックアップに頼ったほうが良いということが分かり、あれこれ調べて作業を進めた。
それで、BackWPupというプラグインをインストール設定をして実際に自動でバックアップしてみた。
以前、このプラグインを試みたことがあったが、エラーが出て出来なくて諦めたことがあったが、今回はエラーが出ずに無事にバックアップ出来た。
バックアップデータは、サーバー内のフォルダに格納されるようにした。
しかし、サーバーからデータをダウンロードしようとすると、きちんとダウンロード出来ないことに気が付いた。
サーバー内にあるバックアップデータの容量の半分もダウンロードしないうちに終わってしまうのだ。
そう言えば、プラグイン「BackWPup」をインストールする前に手動でバックアップをしたが、その時データベースのバックアップデータの容量がかなり小さいことが気になっていた。
今回のBackWPupでも同様にサーバー内のデータをダウンロードすると途中で途切れてしまい、不完全なダウンロードしか出来なかった。

手動でデータベースのバックアップを何度行っても同じような症状が出た。
この不完全なデータでは、サイトを元通りに復旧できない。
それからネット上を彷徨ってあれこれ調べるうちに、同じような症状について書かれた記事を発見した。

参考リンク

PHPmyAdmin上でWordpressデータベースをエクスポートしましたがZIPファイルの中身が空になってしまいました(teratailへようこそ)

phpMyAdminでMySQLエクスポートが途中で切れる場合の対応策(ええかげんブログ)

これらによると、サーバーの仕様が原因だそうだ。
今はまだ勉強中で、読んでもまるで暗号が書かれているようで理解出来ない。
これからコツコツと調べてやってゆくつもり。
データ量が増えてくるとデータベースのバックアップは問題が出てくるようになる。
手動でバックアップする方法では、きちんと出来ないことが分かった。
各テーブルごとに分割してバックアップすればいいが、それでは時間が掛かってバックアップする頻度が少なくなる。これまでと同じことになる。

メンテナンスに時間をとられると肝心のサイト構築に時間をさけなくなってくる。
ここはオプションのバックアップサービスを申し込んだ方が良いかもしれない。
毎月324円(税込み)の費用が掛かるが、自動でバックアップし、別の専用サーバーにデータを保管してくれる。
この別のサーバーにというところがミソだ。
さあ、一晩ゆっくりと考えるとしようか。

おわり

スポンサーリンク
おすすめ記事
Googleさんのおすすめコンテンツはこちら!

『WordPress手動バックアップの欠点』へのコメント

  1. 名前:大伴細人 投稿日:2016/03/28(月) 23:20:22 ID:6dc12ed3e 返信

    いずれはワードプレスに移行しようかと思ってるんですが、
    できるかどうか不安です。

    • 名前:karaage 投稿日:2016/03/30(水) 17:30:34 ID:d63efa140 返信

      みんなやり始めは不安です。
      やっているうちに必要な知識は身につきます。
      一歩を踏み出せば世界が変わります。

  2. 名前:ぽんたちゃん 投稿日:2016/03/29(火) 03:50:46 ID:888788466 返信

    私なら3か月お試しで自動バックアップをしてみますね。
    無料通信wi-fiが近くにあるのであれば別ですが、図書館
    とかセブンイレブン、ファミリーマート、ローソンとかの
    フリースポットでバックアップを取るとか。
    バックアップは必要です。よくありがちなのが最初にバックアップを
    取るのがサーバー(データーベース)が吹っ飛んでリカバリーを取った
    あととかわろえない話はいくらでもあります。バックアップは取り過ぎても
    困りません。復旧できないのがなにより痛いのです。

    • 名前:karaage 投稿日:2016/03/30(水) 17:39:25 ID:d63efa140 返信

      オプションのバックアップを申し込みました。
      今回の復旧で凄く役に立ちました。
      本当に備えあれば憂いなしですね。

  3. 名前:リコプテラ 投稿日:2016/03/30(水) 19:37:31 ID:762b6d8ae 返信

    こんばんは。
    やはりトラブル発生してましたか。
    一時、ブログが表示されなかったり、コメント欄に画像認証がかかっていたり、挙動がおかしかったですから。

    その辺りでコメントしたので、消えちゃったみたいなので、再投稿します。
    挙動が怪しかったので、たまたまコメントテキストを一時保存してあったので、簡単です。
    私もプラグインで痛い目にあったので、今は慎重にやってます。

    以下、本日の12時30分頃投稿した内容です。

    ————————————————————————-

    こんにちは。
    なるほど、サーバのタイムアウトが関連している話でしたか。

    SQLファイルのエクスポートとローカルへのダウンロードを一緒に実行してる点が問題のようなので、通信環境も影響しているかもしれませんね。
    私の場合、通信環境は光なので問題はないと思いますが、SQLファイルの肥大化は将来的に遭遇しそうな問題です。

    2つ目のリンクに書かれている、SQLファイルをローカルでなくサーバ上にエクスポートして、それをFTPでダウンロードするという方法。
    これいいじゃん、と思ったので試しました。
    エックスサーバー、ロリポップともFTPでアクセスしてもsplMyAdminのフォルダが見当たらないので問い合わせたところ、エックスサーバーから「sqlMyAdminはFTPアクセス不可で、設定変更も不可」との回答でした。今現在ロリポップからは回答ありませんが、おそらく同様でしょう。
    この方法は他社も含め共用サーバでは無理なようですね。

    エックスサーバーもロリポップも電話サポートOKと言っても、「技術的なことはメールでお願いします」と。あんまり意味ないですね、電話サポート。

    1つ目のリンクの.htaccessを編集してサーバのタイムアウト時間を延ばす方法は良さそうですね。ただ、ウチのデータベースは今のところ問題なくバックアップできる容量なので、結果の検証はできないのです(笑)

    図書館などの無料WiFiは大容量のデータダウンロードにはなんらかの制限をかけているような気がします。
    一度、別の安定回線で試してみると実際にどこに問題があるのか切り分けできるかもしれませんね。.htaccessによる方法も試してみるとさらに良いかも。

    でも、そんなことをしているよりも、隊長もすでに考えてらっしゃる通り、隊長の通信環境やコストなど考えるとロリポップのスタンダードプラン+自動バックアップがベストかもしれませんね。
    エックスサーバーと同じ会社が運営している、ワードプレスに特化したwpXサーバーも良さそうですが(私はエックスサーバーの回し者じゃないですよ笑)。

    私は現状、ロリポップとエックスサーバーを重複して契約している状態なので、余分なお金をかけてしまいました。
    でも、ロリポップにもワードプレスとブログデータも丸ごと入っていて、契約が残っているうちにいろいろテストできるので、これはこれで無駄じゃなかったなと思います。
    エックスサーバで稼働しているうちに、やっぱりロリポップの方に戻すなんてこともできるし。
    だいぶ回り道して無駄と思われる労力を費やしたおかげで、わかってきたこともたくさんありますし。

    DIYやジムニーに関してもそうですが、隊長の「自分で試行錯誤して結果を得る」という姿勢には強く共感します。
    試行錯誤して得た知識や技術こそが身につくんだと思います。
    そのおかげで私の場合1つのことを身につけるのに、人の3倍くらい時間かかっちゃうんですけどね(笑)

    今日も長文、すみません。
    アウトドア活動(私の場合釣りがメインですが)とブログ運営、お互いこれからもがんばりましょう。

    • 名前:karaage 投稿日:2016/03/30(水) 22:20:12 ID:dce1dce21 返信

      どうもすみません。
      力作のコメントを消してしまいました。
      控えがあって良かったです。

      スタンダードプランに変更してモジュール版PHPとすると遅くなるなんて、これはある意味凄いサービスですね。
      無駄金を使ってこそ分かることがあります。
      別々のサーバーに同じブログを置いているということですが、重複したものとしてGoogleの評価が落ちて検索順位が下がりませんか。

      メンテナンスで一番困るのが回線の不安定なところです。
      図書館のLANの設定がどうなっているか分からないので、回線かサーバー側のどちらに問題があるのか判別出来ません。
      これは困ります。