ECサイトのバックアップで最優先すべきはデータベースです。注文と顧客の情報が入っているため、サーバーに障害が起きてもデータベースさえ残っていれば、出荷や顧客対応を続けられる可能性があります。mysqldumpとcronで自動取得する手順と、別サーバーへ復元するまでをまとめます。
データベースを最優先でバックアップする
バックアップの対象はデータベースとファイルの2つですが、優先度は同じではありません。
ソースファイルは最悪の場合、再構築できます。しかし注文データと顧客データは失われたら復元できません。まずデータベースの定期バックアップを確実にしてください。
レンタルサーバーによっては自動バックアップが標準で付いています。エックスサーバーはMySQLデータベースを過去14日分保持しています。ただし取得は1日1回なので、直前の注文が失われる可能性は残ります。契約中のサーバーの仕様を確認してください。
mysqldumpとcronで自動取得する
SSHとcronが使えるサーバーなら、取得頻度を自分で決められます。バックアップ用のスクリプトを用意します。
cd "$(dirname "$0")"
ec_filename=ec`date "+%Y%m%d_%H%M%S"`.sql
mysqldump --single-transaction -u ユーザー名 -pパスワード -h localhost データベース名 | gzip > ../data/${ec_filename}.gz--single-transaction を付けているのは、テーブルをロックせずに整合性のある状態を取得するためです。これがないと、取得中に入った注文でデータの前後関係が崩れることがあります。
ファイル名にタイムスタンプを入れているので、実行のたびに別ファイルとして残ります。
cronで3時間ごとに実行する例です。
0 */3 * * * sh /home/ユーザー名/example.com/script/backupdb.shパスワードをスクリプトに直接書く場合、ファイルの権限を制限してください。公開ディレクトリの外に置き、所有者以外が読めないようにします。
ファイルは画像を中心にバックアップする
ソースをGitで管理していても、管理画面からアップロードした画像はGitに入りません。商品画像が消えると復旧に手間がかかるので、あわせて取得します。
EC-CUBE4では、商品画像は html/upload/save_image に保存されます。ここを含めてtarでまとめます。
tar czf backup_files_`date "+%Y%m%d"`.tar.gz html/uploadサイズが大きくなるため毎回全体を取る必要はありませんが、最低でも数世代は残してください。1世代だけだと、障害に気づく前に壊れたデータで上書きされる可能性があります。
バックアップの保管先をサーバーの外にする
同じサーバーに置いたままでは、そのサーバーが失われたときに一緒に消えます。クラウドストレージへ自動転送するのが確実です。
AWS CLIをインストールできるサーバーなら、S3へのアップロードまで自動化できます。
aws s3 cp ../data/${ec_filename}.gz s3://バケット名/backup/ローカルPCへのダウンロードでも保管にはなりますが、容量を圧迫するうえ手作業が続きません。自動で外部に置く形にしてください。
別のサーバーへ復元する手順
サーバー移転や障害からの復旧では、次の順番で作業します。
- データベースをインポートする — 新しいサーバーでデータベースを作成し、取得したダンプを流し込みます
gunzip < ec20260731_030000.sql.gz | mysql -u ユーザー名 -p データベース名 - ファイルを配置する — ソース一式と、バックアップしておいた
html/uploadをアップロードします - データベース接続情報を書き換える — EC-CUBE4では
.envのDATABASE_URLを新しいサーバーの内容に変更しますDATABASE_URL=mysql://ユーザー名:パスワード@localhost/データベース名.envの値は実行時に読み込まれるため、書き換えたあとのキャッシュクリアは不要です。そのままサイトを開いて動作を確認してください。
EC-CUBE3の場合、接続情報の場所が違います。.env ではなく app/config/eccube/database.yml を書き換えてください。
復元できることを一度は確認しておく
バックアップで最も多い失敗は、取得できているつもりで復元できないことです。
cronが止まっていた、権限エラーで0バイトのファイルが並んでいた、ダンプが途中で切れていた——障害が起きてから気づくと手遅れになります。
- 取得したファイルのサイズが妥当か（極端に小さくないか）を定期的に見る
- 一度は実際に別環境へ復元して、サイトが動くところまで確認する
この2つをやっておくかどうかで、いざというときの結果が変わります。
サーバー構成による違い
レンタルサーバーの自動バックアップは1日1回の取得が多く、復元できるのはその時点までです。障害直前の注文は戻りません。
VPSやクラウドサーバーであれば、スナップショットの取得間隔を自分で決められ、障害発生の直前に近い状態へ戻せます。取り扱う注文数が多いサイトほど、この差が影響します。
自動バックアップの仕組みはサーバーによって異なるので、契約中のサーバーで何がどこまでできるかを一度確認しておいてください。
EC-CUBEゴールドパートナー
EC-CUBEに関するお問い合わせ
[重要]現在公式にセキュリティサポートが切れていないPHPは8.1以上、MySQLは8.0以上で、対応しているEC-CUBEバージョンは4.2以上です。古いEC-CUBEを使っている方は適切なタイミングでバージョンアップをご検討ください。
