Web担当者必見!プロが教えるWordPressのバックアップ術

  • このエントリーをはてなブックマークに追加
  • Pocket
  • LINEで送る

こんにちわ、家富です。

もしも

管理している顧客の
サイトが飛んでしまったら・・

収益を生んでいる
サイトが飛んでしまったら・・

考えただけでも「ゾッと」
しませんか?

本日は考えただけでも恐ろしい
最悪な状況に陥ってしまった時のための保険とも言える

WordPressのバックアップの
取り方についてご説明したいと思います。

あなたはどういった方法で
WordPressのバックアップを
取られていますでしょうか?

このバックアップの方法について
Webで検索をしてみると、

プラグインでのバックアップ方法
説明しているブログなどをよく目にしますが、

あなたはプラグイン側で
どういった処理を行っているか、
具体的に確認したことはありますか?

プラグインにすべて任せてるから安心!
という方もたくさんいらっしゃると思いますが、

もしバックアップが必要なときに、
そのプラグインが正しく動作しなかったら

バックアップや、そのデータの復元作業を、
プラグインに頼らず行える自信がありますか?

ご自身の大切なデータなのですから、
他人の作ったシステム任せにするのではなく、

いざというときのために、
手動でデータをバックアップ・復元できる、
知識は必ず持っておくべきです。

今回はまず、
手動によるバックアップ方法
についてご説明します。

データのバックアップ

WordPressのデータを
バックアップするためには、

まずどういったデータを
バックアップするべきか、

具体的なバックアップ対象を
確認しておく必要があります。

WordPressでバックアップが必要なのは、
以下に示す5つです。

  1. テーマファイル一式
  2. プラグイン一式
  3. データベース内容一式
  4. アップロードファイル一式
  5. wp-config.php

基本的にはこれ以外のバックアップは、
必要ないと考えてもらってOKです。

WordPressの本体ファイルは
いつでもオフィシャルサイトから
最新版のデータを
ダウンロードすることができますので、

わざわざ複雑な本体ファイルを
バックアップする必要はありません。

しかしながら、
本体ファイルに改変を加えている場合は別です。

ただし、本体ファイルに
改変を加えるということは、

バックアップに手間がかかるだけではなく、
バージョンアップの場合にも、

本体を更新したらサイトが動かなくなるという、
大きな問題を抱えることになりますので、
通常は行うべきではありません。

安易に本体改造を勧めるサイトや、
ブログの記事をよく目にしますが、

その紹介されているコードは、
WordPressの流儀や
本来のカスタマイズ方法を知らない
素人の方が書いた記事が多い印象です。

そのコードがどういった影響を及ぼすのか、
なぜその場所の改造が必要になるのか、
ご自身で意味が分からない場合には
絶対に行わないようにしてください。

話が脱線してしまいましたが、
基本的には上記の内容を
バックアップするだけで事足ります。

バックアップするファイルの詳細

それでは、先ほどのバックアップ対象について、
より深く掘り下げてみます。

データベースを除く
ファイルのバックアップは、

WordPressを
インストールしたディレクトリの、

以下のディレクトリと
ファイルをバックアップしてください。

/wp-content/themes/{テーマ名}/
/wp-content/plugins/
/wp-content/uploads/
/wp-config.php

最低限のバックアップは
上記で問題ありません。

ただ、プラグインなどによっては、
/wp-content/ ディレクトリ内に
独自のデータを保存し、
利用しているケースがあります。

もし判断がつかない場合には、
/wp-content/ ディレクトリを
丸ごとバックアップしても、
問題はありません。

確実なことが不明であれば、
/wp-content/ ディレクトリを
そのままバックアップするのが、
安心できる方法でしょう。

バックアップを行う際の文字コード

ファイルを
バックアップする際に
注意していただきたいのが、

FTP接続時の

「エンコーディング指定
(文字コード指定)」

です。

WordPressでは
メディア管理機能があり、

そちらに写真などを
ファイルをアップロードして、

ブログのアイキャッチ画像や
添付ファイルなどを管理しますが、

そのファイルが日本語名称の
場合などが多々あると思います。

WordPressではそういったファイルを、
/wp-content/uploads/ 以下に保存するのですが、

WP Multibyte Patchプラグインを
利用している場合を除き、
そのときのファイル名には、

アップロードされた時の
ファイル名をそのまま利用します。

そして、
通常はUTF-8の文字コードを使って、
データを保存しています。

FTPソフトは多々ありますが、
どのFTPソフトにも接続時の
エンコーディング指定(文字コード指定)というのがあり、

通常は「自動」といった
内容になっていることが多く、

その場合にサーバー上の日本語ファイル名が
文字化けしていることがあります。

もし文字化けしているまま
ダウンロードしてしまうと、

文字化けしているデータが
手元に残ることになり、

復元した場合にリンク切れが
発生することになります。

FTPソフトでの接続は、
エンコーディング指定(文字コード指定)を
必ず「UTF-8」に指定し、
接続するようにしてください。

データベースのバックアップツール

次にデータベースの
バックアップを行いましょう。

通常はサーバーに
「PHPMyAdmin」や「Plesk」といった、

データベースの管理ツールが
存在する場合が多いのですが、

もし簡単に使える管理ツールが存在しない場合、
以下のツールが非常に役に立ちます。

Adminer
https://www.adminer.org/

これは1ファイルで
動作するデータベース管理ツールで、
PHPMyAdminの簡易版のようなものです。

簡易版といっても
PHPMyAdminでできることは、

ほとんどすべて行うことができるうえ、
インターフェースも簡略化されて見やすいので、
とても使いやすいです。

私はPHPMyAmdinが使える場合でも、
こちらのツールを利用して
対応することの方が多いです。

データベースのバックアップ方法

データベースのバックアップは、

wp-config.php に
記載されている接続情報をたよりに、

バックアップするデータベースと
テーブルを判断しましょう。

1つのデータベースに、
複数のWordPressが
インストールされていたり、

そのほかのシステムが
インストールされている場合、

どのテーブルを
バックアップすればよいのか、
判断に迷う場合があります。

そんな時は wp-config.php の、
テーブルプレフィクスを確認してください。

テーブルプレフィクスの値が wp_ となっていれば、
データベース内の以下のテーブルが対象となります。

wp_posts
wp_postmeta
wp_users
wp_usermeta
wp_terms
wp_term_taxonomsy
wp_term_relationships
wp_options
wp_comments
wp_commentmeta
wp_links
wp_termmeta (WordPressバージョン 4.2.2以上)

もし、テーブルプレフィクスが site_ 等となっていた場合、
上記のテーブル一覧は、

site_posts
site_postmeta
site_users

といった名称になります。

WordPressの基本的なテーブルであれば、

上記で示した12テーブル
(バージョン4.2.2未満であれば11テーブル)を

バックアップすればよいのですが、
プラグインの中には独自のテーブルを作るものがあります。

そういった場合、
とりあえずテーブルプレフィクスが同一のものは、
すべてバックアップをとっておけば安心です。

ただし、複数のWordPressが
インストールされている時に、
テーブルプレフィクスが似ていることがあり、
その場合には若干注意が必要です。

サイトA:wp_
サイトB:wp_site_

のような状況だと、

wp_posts
wp_site_posts

といった具合に、
似たテーブル名称ができていますので、

違うWordPressのテーブルを
バックアップしていて、

必要なWordPressのテーブルが
バックアップされていなかった・・

という事態が起こらないよう注意が必要です。

さらに注意となりますが、
プラグインが独自に
テーブルを作成する場合には、
開発の明確なルールがあり、

wp-config.php に設定された
テーブルプレフィクスを、
必ず独自のテーブルにもつけることが
義務づけられています。

ただ、
中にはそういったルールを無視し、
テーブルプレフィクスをつけずに、
勝手なテーブルを追加するプラグインも存在します。

今流通しているメジャーなプラグインでは、
そういったことは確認できませんが、

古いプラグインや、
WordPressの公式ディレクトリ以外から
ダウンロードしたプラグインなどでは、

そういったルールを無視する
不届きなプラグインが存在することが、
今までに何度かありました。

そういった場合、
どのテーブルをプラグインが作ったのか、
判別をするのが非常に難しい状況になります。

もし心当たりがあり、
判別がつかない場合には、
やむを得ず全テーブルをバックアップするのも、
視野にいれておきましょう。

さいごに

以上がWordPressの
手動バックアップの方法です。

基本的にはどんなバックアッププラグインも、
上記の内容をシステマチックに行っているものが多いです。

手動でのバックアップ方法を知っておくことで、
万が一プラグインが動作しなかった場合でも、
確実なバックアップを取得することができます。

すべてを他人が作ったシステムに依存するのも、
手軽でコストもかからないため魅力的ですが、

何かあったときに内部がブラックボックスだと、
手を出すことができず、
結局はコストが発生することになります。

自分自身の大切なデータの
バックアップ方法については、
最低限理解しておくようにしたほうが、
より安心したサイト運営が可能になります。

  • このエントリーをはてなブックマークに追加
  • Pocket
  • LINEで送る

SNSでもご購読できます。

コメントを残す

*