WordPressのバックアップをNFS共有ストレージに保存する手順（exports・マウント・cron）

NFS（Network File System）は、別のサーバーや NAS のディレクトリを、ネットワーク越しに自分のディレクトリのようにマウントして使う仕組みです。WordPress サーバーのディスクとは別の機器にバックアップを置けるので、サーバーのディスク故障や OS の破損からデータを守れます。

この記事では、NFS サーバー（バックアップ用ストレージ）を用意し、WordPress サーバーからマウントして、データベースとファイルを毎日保存する手順を説明します。

構成と前提

• 2台は同じ社内ネットワーク（プライベートネットワーク）にあるものとします。NFS の通信は標準では暗号化されないため、インターネット越しに使わないでください。
• コマンドは Debian / Ubuntu と RHEL 系（AlmaLinux、Rocky Linux など）を想定しています。
• NAS 製品を保存先にする場合は、手順1の代わりに NAS の管理画面で NFS 共有を作り、許可するクライアントに WordPress サーバーの IP アドレスを指定します。

手順1: NFSサーバーで共有ディレクトリを作る

パッケージを入れ、共有するディレクトリを作ります。

# Debian / Ubuntu
sudo apt install nfs-kernel-server

# RHEL 系
sudo dnf install nfs-utils

sudo mkdir -p /srv/backup/wordpress
sudo chown 1500:1500 /srv/backup/wordpress

/etc/exports に共有の設定を1行追加します。

/srv/backup/wordpress 192.168.10.11(rw,sync,no_subtree_check,root_squash,anonuid=1500,anongid=1500)

バックアップはクライアントの root で実行します。root_squash によってサーバー側では UID 1500 として扱われるため、共有ディレクトリの所有者を 1500 にしておくと書き込めます。no_root_squash にするとクライアントの root がサーバーのファイルを root 権限で扱えるようになるので、使わないでください。

設定を反映し、NFS サービスを起動します。

sudo exportfs -ra
sudo exportfs -v

# Debian / Ubuntu
sudo systemctl enable --now nfs-kernel-server

# RHEL 系
sudo systemctl enable --now nfs-server

ファイアウォールを使っている場合は、NFS の通信（NFSv4 では TCP 2049 番）を WordPress サーバーからだけ許可します。

# firewalld（RHEL 系）
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.10.11" service name="nfs" accept'
sudo firewall-cmd --reload

# ufw（Ubuntu）
sudo ufw allow from 192.168.10.11 to any port 2049 proto tcp

手順2: WordPressサーバーからマウントする

# Debian / Ubuntu
sudo apt install nfs-common

# RHEL 系
sudo dnf install nfs-utils

sudo mkdir -p /mnt/backup
sudo mount -t nfs 192.168.10.20:/srv/backup/wordpress /mnt/backup

# 書き込めるか、サーバー側でどの UID になるかを確かめる
sudo touch /mnt/backup/write-test
ls -ln /mnt/backup/write-test
sudo rm /mnt/backup/write-test

ls -ln の所有者が 1500 と表示されれば、root_squash と anonuid が設定どおりに働いています。

再起動後も自動でマウントされるように、/etc/fstab に追加します。_netdev は、ネットワークが使えるようになってからマウントするための指定です。

192.168.10.20:/srv/backup/wordpress  /mnt/backup  nfs  defaults,_netdev  0  0

sudo umount /mnt/backup
sudo mount -a
mountpoint /mnt/backup

手順3: バックアップスクリプトを作る

データベースの接続情報は、コマンドラインに書かずに設定ファイルに置きます。

/root/.wp-backup.cnf（chmod 600 にする）:

[client]
user=wp_backup
password=change-this-password

/usr/local/sbin/wp-nfs-backup.sh:

#!/bin/bash
set -euo pipefail

WP_PATH=/var/www/html
DB_NAME=wordpress
DEST=/mnt/backup
KEEP_DAYS=14
STAMP=$(date +%Y%m%d-%H%M)

# NFS がマウントされていなければ中止する（ローカルディスクに書いてしまうのを防ぐ）
if ! mountpoint -q "$DEST"; then
  echo "$(date '+%F %T') $DEST is not mounted" >&2
  exit 1
fi

# 書き込み中は .part の名前にしておき、終わってから正式な名前に変える
mysqldump --defaults-extra-file=/root/.wp-backup.cnf --single-transaction \
  --default-character-set=utf8mb4 "$DB_NAME" | gzip > "$DEST/db-$STAMP.sql.gz.part"
tar -czf "$DEST/files-$STAMP.tar.gz.part" -C "$WP_PATH" .

# 圧縮ファイルが壊れていないか確かめる
gzip -t "$DEST/db-$STAMP.sql.gz.part"
tar -tzf "$DEST/files-$STAMP.tar.gz.part" > /dev/null

mv "$DEST/db-$STAMP.sql.gz.part" "$DEST/db-$STAMP.sql.gz"
mv "$DEST/files-$STAMP.tar.gz.part" "$DEST/files-$STAMP.tar.gz"

# 古いバックアップを削除する
find "$DEST" -maxdepth 1 -type f \( -name 'db-*.sql.gz' -o -name 'files-*.tar.gz' \) \
  -mtime +"$KEEP_DAYS" -delete

echo "$(date '+%F %T') backup $STAMP done"

sudo chmod 700 /usr/local/sbin/wp-nfs-backup.sh
sudo /usr/local/sbin/wp-nfs-backup.sh
ls -lh /mnt/backup

スクリプトのポイントは次のとおりです。

• 未マウントのときは止める: NFS が外れていると /mnt/backup はただのローカルディレクトリになり、バックアップが WordPress サーバー自身のディスクに溜まってしまいます。mountpoint -q でマウントを確かめてから書き込みます。
• 途中のファイルを正式な名前にしない: 書き込みの途中で失敗したファイルは .part のまま残るので、正常なバックアップと見分けられます。
• set -o pipefail: mysqldump が失敗したときに、後ろの gzip が成功してもスクリプトをエラーで止めます。

wordpress は wp-config.php の DB_NAME、/var/www/html は WordPress を置いたディレクトリに合わせます。

手順4: cronで毎日実行する

/etc/cron.d/wp-nfs-backup:

30 0 * * * root /usr/local/sbin/wp-nfs-backup.sh >> /var/log/wp-nfs-backup.log 2>&1

毎日 0時30分に実行し、結果をログに残します。cron の行の中で date +%Y%m%d のように % を使うと改行として扱われるため、日付の処理はスクリプトの中に置いています。ログに is not mounted が出ていないかを定期的に確認してください。

手順5: 復元を確かめる

バックアップは、戻せることを確かめて初めて役に立ちます。テスト用のデータベースとディレクトリに戻す例です。

STAMP=20261110-0030
mkdir -p /tmp/wp-restore
tar -xzf "/mnt/backup/files-$STAMP.tar.gz" -C /tmp/wp-restore
gunzip -c "/mnt/backup/db-$STAMP.sql.gz" | mysql --defaults-extra-file=/root/.wp-backup.cnf wordpress_test

STAMP は戻したいバックアップのファイル名に合わせます。テスト環境でサイトが表示され、ログインできることを確かめてから、本番の復元に使います。

運用の注意

• NFS だけに頼らない: NFS は WordPress サーバーから常に書き込める場所なので、サーバーが乗っ取られたり、誤って削除コマンドを実行したりすると、バックアップも消される可能性があります。NAS 側のスナップショット機能や、別の場所（クラウドストレージなど）への複製を組み合わせます。
• 同じ建物の障害: NFS サーバーが同じデータセンターや同じ建物にある場合、火災や停電では両方が止まります。遠隔地への控えも用意します。
• 共有先を絞る: /etc/exports は IP アドレスで許可する範囲を絞り、rw と * を組み合わせないようにします。
• 容量を監視する: 保存先の空き容量が無くなると書き込みが失敗します。KEEP_DAYS と1回分の大きさから、必要な容量を見積もっておきます。

まとめ

• NFS サーバーでは許可するクライアントを IP アドレスで指定し、root_squash と anonuid で書き込みユーザーを決める
• クライアントは /etc/fstab に _netdev 付きで登録し、再起動後もマウントされるようにする
• スクリプトは mountpoint -q で未マウントを検出して止め、.part の名前で書いてから正式な名前に変える
• 世代は find -mtime で整理し、cron の実行結果はログで確認する
• NFS は同じネットワーク内の保存先なので、スナップショットや遠隔地への複製と組み合わせる

関連記事:

• WordPressのデータベースバックアップをcronで自動化する方法
• WordPressのバックアップテストと復元確認の方法
• WordPressのバックアップ整合性チェックを自動化する方法