Rocky Linuxで暗号化フルバックアップを自動化し、Google Driveへ安全に保存する

クラウド RockyLinux運用メモ

本記事は筆者の指示・構成に基づき、AI（ChatGPT）によって生成されています。
内容は筆者が確認・修正を行っていますが、AI生成であることを理解した上でご利用ください。

はじめに（この記事の目的）

本記事では、筆者がLinux系サーバーを運用・学習する中で確認・検証・記録した内容を整理します。
同じ作業を行う方が再現できるよう、背景・目的・手順・注意点を丁寧に解説します。
筆者の学習記録であると同時に、実用的なガイドとして活用できる構成です。

この記事の対象

  • Linux系OSでサーバーを自己管理している方
  • コマンドや設定の目的を理解しながら安全に操作したい方
  • 実践的な例と検証手順を知りたい方

作業環境

  • OS：Linux系OS（x86_64 相当）
  • 接続方法：SSH（公開鍵認証）
  • ユーザー：一般ユーザー（sudo権限あり）

この記事の目的と概要

本記事ではバックアップ確認の安全運用（暗号化＋クラウド保存）と日次検証に関する設定・確認・操作方法を解説します。
以下の流れで進めます。

  • 作業前の確認と前提整理
  • ステップごとの具体的手順
  • コマンドとその解説
  • 作業前後の比較
  • 安全策と復旧方法

実施手順（ステップ解説）

ステップ1：作業前の状態確認

# 目的：OSカーネルや主要サービスの稼働状況を確認（※サービス名は環境に合わせて置換）
# 用語：カーネル（OSの中核部分）
uname -r
sudo systemctl status web.service db.service ids.service firewall.service --no-pager

# 目的：ディスクとサイト領域のサイズ目安を把握（※サイトパスは環境に合わせる）
df -h
sudo du -sh /srv/www/site /etc /home

# 目的：rclone・GPG・wp-cliなど前提コマンドの導入確認
rclone version
gpg --version
wp --info 2>/dev/null || echo "wp-cli未導入"

本節では、変更作業の前にサーバーの基本情報を確認します。
カーネルは再起動後の反映有無の判断材料です。
主要サービスの稼働はセキュリティと可用性に直結します。
rclone（クラウド連携ツール）とGnuPG（暗号化ツール）はバックアップの前提です。
wp-cli（WordPress操作ツール）は更新確認に利用します。

出力例:
X.Y.Z-...-generic
● web.service - Web Server
     Active: active (running)
● db.service - Database Server
     Active: active (running)
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda2        25G  3.8G   20G  17%  /
128M   /srv/www/site   24M   /etc   80K   /home
rclone v1.xx.x
gpg (GnuPG) 2.3.x
WP-CLI version: 2.x.x

ステップ2：バックアップ（暗号化→クラウド保存）の実装

# 目的：フルバックアップスクリプトを配置（/usr/local/bin/full_backup.sh）
# 基本構文：teeでファイル作成 → 実行権限付与
# 主なオプション：mysqldump --single-transaction、tar --exclude、gpg --symmetric、rclone copy
sudo tee /usr/local/bin/full_backup.sh >/dev/null <<'SH'
#!/usr/bin/env bash
set -Eeuo pipefail
BK_ROOT="/secure/backup/path/daily"
NOW="$(date +%F_%H%M%S)"
RETENTION_DAYS=7
RCLONE_REMOTE="remote:Backup"
SITE_ROOT="/srv/www/site"
TARGETS=("/etc" "$SITE_ROOT" "/home")
log(){ echo "[$(date +%F_%T)] $*"; }
trap 'log "ERROR: line $LINENO で失敗"; exit 1' ERR
mkdir -p "$BK_ROOT" && chmod 700 "$BK_ROOT"
log "Start backup at $NOW"

# DBダンプ（環境の認証方法に合わせて設定ファイル等を利用）
if mysql -e "SELECT 1;" >/dev/null 2>&1; then
  GETDBS=(mysql -N -e)
  DUMP=(mysqldump --single-transaction --quick --routines --triggers)
else
  GETDBS=() ; DUMP=()
fi
if [ ${#GETDBS[@]} -gt 0 ]; then
  DBS="$("${GETDBS[@]}" "SHOW DATABASES;" | grep -Ev '^(information_schema|performance_schema|sys)$' || true)"
  for db in $DBS; do log "Dump DB: $db"; "${DUMP[@]}" "$db" > "$BK_ROOT/${db}_${NOW}.sql"; done
fi

# ファイルアーカイブ（自己巻き込みと機密は除外）
tar \
  --exclude="$BK_ROOT" \
  --exclude="${SITE_ROOT}/wp-content/cache" \
  --exclude="${SITE_ROOT}/wp-content/uploads/cache" \
  -czf "$BK_ROOT/files_${NOW}.tar.gz" "${TARGETS[@]}"

# インストールパッケージ一覧
rpm -qa | sort > "$BK_ROOT/packages_${NOW}.txt"

# 暗号化（パスフレーズファイルは改行なし・600）
PASSPHRASE_FILE="/secure/secret/backup_passphrase"
[ -f "$PASSPHRASE_FILE" ] || { log "ERROR: $PASSPHRASE_FILE not found. Create it (600)."; exit 1; }
log "[Encrypt] GPG symmetric AES256"
for f in "$BK_ROOT"/*"${NOW}"*; do
  [ -f "$f" ] || continue
  gpg --batch --yes --symmetric --cipher-algo AES256 \
      --passphrase-file "$PASSPHRASE_FILE" \
      -o "${f}.gpg" "$f"
  shred -u "$f"
done

# チェックサム
( cd "$BK_ROOT" && sha256sum *"${NOW}"*.gpg > "SHA256SUMS_${NOW}.txt" )

# クラウド送信（rcloneリモート名は一般化）
log "Upload to $RCLONE_REMOTE"
rclone copy "$BK_ROOT" "$RCLONE_REMOTE" --transfers=4 --checkers=8

# ローカル世代管理
log "Prune local > ${RETENTION_DAYS}d"
find "$BK_ROOT" -type f -mtime +${RETENTION_DAYS} -delete

log "Backup OK at $NOW"
SH
sudo chmod 700 /usr/local/bin/full_backup.sh

# 目的：バックアップの自動実行（毎日深夜帯の任意時刻の例：03:00）
# 基本構文：rootのcrontabにジョブ追加
( sudo crontab -l; echo '0 3 * * * /usr/local/bin/full_backup.sh >> /var/log/backup/full_backup.log 2>&1' ) | sudo crontab -

# 目的：暗号化パスフレーズを安全に作成（改行なし・600）
sudo mkdir -p /secure/secret
sudo bash -c 'echo -n "例:Use-Strong-Secret" > /secure/secret/backup_passphrase'
sudo chmod 600 /secure/secret/backup_passphrase
sudo mkdir -p /var/log/backup && sudo touch /var/log/backup/full_backup.log

本節では、バックアップの自動化と暗号化を実装します。
rclone（クラウド連携）でクラウド側へアップロードし、GnuPG（暗号化）で漏えいを防ぎます。
cron（定期実行）で毎日深夜帯にバックアップが動作します。
tarでは自己巻き込み防止のためバックアップ保存先を除外し、機密ファイルは含めない方針です。

出力例:
[YYYY-MM-DD_HH:MM:SS] Start backup at YYYY-MM-DD_HHMMSS
[Encrypt] GPG symmetric AES256
[YYYY-MM-DD_HH:MM:SS] Upload to remote:Backup
[YYYY-MM-DD_HH:MM:SS] Backup OK at YYYY-MM-DD_HHMMSS

ステップ3：作業後の状態確認

# 目的：ローカル成果物の確認（.gpgとSHA256SUMS）
sudo -i
ls -lh /secure/backup/path/daily | tail
cd /secure/backup/path/daily
LATEST_SUM=$(ls -1t SHA256SUMS_*.txt | head -n1)
sha256sum -c "$LATEST_SUM" | head

# 目的：復号テスト（DBダンプの先頭を確認）
gpg --batch --yes --decrypt \
    --passphrase-file /secure/secret/backup_passphrase \
    "$(ls -1t /secure/backup/path/daily/appdb_*.sql.gpg | head -n1)" | head

# 目的：クラウド側の確認（rcloneのcheck）
rclone check /secure/backup/path/daily remote:Backup

本節では、暗号化済み成果物とハッシュ整合性を確認します。
復号テストにより、実際に復元可能なバックアップであることを確かめます。
rcloneのcheckでローカルとクラウドの差分がないことを検証します。

出力例:
files_YYYY-MM-DD_HHMMSS.tar.gz.gpg: OK
appdb_YYYY-MM-DD_HHMMSS.sql.gpg: OK
-- MariaDB dump ...
NOTICE: remote 'Backup': 0 differences found

作業前後の比較

項目作業前作業後
バックアップ方式未整備または平文保存GPG暗号化＋クラウド二重保存（汎用リモート名）
自動実行未設定cronで毎日深夜帯に実行（時刻は例示）
整合性確認未実施SHA256SUMSで検証
復元手順未整備DB/ファイルの復元コマンドを整備（パスはダミー）
機密ファイル混入混入の懸念ありtarで保存先と機密を除外

使用したコマンド一覧と解説

コマンド目的解説
mysqldumpDBダンプ基本構文：mysqldump [--single-transaction] DB名 > dump.sql。
InnoDBの整合性を保つため--single-transactionを使用します。
tarファイル圧縮基本構文：tar -czf アーカイブ名.tar.gz 対象。
--excludeで保存先や機密を除外します。
gpg暗号化基本構文：gpg --symmetric --cipher-algo AES256 -o 出力.gpg 入力。
復号はgpg --decrypt 入力.gpgです。
sha256sum整合性検証基本構文：sha256sum ファイル > SHA256SUMS.txt。
検証はsha256sum -cです。
rcloneクラウド転送基本構文：rclone copy ローカル リモート:。
--transfersや--checkersで並列度を調整します。
crontab定期実行基本構文：分 時 日 月 曜 コマンド。
深夜帯の任意時刻で日次実行します。
systemctlサービス確認基本構文：systemctl status サービス。
環境に合わせてサービス名を指定します。

安全策と復旧方法

  • 安全策：暗号化パスフレーズは/secure/secret/backup_passphraseに保存し、権限600で管理します。
    内容は改行なしで、サーバー外のパスワードマネージャにも保管します。
  • 安全策：tarでは$BK_ROOT、秘密情報、設定ファイルディレクトリなどを除外します。
    具体パスは公開用には記載しません。
  • 復旧方法（DB）：gpg --decrypt appdb_*.sql.gpg | mysql -u <USER> -p <DBNAME>で復元します。
    接続情報は環境変数や設定ファイルで安全に渡します。
  • 復旧方法（ファイル）：gpg --decrypt files_*.tar.gz.gpg | tar -xz -C /で展開し、必要に応じて所有権・サービス再起動を行います。

注意点・落とし穴

  • パスフレーズに改行が含まれると復号で戸惑ったため、echo -nで作成します。
  • クラウドリモート名や保存先の実名公開は避けます。
    公開用資料では一般化した名称を使用します。
  • バックアップ保存先を除外しないと、tarで自己巻き込みが発生しエラーになりやすいです。
  • 具体的なOS・カーネル・サービス名・時刻は公開時に抽象化します。

まとめ

本記事ではバックアップ確認の安全運用（暗号化＋クラウド保存）と日次検証を解説しました。
作業前後での比較と安全策を意識することで、トラブルを未然に防げます。
読者のLinux運用の一助になれば幸いです。

実践課題

  1. 月に一度、復号テスト（DBのみ）を実施し、手順を記録します。
    公開用資料では具体パスを記載しない方針を徹底します。
  2. 週に一度、検証ログを点検します。
    通知連携（メールやチャット）を用いてエラー検知を自動化します。

関連記事

参考リンク