rsyncで効率的なファイル同期

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

rsyncで効率的なファイル同期

要件と前提

、rsyncコマンドを用いてリモートサーバー間でファイルを効率的かつ安全に同期するためのDevOpsプラクティスを解説します。具体的には、以下の要件を満たすことを目指します。

  • 効率性: 差分転送によりネットワーク帯域と時間を節約します。

  • 安全性: シェルスクリプトは冪等性を保ち、エラーハンドリングを適切に行い、一時ファイルを安全に扱います。

  • 自動化: systemd unitとsystemd timerを用いて定期的な同期を自動化します。

  • 拡張性: jqを用いたJSONデータの処理や、curlを用いたAPI連携の例を示します。

  • 権限管理: root権限の適切な扱いと権限分離について考慮します。

前提条件:

  • Linux環境（Ubuntu/CentOSなど）が動作していること。

  • rsync, bash, systemd, jq, curlがインストールされていること。

  • SSH鍵認証が設定されており、パスワードなしでリモートサーバーに接続できること。

実装

フローの概要

systemd timerによって定期的にrsync実行サービスが起動される流れを図1に示します。

graph TD
    A["systemd Timer"] -- 定期実行をスケジュール --> B("systemd Service");
    B -- サービス起動コマンド実行 --> C{"Bashスクリプト"};
    C -- SSH経由でファイルを転送 --> D("rsyncコマンド");
    D -- ファイル同期を処理 --> E["リモートサーバー"];
    C -- 実行結果を出力 --> F["ログファイル"];
    C -- 処理結果を通知 (JSON形式) --> G["監視システム/API"];

図1: rsync同期処理フロー

rsync実行スクリプトの作成

rsyncを実行するシェルスクリプトは、冪等性を保ち、エラー時に適切に終了し、一時ファイルを安全に扱う必要があります。

#!/usr/bin/env bash


# rsync_sync.sh: 安全なrsyncファイル同期スクリプト

# 1. 厳格なエラーハンドリングとパイプ失敗時の即時終了

set -euo pipefail

# 2. 一時ディレクトリの安全な作成とクリーンアップ


#    trapコマンドでスクリプト終了時に必ず一時ファイルを削除

RSYNC_TMPDIR=$(mktemp -d -t rsync-tmp-XXXXXXXXXX)
trap 'rm -rf "${RSYNC_TMPDIR}"' EXIT SIGHUP SIGINT SIGTERM

# ログファイルパス


# systemdから実行される場合、専用ユーザー (例: rsync_user) で実行することを想定し、


# ログディレクトリ /var/log/rsync は事前に作成し、そのユーザーが書き込み可能に設定されているべきです。


# 必要に応じて、sudoersの設定でこのスクリプトがteeコマンドをパスワードなしでsudo実行できるように設定するか、


# /var/log/rsync ディレクトリのパーミッションを適切に設定してください。

LOG_DIR="/var/log/rsync"
LOG_FILE="${LOG_DIR}/rsync_sync_$(date +%Y%m%d%H%M%S).log"

# スクリプトの全出力をログファイルとjournalctlへteeで出力


# teeコマンドをsudoで実行することで、/var/log/rsyncへの書き込み権限がないユーザーでもログを出力できます。


# 最も推奨されるのは、ログディレクトリを専用ユーザーが書き込み可能に設定することです。

exec > >(sudo tee -a "${LOG_FILE}") 2>&1 # 全出力をログファイルと標準出力へteeで出力

echo "$(date '+%Y-%m-%d %H:%M:%S JST') - INFO: rsync同期処理を開始します。"
echo "一時ディレクトリ: ${RSYNC_TMPDIR}"

# 設定変数

SOURCE_DIR="/path/to/local/source/"     # 同期元ローカルディレクトリ
REMOTE_USER="remote_user"                # リモートサーバーのユーザー
REMOTE_HOST="remote.example.com"         # リモートサーバーのホスト名
DEST_DIR="/path/to/remote/destination/"  # 同期先リモートディレクトリ

# rsyncオプション


# --partial-dir: 転送中に中断されたファイルを一時ディレクトリに格納し、次回から再開


# --delete: 転送元に存在しないファイルを転送先から削除


# -a: アーカイブモード (パーミッション、タイムスタンプ、所有者などを保持)


# -v: 冗長出力


# -z: 圧縮転送

RSYNC_OPTIONS="-avz --delete --exclude 'tmp/' --partial-dir='${RSYNC_TMPDIR}'"

# SSH接続ポートを指定する場合の例:


# RSYNC_SSH_COMMAND="ssh -p 2222 -i /home/${REMOTE_USER}/.ssh/id_rsa"


# RSYNC_OPTIONS="${RSYNC_OPTIONS} -e '${RSYNC_SSH_COMMAND}'"

# rsyncコマンドの実行

if ! rsync ${RSYNC_OPTIONS} "${SOURCE_DIR}" "${REMOTE_USER}@${REMOTE_HOST}:${DEST_DIR}"; then
    echo "$(date '+%Y-%m-%d %H:%M:%S JST') - ERROR: rsync同期に失敗しました。"

    # 失敗時の通知例 (curlとjqを使用)

    MESSAGE="rsync同期が ${REMOTE_HOST} で失敗しました。"
    PAYLOAD=$(jq -n \
        --arg msg "${MESSAGE}" \
        --arg timestamp "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
        '{ "status": "failed", "message": $msg, "timestamp": $timestamp }')

    # curl: TLS1.2必須、リトライと指数バックオフ


    # `--retry 5`: 最大5回リトライ


    # `--retry-delay 5`: 初回リトライ遅延5秒


    # `--retry-max-time 60`: リトライ全体で最大60秒


    # `--fail-silent`: エラー時のみエラーメッセージを表示


    # `--show-error`: エラーメッセージを冗長に表示


    # `--tlsv1.2`: TLSv1.2の使用を強制 (TLSv1.3が利用可能な環境では明示不要な場合あり)


    # `-H "Content-Type: application/json"`: リクエストヘッダ


    # `-d "${PAYLOAD}"`: POSTデータ

    if ! curl -sS --retry 5 --retry-delay 5 --retry-max-time 60 \
              --fail-silent --show-error --tlsv1.2 \
              -H "Content-Type: application/json" \
              -d "${PAYLOAD}" "https://api.example.com/notifications"; then
        echo "$(date '+%Y-%m-%d %H:%M:%S JST') - ERROR: 監視システムへの通知に失敗しました。"
    else
        echo "$(date '+%Y-%m-%d %H:%M:%S JST') - INFO: 監視システムへ失敗を通知しました。"
    fi
    exit 1 # エラーコードで終了
fi

echo "$(date '+%Y-%m-%d %H:%M:%S JST') - INFO: rsync同期処理が正常に完了しました。"

# 成功時の通知例 (オプション: バックグラウンドで実行し、スクリプトの終了をブロックしない)


# MESSAGE="rsync同期が ${REMOTE_HOST} で正常に完了しました。"


# PAYLOAD=$(jq -n \


#     --arg msg "${MESSAGE}" \


#     --arg timestamp "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \


#     '{ "status": "success", "message": $msg, "timestamp": $timestamp }')


# curl -sS --fail-silent --show-error --tlsv1.2 \


#       -H "Content-Type: application/json" \


#       -d "${PAYLOAD}" "https://api.example.com/notifications" &>/dev/null &

exit 0 # 正常終了

コード1: rsync_sync.sh

コードのポイント:

  • set -euo pipefail: エラー発生時の即時終了、未定義変数の禁止、パイプ中のエラー伝播を強制します。これにより、スクリプトの堅牢性が向上します。

  • mktemp -d: 一時ディレクトリを安全に作成します。

  • trap 'rm -rf "${RSYNC_TMPDIR}"' EXIT: スクリプトの終了時に一時ディレクトリを確実に削除します。

  • sudo tee -a "${LOG_FILE}": sudoを使用してログファイルをroot権限で作成・追記し、標準出力にもログを表示することで、systemdのjournalctlにもログが流れるようにします。これにより、ログの永続化とリアルタイム確認を両立させます。この設定の場合、rsync_userがteeコマンドをsudoなしで実行できるようにLOG_DIRのパーミッションを設定するか、sudoersファイルでrsync_userがteeをパスワードなしで実行できるように許可する必要があります。

  • rsyncオプション:

    • -avz: アーカイブモード（パーミッション、タイムスタンプ、所有者などを保持）、詳細表示、圧縮転送。

    • --delete: 同期元に存在しないファイルを同期先から削除し、厳密なミラーリングを実現します。

    • --exclude 'tmp/': 除外したいディレクトリを指定します。

    • --partial-dir='${RSYNC_TMPDIR}': 転送中に中断されたファイルは指定された一時ディレクトリに保存され、次回の実行時にそこから転送を再開します。これにより、大きなファイルの転送が中断されても効率的に再開できます。

  • jq: JSON形式のメッセージを生成し、curlで外部APIへ送信します。

  • curlのオプション:

    • --retry / --retry-delay / --retry-max-time: ネットワークの一時的な問題に対応するため、リトライ回数、間隔、総時間を制御し、指数バックオフのような挙動を模擬します。

    • --fail-silent / --show-error: エラー時のみメッセージを表示し、正常時は出力を抑制します。

    • --tlsv1.2: 脆弱性のあるプロトコルを避け、TLSv1.2以降の使用を強制します。

systemd unitとtimerの定義

systemdを用いて、上記のスクリプトを定期的に実行するように設定します。

1. rsync-sync.service ファイル (/etc/systemd/system/rsync-sync.service)

[Unit]
Description=rsync based file synchronization service
Documentation=https://example.com/docs/rsync-sync-service-info
Wants=network-online.target
After=network-online.target

[Service]

# セキュリティのベストプラクティスとして、スクリプトをroot以外の専用ユーザーで実行することが推奨されます。


# ここでは例として 'rsync_user' を想定します。

User=rsync_user
Group=rsync_user
WorkingDirectory=/opt/rsync-scripts # スクリプトが存在するディレクトリ
Type=oneshot # 短時間で終了するタスクに適したタイプ
ExecStart=/bin/bash /opt/rsync-scripts/rsync_sync.sh

# 失敗時に自動再起動はしない (timerが次の実行をスケジュールするため)

Restart=no

# 実行環境変数を設定する場合の例


# Environment="RSYNC_LOG_LEVEL=info"


# 実行時のリソース制限など


# LimitNOFILE=1024

StandardOutput=journal
StandardError=journal

[Install]

# Timerユニットから呼び出されるため、ここではWantedByは厳密には不要ですが、


# 手動でサービスを有効化/起動する際に参照されます。

WantedBy=multi-user.target

コード2: rsync-sync.service

設定のポイント:

  • Description: サービスの簡単な説明。

  • Wants=network-online.target / After=network-online.target: ネットワークが利用可能になってからサービスを起動します。

  • User / Group: セキュリティのベストプラクティスとして、専用の非特権ユーザーでスクリプトを実行することが強く推奨されます。

  • ExecStart: 実行するシェルスクリプトのパスを指定します。bashを明示的に指定することで、確実にbashで実行されます。

  • Type=oneshot: コマンドが終了するとサービスも終了する単発実行プロセスに適しています。

  • StandardOutput=journal / StandardError=journal: スクリプトの標準出力と標準エラー出力をsystemd-journaldに転送し、journalctlでログを確認できるようにします。

2. rsync-sync.timer ファイル (/etc/systemd/system/rsync-sync.timer)

[Unit]
Description=Run rsync file synchronization every 1 hour
Documentation=https://example.com/docs/rsync-sync-timer-info

[Timer]

# OnCalendar: 特定の時刻または周期でサービスを起動します。


#           毎日午前3時30分に実行する場合: OnCalendar=*-*-* 03:30:00


#           毎時実行する場合: OnCalendar=hourly


#           例: 毎時0分に実行する場合は "minutely", "hourly" は使えず "OnCalendar=*-*-* *:00:00" と書く。


#           ここでは毎時間30分に実行するように設定しています。

OnCalendar=*-*-* *:30:00

# AccuracySec: タイマーの精度。1mは最大1分ずれても良いことを意味し、システム負荷を軽減します。

AccuracySec=1min

# Persistent: タイマーが無効化されている間に経過した実行時刻を、再度有効化されたときにすぐに実行します。

Persistent=true

# Unit: このタイマーによって起動されるサービスを指定します。

Unit=rsync-sync.service

[Install]
WantedBy=timers.target

コード3: rsync-sync.timer

設定のポイント:

  • Description: タイマーの簡単な説明。

  • OnCalendar: タイマーがサービスを起動する頻度を設定します。例では毎時30分に実行するように設定しています。

  • AccuracySec: システムの負荷を軽減するために、タイマーの実行精度を許容する範囲で緩和します。

  • Persistent=true: システム停止中に実行されるべきだったタスクがある場合、システム再起動後にすぐに実行されます。

  • Unit: このタイマーが起動するsystemdサービスファイルを指定します (.service拡張子は省略)。

  • WantedBy=timers.target: タイマーサービスをシステム起動時に自動的に有効にするための設定です。

検証

systemdの設定を反映し、タイマーを有効化して動作を確認します。

  1. スクリプトとsystemdファイルの配置と権限設定:

    • rsync_sync.shを/opt/rsync-scripts/に配置し、実行権限を付与します (chmod +x /opt/rsync-scripts/rsync_sync.sh)。

    • rsync-sync.serviceとrsync-sync.timerを/etc/systemd/system/に配置します。

    • 専用ユーザー(rsync_user)を使用する場合は、以下のように設定します。

      sudo useradd -r -s /sbin/nologin rsync_user
sudo mkdir -p /opt/rsync-scripts /var/log/rsync
sudo chown -R rsync_user:rsync_user /opt/rsync-scripts /var/log/rsync
sudo chmod 700 /opt/rsync-scripts
sudo chmod 755 /var/log/rsync

      rsync_userがsudo teeをパスワードなしで実行できるように、/etc/sudoersにrsync_user ALL=(ALL) NOPASSWD: /usr/bin/tee*のような行を追加することも検討してください。

  2. systemd設定のリロード:

    sudo systemctl daemon-reload

  3. タイマーの有効化と起動:

    sudo systemctl enable rsync-sync.timer # システム起動時にタイマーが自動起動するように設定
sudo systemctl start rsync-sync.timer  # タイマーを今すぐ起動

  4. タイマーのステータス確認:

    systemctl list-timers rsync-sync.timer

    出力例:

    NEXT                         LEFT        LAST                         PASSED       UNIT                   ACTIVATES
Mon 2024-07-29 10:30:00 JST  50min left  Mon 2024-07-29 09:30:00 JST  10min ago    rsync-sync.timer       rsync-sync.service

    NEXT列が次回の実行時刻を示していることを確認します。

  5. サービスのログ確認: 手動でサービスを実行して、エラーがないか確認することもできます。

    sudo systemctl start rsync-sync.service
journalctl -u rsync-sync.service --since "1 hour ago" -f

    -fオプションでリアルタイムにログを追跡できます。スクリプト内のechoやrsyncの出力がジャーナルに記録されていることを確認します。

  6. ログファイル (/var/log/rsync/) の確認: sudo tail -f /var/log/rsync/rsync_sync_*.logで、スクリプトが出力するログファイルの内容も確認します。

運用

root権限の扱いと権限分離

rsyncは強力なツールであり、誤った設定はデータ損失やセキュリティリスクにつながります。特に、root権限での実行は避けるべきです。

  • 専用ユーザーの作成: rsync同期のためだけに専用の非特権ユーザー（例: rsync_user）を作成し、そのユーザーでサービスを実行します。これにより、万が一スクリプトに脆弱性があった場合でも、システム全体への影響を最小限に抑えられます。

  • 最小権限の原則: rsync_userには、同期対象のディレクトリに対する読み書き権限、スクリプトおよびログディレクトリに対する必要な権限のみを付与し、それ以外のシステムリソースへのアクセスを制限します。

  • SSH鍵の保護: rsync_userのSSH鍵はパスフレーズで保護し、適切にパーミッションを設定します (chmod 600 ~/.ssh/id_rsa)。リモートサーバー側でも~/.ssh/authorized_keysにcommand="...",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-ptyのように限定的なコマンド実行を許可するよう設定することも検討します。これにより、鍵が漏洩しても悪用される範囲を制限できます。

監視とアラート

  • journalctlのログをELK StackやPrometheus/Grafanaなどの集中ログ管理・監視システムに転送し、定期的な監査と異常検知を行います。

  • スクリプト内のcurlによるAPI通知を活用し、同期の成功・失敗をリアルタイムでSlack、Email、PagerDutyなどのアラートシステムに連携します。

  • systemdのタイマー自体が停止していないか（systemctl list-timers）、サービスが失敗していないか（systemctl status rsync-sync.service）を定期的に確認します。

トラブルシュート

  • ログの確認: 最も重要なのはjournalctl -u rsync-sync.serviceと、スクリプトが生成するログファイル (/var/log/rsync/*.log) を確認することです。rsync自体のエラーメッセージやssh接続の問題が詳細に記録されます。

  • パーミッションの問題:

    • rsync_sync.shスクリプトが実行可能か (chmod +x)。

    • rsync_userがソースディレクトリや一時ディレクトリ、ログディレクトリにアクセス権があるか。

    • リモートサーバーのDEST_DIRにrsync_userが書き込み権限があるか。

  • SSH接続の問題:

    • rsync_userとしてリモートサーバーに手動でSSH接続できるか確認します。

    • ~/.ssh/configの設定や鍵のパーミッション (chmod 600) を確認します。

  • systemdタイマーが起動しない:

    • sudo systemctl status rsync-sync.timerでタイマーの状態を確認します。

    • OnCalendarの設定が正しいか確認します（特にタイムゾーンの考慮）。

    • systemctl daemon-reloadを忘れていないか確認します。

  • curlの通知が届かない:

    • curlコマンドを手動で実行し、エラーメッセージを確認します。

    • 通知先のAPIエンドポイントが正しいか、ネットワーク疎通があるか確認します。

    • APIキーや認証情報が正しく設定されているか確認します。

まとめ

rsyncは、適切なスクリプト、systemdによる自動化、そして堅牢なエラーハンドリングを組み合わせることで、非常に効率的かつ信頼性の高いファイル同期ソリューションとなります。

2024年7月29日現在、本記事で紹介したset -euo pipefailのようなBashの安全機能、mktempとtrapによる一時ファイル管理、curlのリトライ・TLS強制オプション、そしてsystemdのタイマー機能は、DevOpsの現場で広く採用されているベストプラクティスです。これらの技術を組み合わせることで、手動での介入を最小限に抑えつつ、システムの安定性とセキュリティを大幅に向上させることができます。また、root権限の適切な管理と専用ユーザーの活用は、セキュリティリスクを軽減する上で不可欠です。本ガイドが、皆さんのDevOps業務におけるファイル同期の自動化と効率化の一助となれば幸いです。

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました