ブログ運営に関する記事を読んでいると、
「WordPressはコードの書き換えをミスすると、画面が真っ白になっちゃう。だからバックアップは必須。」
的な内容を多く見かけます。
そこで、当ブログもバックアップをしてみました。
まだ、ドメインを立ち上げたばかりで、コードの”͡コ”の字の”C”の字も触っていませんが、とりあえず、バックアップです！
当ブログは、ConoHa Wing 上で運営させていただいていることもあり、ConoHa Wingの標準のバックアップに頼っていても問題なさそうですが、ファイルマネージャ機能をつかってダウンロードを試してみたので、記録として残しておきます。
このページには以下のことを書きました。
- ConoHa Wingによる標準バックアップ（自動です。）
- 手動バックアップ（ConoHa の標準ファイルマネージャを使った場合）
まだ、リストアは試していないので、試したら、また追記しようと思っています。
なお、なぜConoHa Wingに決めたのか？は以下の記事に書いていますので、迷っている方は参考にしてください。
それから、みなさんのご参考に、バックアップについて当ブログの方針を決めるにあたり、勉強した記事のリンクを以下に載せておきますね。
「【WordPress復旧手順】バックアップデータから復元・復旧する方法」
「BackWPUpで確実にWordPressのバックアップを取る方法」
「WordPressでサイトの情報をバックアップする方法【初心者向け】」
上記に載せた記事では、いずれも、WordPressのプラグイン”BackWPup”によるバックアップ方法を紹介しています。
でも、自分のローカルNASへ保存することを考えると、結局、サーバに保存されたファイルをローカルに移すので、手間はあまり変わらないと考えて、当ブログはしばらく手動の運用にすることにしました。（プラグインは試していません。）
今回の記事です。
ConoHa Wingによる標準バックアップの紹介
ConoHa Wingでは、14日間の標準バックアップが付いており、自分でバックアップを考える必要は、あまりなさそうです。
当サイトも、以下のConoHa コンソールのスクショのとおり、バックアップが13日間たまっています。クリックするだけで、14日前の状態までであれば、戻りたい日の私に戻れるようです。(なお、15日前のバックアップには”リストア不可”と明示されています。)
取ったバックアップを、ローカルにダウンロードして中身を見てみたかったのですが、ConoHaコンソールの標準機能では、できなさそうです。
後で書きますが、データベースを手動でバックアップする方法は、今のところ判明していないので、データベースのリストアが必要になった暁には、この、ConoHaの標準バックアップからのリストアを試すことになりそうです。
手動バックアップ．．．ConoHa コンソールの標準ファイルマネージャにて実施
対象フォルダ
サルワカさんの、以下のページを参考に、バックアップすべきフォルダを選びました。
「WordPressでバックアップを取る4つの方法（初心者向け）」
当ブログで、選んだフォルダは、以下の４つです。
- themes>jin
- themes>jin-child
- plugins
- uploads
上記のフォルダは、いずれも”public_html>mottainai-obake.com>wp-content>”の下にありました。
なお、themes>jin-childは、jinの子テーマを適用している方だけ対象です。
当サイトでJINの子テーマをどうして適用することにしたか？は以下の記事で書いています。良かったら、読んでみてくださいね。
バックアップの手順
このページでは、ConoHa Consoleからすぐに利用できる、ファイルマネージャを使ったバックアップ方法を紹介しています。
FTPツールを使ったバックアップ方法については、以下の記事を見てください。
ではファイルマネージャでアクセスしてみましょう。
ConoHaのファイルマネージャは以下のスクショのようなイメージです。
ここで、下↓（上のスクショの赤丸）をクリックすると、ダウンロードが始まります。
上で紹介した、４つのフォルダを１つづつ選択しながら、ダウンロード作業を４回繰り返します。
以下のスクショの通り、ローカルのフォルダに保存しておきました。
ファイルの容量（10記事分）
現在、当ブログの記事は10記事ですが、以下のような状況です。
| フォルダ名 | ファイル容量 |
| thema>jin | 約1.2 MB |
| thema>jin-child | 約1.1 MB |
| plugins | 約0.8 MB |
| uploads | 約18 MB |
uploadsは、画像データが保存されており、容量が多いんですね！
サーバからダウンロードしたときに、他のフォルダは数秒で完了していたのに、このuploadsフォルダだけは、数分かかっていました。
今後も、すべてバックアップするべきか、一考必要です。
以下、考えたことをメモ程度に少し書いておきます。
uploads フォルダがサイズが大きい理由
以下のスクショを見てわかる通り、一つのファイルに対して、描画サイズの異なるファイルを４種類保持しているのが理由のようです。
オリジナルのファイルは、そんなに大きくないのに不思議だなぁと思ってました。
ということで、サーバに上げる前のローカルのファイルをバックアップとして代用することは出来ないので、uploads フォルダも定期バックアップ対象ということになりますね。
uploads fileの具体的バックアップ方法（案）
毎回、これだけ大量のファイルをダウンロードして、ローカルのストレージに保存しておくのも、ストレージがモッタイナイので、uploadsだけは、日付を見ながら差分だけダウンロードする運用にしようと思っています。
それか、FTPのアプリケーションで、「差分のみコピー」的な機能があれば、FTPアプリケーションを導入するか？ですね。
これは、次の項に書く、データベースのバックアップと共に、後日調べようと思います。
データベースはどこだ！
最初に、バックアップをした時には、データベースをどうやってバックアップしたらよいか判りませんでしたが、調査しているうちに判ったので、以下のページに書いていますので、見てみてください。
ということで、このページでは、
当ブログでの、WordPressのバックアップ方法について、暫定的な方法を紹介しました。
また、調査が進んだら更新しようと思います。
最後まで読んでいただき、ありがとうございます！
このページで分かるように、ConoHa WingでWordPressを始めれば、バックアップの悩みはあまりありませんよね。
