Linux サーバーのバックアップ方法：rsync・tar と cron・MySQL ダンプ・restic で S3 へ

ディスク障害、誤操作による削除、ランサムウェアなどでデータは一瞬で失われます。確実な Linux サーバーのバックアップは運用の基本です。この記事では、rsync による別サーバーへの同期、tar と cron による定期アーカイブ、MySQL/MariaDB ダンプの自動化と世代管理、restic による S3 互換ストレージへの暗号化バックアップという 4 つの方法を組み合わせ、最後に復元テストを行います。Debian/Ubuntu と Rocky Linux/AlmaLinux に対応しています。

ステップ1：rsync で別サーバーへバックアップ

rsync は差分だけを転送するため、Web ディレクトリや設定ファイルの同期に最適です。バックアップ先に一般ユーザー backup とディレクトリ /backup/web01 を作成し、元サーバーで専用の SSH キーを作成します（「SSH キー」の記事を参照）。--delete は転送先の余分なファイルを削除するので、最初は必ず -n で試してください。

# Install rsync on BOTH servers
apt install -y rsync        # Debian / Ubuntu
dnf install -y rsync        # Rocky Linux / AlmaLinux

# On the source server: dedicated key for backups
ssh-keygen -t ed25519 -f /root/.ssh/backup_key -N ""
ssh-copy-id -i /root/.ssh/backup_key.pub -p 22 [email protected]

# Preview first (-n = dry run), then run for real
rsync -aHn --delete -e "ssh -i /root/.ssh/backup_key -p 22" \
  /etc /var/www [email protected]:/backup/web01/
rsync -aH --delete -e "ssh -i /root/.ssh/backup_key -p 22" \
  /etc /var/www [email protected]:/backup/web01/

ステップ2：tar と cron で定期バックアップ

rsync はミラーなので、元で誤って削除すると次回の同期でバックアップ側からも消えます。そこで日付付きの tar アーカイブを毎日作成し、直近 7 日分を保持します。スクリプトは find -mtime で古いファイルを削除し、cron で毎晩実行します。

cat > /usr/local/bin/backup-files.sh <<'EOF'
#!/bin/bash
set -euo pipefail
DEST=/backup/files
KEEP_DAYS=7
mkdir -p "$DEST"
# tar exit code 1 = "file changed while reading", which is acceptable
tar -czpf "$DEST/files-$(date +%F).tar.gz" /etc /var/www /root || [ $? -eq 1 ]
find "$DEST" -name 'files-*.tar.gz' -mtime +$KEEP_DAYS -delete
EOF
chmod 700 /usr/local/bin/backup-files.sh
/usr/local/bin/backup-files.sh && ls -lh /backup/files

# Schedule: crontab -e
10 3 * * * /usr/local/bin/backup-files.sh >> /var/log/backup.log 2>&1

ステップ3：MySQL/MariaDB の自動バックアップと世代管理

稼働中のデータベースファイルを直接コピーすると壊れたバックアップになりがちです。mysqldump または mariadb-dump でエクスポートしましょう。--single-transaction は InnoDB をロックせずに整合性のあるスナップショットを取得します。スクリプトはデータベースごとにダンプして gzip 圧縮し、14 日分を保持します。パスワードは権限 600 の /root/.my.cnf に置き、コマンドラインやプロセス一覧に表示されないようにします。

# Credentials (skip if root can log in to MariaDB/MySQL via unix_socket)
cat > /root/.my.cnf <<'EOF'
[client]
user=root
password=YourDatabaseRootPassword
EOF
chmod 600 /root/.my.cnf

cat > /usr/local/bin/backup-db.sh <<'EOF'
#!/bin/bash
set -euo pipefail
DEST=/backup/mysql
KEEP_DAYS=14
mkdir -p "$DEST"
CLIENT=$(command -v mariadb || command -v mysql)
DUMP=$(command -v mariadb-dump || command -v mysqldump)
for DB in $("$CLIENT" -N -e "SHOW DATABASES" | grep -Ev '^(information_schema|performance_schema|sys)$'); do
  "$DUMP" --single-transaction --routines --triggers --events "$DB" \
    | gzip > "$DEST/$DB-$(date +%F_%H%M).sql.gz"
done
find "$DEST" -name '*.sql.gz' -mtime +$KEEP_DAYS -delete
EOF
chmod 700 /usr/local/bin/backup-db.sh

# Schedule: crontab -e
20 2 * * * /usr/local/bin/backup-db.sh >> /var/log/backup.log 2>&1

ステップ4：restic で S3 互換ストレージへ暗号化バックアップ

restic は重複排除・暗号化・スナップショットに対応し、AWS S3、Cloudflare R2、MinIO など S3 互換サービスへ保存できます。ステップ3のダンプディレクトリも含めれば、すべてを遠隔地に保管できます。forget --prune で日・週・月単位の保持ポリシーを適用し、容量を解放します。

# Install restic
apt install -y restic                                   # Debian / Ubuntu
dnf install -y epel-release && dnf install -y restic    # Rocky / AlmaLinux

# Repository settings for an S3-compatible bucket
cat > /root/.restic.env <<'EOF'
export AWS_ACCESS_KEY_ID=YOUR_ACCESS_KEY
export AWS_SECRET_ACCESS_KEY=YOUR_SECRET_KEY
export RESTIC_REPOSITORY=s3:https://s3.example.com/my-backup-bucket/web01
export RESTIC_PASSWORD_FILE=/root/.restic.pass
EOF
openssl rand -base64 32 > /root/.restic.pass
chmod 600 /root/.restic.env /root/.restic.pass

. /root/.restic.env
restic init
restic backup /etc /var/www /backup/mysql
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic snapshots

# Schedule: crontab -e
40 3 * * * { . /root/.restic.env && restic backup -q /etc /var/www /backup/mysql && restic forget -q --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune; } >> /var/log/restic.log 2>&1

ステップ5：定期的にリストアをテストする

一度も復元していないバックアップは当てになりません。少なくとも月 1 回、ファイルを一時フォルダへ展開し、ダンプをテスト用データベースへ取り込んで件数を確認し、restic check を実行しましょう。可能であれば新しいサーバーへ丸ごと復元し、所要時間を記録しておきます。

# Files: list an archive and extract one directory to a temp folder
tar -tzf /backup/files/files-2026-10-01.tar.gz | head
mkdir -p /tmp/restore
tar -xzf /backup/files/files-2026-10-01.tar.gz -C /tmp/restore etc/nginx

# Database: import into a throw-away database and compare
mysql -e "CREATE DATABASE restore_test"
gunzip -c /backup/mysql/shop-2026-10-01_0220.sql.gz | mysql restore_test
mysql -e "SELECT COUNT(*) FROM restore_test.orders"
mysql -e "DROP DATABASE restore_test"

# restic: verify the repository and restore the latest snapshot
. /root/.restic.env
restic check
restic restore latest --target /tmp/restic-restore --include /etc/nginx

よくある質問

バックアップでディスクがいっぱいになった

KEEP_DAYS を減らし、キャッシュやログを除外し（tar の --exclude）、バックアップは別サーバーやオブジェクトストレージへ移してください。整理方法は「ディスク容量不足」の記事を参照してください。

cron のジョブが実行されない

/var/log/backup.log と journalctl -u cron（Rocky は crond）を確認します。cron の PATH は最小限なので、スクリプトではフルパスを使い、実行権限を付けてください。

大きなデータベースのダンプでサイトが遅くなりませんか？

InnoDB と --single-transaction ならロックはかかりませんが、ディスク I/O は消費するので深夜などアクセスの少ない時間に実行してください。非常に大きい場合は mariadb-backup や Percona XtraBackup による物理ホットバックアップも検討しましょう。

上記の手順で解決しない場合は、サポートチケットを送信して IMIDC の 24 時間 365 日対応テクニカルサポートへご連絡ください。サーバー IP、OS バージョン、実行したコマンド、エラー全文を添えていただくと、より迅速に調査できます。