2026年9月10日

2026年9月10日

WordPressのバックアップをテープ(LTO)に保存する手順|tar・mt・復元確認

テープ(LTO)へのバックアップは、ふだんはサーバーから切り離して保管できるため、サーバーごと暗号化されるランサムウェアや操作ミスの影響を受けにくい保管先です。長期保管が必要な場合や、オンラインのバックアップとは別にオフラインの控えを持ちたい場合に使います。

この記事では、Linux サーバーにつないだテープドライブへ、WordPress のデータベースとファイルを書き込む手順を説明します。

前提と構成

  • テープドライブは、自社で管理する物理サーバーに SAS などで接続して使います。レンタルサーバーや一般的な VPS にはテープドライブをつなげません。その場合は、Web サーバーで作ったバックアップをテープドライブのあるサーバーへ転送してから書き込みます。
  • コマンドは Debian / Ubuntu と RHEL 系(AlmaLinux、Rocky Linux など)を想定しています。
  • テープの容量は LTO の世代ごとに異なります。書き込むデータの合計がテープ1本に収まるかを先に確認してください。

テープデバイスの名前と mt コマンド

Linux ではテープドライブが次の2つの名前で見えます。

デバイス 動作 使いどころ
/dev/st0 閉じるたびに先頭へ巻き戻す 1本に1つのアーカイブだけ書く場合
/dev/nst0 閉じても巻き戻さない 1本に複数のアーカイブを追記する場合

/dev/st0 に追記のつもりで書くと、毎回先頭から上書きされます。この記事では、追記と位置合わせができる /dev/nst0 を使います。

テープの位置を動かすには mt コマンドを使います。パッケージは mt-st です。

# Debian / Ubuntu
sudo apt install mt-st

# RHEL 系
sudo dnf install mt-st

# ドライブとテープの状態を確認する
sudo mt -f /dev/nst0 status

よく使う操作は次のとおりです。

コマンド 動作
mt -f /dev/nst0 rewind 先頭へ巻き戻す
mt -f /dev/nst0 eod 記録済みデータの終わりへ移動する(追記の前に使う)
mt -f /dev/nst0 fsf 2 ファイルマークを2つ進める(3つ目のアーカイブの先頭へ)
mt -f /dev/nst0 eject 巻き戻して取り出す

tar で /dev/nst0 に書き込むと、アーカイブの終わりにファイルマークが付きます。fsf はこのファイルマークを数えて移動するので、何番目に何を書いたかを記録しておくと、後から目的のアーカイブを読み出せます。

手順1: バックアップするファイルを用意する

テープに書く前に、データベースとファイルを1つのディレクトリにまとめます。データベースの接続情報は、コマンドラインに書かずに設定ファイルに置きます。

/root/.wp-backup.cnf(chmod 600 にする):

[client]
user=wp_backup
password=change-this-password
DAY=$(date +%Y%m%d)
DIR=/var/backups/wordpress/$DAY
mkdir -p "$DIR"

# データベース(InnoDB をロックせずに整合した状態で書き出す)
mysqldump --defaults-extra-file=/root/.wp-backup.cnf --single-transaction \
  --default-character-set=utf8mb4 wordpress > "$DIR/db.sql"

# WordPress のファイル一式
tar -czf "$DIR/files.tar.gz" -C /var/www/html .

# 復元時に壊れていないか確かめるためのチェックサム
cd "$DIR" && sha256sum db.sql files.tar.gz > SHA256SUMS

wordpress の部分は wp-config.php の DB_NAME、/var/www/html は WordPress を置いたディレクトリに合わせます。--defaults-extra-file は mysqldump の最初のオプションとして書く必要があります。

なお、tar -czf で作った圧縮済みのアーカイブには、tar -r で後からファイルを追加できません。データベースのダンプとファイルのアーカイブは、上のように別のファイルとして並べておきます。

手順2: テープに書き込む

# 記録済みデータの終わりへ移動する
sudo mt -f /dev/nst0 eod

# 日付のディレクトリごとテープに書き込む
sudo tar -cvf /dev/nst0 -C /var/backups/wordpress "$DAY"

新しいテープに初めて書くとき、または古い内容を消して最初から書き直すときは、eod の代わりに mt -f /dev/nst0 rewind で先頭へ戻してから書き込みます。

ここでは tar の -z(gzip 圧縮)を付けていません。中身の files.tar.gz はすでに圧縮されており、LTO ドライブは書き込み時にドライブ側で圧縮する機能も持っています。

手順3: 書き込んだ内容を確かめる

書き込みが終わったら、テープから読み出せるかを確かめます。ここでは、テープの1つ目のアーカイブを確認する例を示します。

sudo mt -f /dev/nst0 rewind

# 一覧を表示できるか
sudo tar -tvf /dev/nst0

# ディスク上の元ファイルと中身が一致するか
sudo mt -f /dev/nst0 rewind
sudo tar -dvf /dev/nst0 -C /var/backups/wordpress

tar -d(--compare)は、アーカイブ内のファイルとディスク上のファイルを比べ、違いがあれば表示します。何も違いが出なければ、書き込んだ内容は元と一致しています。2つ目以降のアーカイブを確かめるときは、rewind の後に fsf で位置を合わせてから実行します。

手順4: スクリプトにしてcronで自動化する

手順1〜2をスクリプトにまとめます。

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

#!/bin/bash
set -euo pipefail

WP_PATH=/var/www/html
DB_NAME=wordpress
STAGE=/var/backups/wordpress
TAPE=/dev/nst0
DAY=$(date +%Y%m%d)
DIR="$STAGE/$DAY"

mkdir -p "$DIR"
mysqldump --defaults-extra-file=/root/.wp-backup.cnf --single-transaction \
  --default-character-set=utf8mb4 "$DB_NAME" > "$DIR/db.sql"
tar -czf "$DIR/files.tar.gz" -C "$WP_PATH" .
( cd "$DIR" && sha256sum db.sql files.tar.gz > SHA256SUMS )

mt -f "$TAPE" eod
tar -cf "$TAPE" -C "$STAGE" "$DAY"
echo "$(date '+%F %T') wrote $DAY to $TAPE"

# ディスク上の作業用コピーは7日分だけ残す
find "$STAGE" -mindepth 1 -maxdepth 1 -type d -mtime +7 -exec rm -rf {} +
sudo chmod 700 /usr/local/sbin/wp-tape-backup.sh

cron には /etc/cron.d/ にファイルを置いて登録します。/var/spool/cron/ の中のファイルを直接書き換えるのではなく、crontab -e か /etc/cron.d/ を使ってください。

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

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

cron の行の中に date +%Y%m%d を直接書く場合は、% を \% と書かないと改行として扱われます。日付の処理はスクリプトの中に置くと、この問題を避けられます。

テープが容量いっぱいになると tar はエラーで止まり、ログにエラーが残ります。ログを定期的に確認し、テープを入れ替える運用(曜日ごと・週ごとに別のテープを使うなど)を決めておきます。

手順5: テープから復元する

3つ目に書いたアーカイブを、一時ディレクトリに取り出す例です。

sudo mt -f /dev/nst0 rewind
sudo mt -f /dev/nst0 fsf 2
sudo mkdir -p /tmp/wp-restore
sudo tar -xvf /dev/nst0 -C /tmp/wp-restore

# チェックサムで壊れていないかを確かめる
cd /tmp/wp-restore/20261110 && sha256sum -c SHA256SUMS

20261110 は取り出した日付のディレクトリ名に置き換えます。チェックサムがすべて OK になったら、files.tar.gz をテスト用のディレクトリに展開し、db.sql をテスト用のデータベースに読み込んで、サイトが表示されるかを確かめます。

mysql --defaults-extra-file=/root/.wp-backup.cnf wordpress_test < /tmp/wp-restore/20261110/db.sql

本番に戻す前に、テスト環境で表示とログインができることを確かめてください。復元の練習は、実際に必要になる前に定期的に行います。

保管と運用の注意

  • 書いたテープは取り出して別の場所に保管する: ドライブに入れたままでは、サーバーと同じ障害や攻撃の影響を受けます。
  • 保管環境: 温度・湿度の条件は、テープメーカーが示す範囲に従います。
  • 持ち出すテープの中身を守る: データベースには会員情報やパスワードのハッシュが含まれます。テープを社外へ持ち出す場合は、ドライブの暗号化機能や、書き込む前のファイルの暗号化を検討し、鍵はテープと別に管理します。
  • 記録を残す: どのテープの何番目に、いつのバックアップを書いたかを記録しておかないと、復元のときに探せません。

まとめ

  • 追記するときは巻き戻さない /dev/nst0 を使い、mt eod で終わりへ移動してから書く
  • 圧縮済みの tar には後から追加できないので、データベースとファイルは別ファイルにしてまとめて書く
  • 書いた後は tar -t と tar -d で読み出せるか、元と一致するかを確かめる
  • 自動化は /etc/cron.d/ とスクリプトで行い、日付の % はスクリプト側で扱う
  • 復元はチェックサムを確かめてからテスト環境で行い、テープは別の場所に保管する

関連記事:

お気軽にご相談ください

お見積りへ お問い合わせへ
▲