オンプレミスのLinuxサーバーからAzure Storageへ大量データを送るとき、「azcopyを前面で起動してしまった、いまから裏送りしたい」というニーズは現場あるあるです。本稿は“途中から完全に安全なバックグラウンド化はできるのか”という根本の疑問に答えつつ、実運用で事故らないためのベストプラクティスと、やむを得ないときの応急処置、管理・監視・再開の詳しい手順まで一気通貫でまとめました。
結論（要点）
- 実行中のazcopyプロセスを、そのまま安全・確実にバックグラウンド化する方法はありません。TTY（端末）に結びついたままのプロセスを後付けで切り離すのは設計上リスクが高く、途中で止まる・ログを失う・整合性が崩れる可能性があります。
- 最善策は「停止 → ジョブ再開（resume） or 再投入」です。azcopyはジョブ管理機構を持ち、
azcopy jobs resume <JobID>で差分再開できます。 - 転送をこれから始めるなら、
nohupやscreen/tmuxから起動し、ログと計画ファイルを安全な場所に置く設計にしましょう。
背景：なぜ“いま走っているもの”を裏へ回せないのか
シェルから起動したプロセスは、標準入出力（stdin/stdout/stderr）と制御端末（controlling TTY）に紐づきます。SSH切断やログアウト時には多くのシェルがSIGHUPを送出し、bgだけではプロセスが落ちることがあります。「bg + disown」でSIGHUPを無視させる応急処置はありますが、すでにTTYにぶら下がっているI/Oや、シグナルの伝播、ジョブ制御の整合性の問題は残るため、長時間転送の安定運用には不向きです。したがって、転送の信頼性を優先するなら一度止めて再開が定石です。
シナリオ別：推奨アクション早見表
| シナリオ | 推奨アクション | 補足説明 |
|---|---|---|
| 転送をこれから開始する場合 | nohup azcopy copy '/path/to/files/*' \ 'https://<storage>.blob.core.windows.net/container?<SAS>' \ --recursive=true > /var/log/azcopy/azcopy.log 2>&1 & | nohup：ログアウトや切断でもプロセスが終了しない。 &：バックグラウンド実行。 標準出力・標準エラーはログへリダイレクト（例：/var/log/azcopy/azcopy.log）。 進捗確認：tail -f /var/log/azcopy/azcopy.log |
| すでに前面で動いている場合 | ps aux | grep azcopyでPIDを確認。 再開可能な設計にした上で、kill <PID>（基本は-TERM。どうしても止まらない時のみ-9）。 上記のnohup &方式、またはscreen/tmuxで再実行。 | azcopyはジョブ管理を備え、azcopy jobs resume <JobID>で差分再開可能。 既存プロセスをそのまま裏に回す完全に安全な手段はないため、再起動が基本方針。 |
| 長時間転送を安定させたい場合 | screenやtmuxセッション内からazcopyを起動 | セッションをデタッチしても後で再接続できるため、SSH切断に強い。 |
実運用フロー：安全に止めて、確実に再開する
1. 実行中ジョブの把握とジョブIDの確認
azcopyは開始時にジョブID（英数字）を付与します。開始メッセージを逃した場合も、次で一覧できます。
azcopy jobs list
azcopy jobs show <JobID> --with-status=All--with-status=Allで処理済み／未処理の進捗も把握できます。
2. 実行中プロセスの安全停止
いきなり-9は避け、まずはSIGTERM（またはSIGINT）で穏当に止め、ジョブ計画ファイルの整合性を保ちます。
ps -o pid,ppid,cmd -C azcopy
kill -TERM <PID> # 反応がなければ -INT、最終手段で -9停止後、azcopy jobs listで対象ジョブがInProgressまたはFailed等の状態で残っていることを確認します。
3. ジョブの差分再開
azcopy jobs resume <JobID> \
--log-level INFO \
--cap-mbps 0--cap-mbps：帯域制限。ネットワークの輻輳や切断を減らしたい場合に有効（0は無制限）。--log-level：INFO/WARNING/ERRORなど。
再開で使う資格情報（SAS/アカウントキー/ログイン）は、初回時と同じ方法が適用されます。長時間の転送ではSASの有効期限切れに注意（開始前に十分なTTLで発行する）。
最初から強い：nohup / screen / tmux の基本設計
nohupで最小構成
install -d -m 755 /var/log/azcopy
export AZCOPY_LOG_LOCATION=/var/log/azcopy
export AZCOPY_JOB_PLAN_LOCATION=/var/log/azcopy/plan # 計画ファイルの保存先
install -d -m 700 "$AZCOPY_JOB_PLAN_LOCATION"
nohup azcopy copy '/data/bulk/*'
'https://.blob.core.windows.net/archive?'
--recursive=true
--log-level=INFO
> /var/log/azcopy/azcopy.log 2>&1 &
echo "PID: $!"AZCOPY_LOG_LOCATIONとAZCOPY_JOB_PLAN_LOCATIONを専用ディレクトリに固定すると、トラブル時の調査・再開が容易です（デフォルトはホーム配下~/.azcopy）。
screenで堅牢に
# 新規セッション（名前付き）を作る
screen -S azcopy01
# セッション内で実行
azcopy copy '/data/bulk/*'
'https://.blob.core.windows.net/archive?'
--recursive=true
# デタッチ：Ctrl-a d
# 再接続：screen -r azcopy01
# セッション一覧：screen -lsサーバー再起動時に自動復旧させたい場合は、systemdのユーザーサービスでscreen/tmuxを起動し、その中でジョブを走らせる設計も有効です（再投入の仕組みをスクリプト化するのがコツ）。
tmuxでモダンに
tmux new -s azcopy01
# 中でazcopyコマンド実行
# デタッチ：Ctrl-b d
tmux attach -t azcopy01
tmux ls応急処置（非推奨だが知っておくと助かる）
どうしても今すぐSSHを切断しないといけない、しかし止めたくない——そんな局面のカンフル剤です。いずれも自己責任・非推奨で、長時間・大容量の運用には向きません。
- bg + disown：
Ctrl-Z→bg %1→disown -h %1でSIGHUPを無視。ただしTTYに紐づくI/Oやシェルの状態次第で落ちることがあり、確実性は担保できません。 - reptyr：既存プロセスを別の端末に“引越し”するツール。セキュリティ設定やカーネルのptrace制限で失敗しやすく、プロダクションでは推奨しません。
上記はあくまで“今だけ凌ぐ”手段です。安全第一なら、やはり停止→resumeに切り替えましょう。
品質と整合性：エラーに強い設計
ログと計画ファイルの扱い
AZCOPY_LOG_LOCATION：ログ保存先。監視対象に。AZCOPY_JOB_PLAN_LOCATION：ジョブ計画（plan）保存先。消さないこと（resumeに必要）。- 長期運用ではroot以外の専用ユーザーや専用パス（例：
/var/lib/azcopy）を用意し、権限を最小化。
ログローテーション例
# /etc/logrotate.d/azcopy
/var/log/azcopy/azcopy.log {
weekly
rotate 12
copytruncate
compress
missingok
notifempty
}帯域・CPU・I/Oの制御
--cap-mbpsで転送帯域の上限を設定。ネットワークの混雑や他業務への影響を緩和。AZCOPY_CONCURRENCY_VALUE（環境変数）で並列度を明示調整。CPUやディスクI/Oとのバランスを取る。- Linuxの
nice/ioniceでスケジューリング優先度を下げ、業務影響をさらに低減。
AZCOPY_CONCURRENCY_VALUE=32 \
nice -n 10 ionice -c2 -n7 \
nohup azcopy copy '/data/bulk/*' 'https://...?...' --recursive \
> /var/log/azcopy/azcopy.log 2>&1 &整合性オプション
- アップロード時：
--put-md5でコンテンツMD5を計算・格納（性能低下とトレードオフ）。 - ダウンロード時：
--check-md5 FailIfDifferentなどで整合性検証。 - 再実行時に重複を避けたいなら、上書き動作（
--overwrite）のポリシーやsyncコマンドの活用を検討。
copy と sync の使い分け
copy：指定範囲を送る。再実行で同名があると上書きのポリシー次第で再転送される。sync：差分同期志向。削除の扱い（--delete-destination）やメタデータの同期挙動を理解した上で採用。
「一度止めてresume → それでも残差がある」場合は、syncで最終整合性を取るときれいに仕上がります。
エラーハンドリングと再試行の型
- ネットワーク切断・一時的な5xxはazcopyが自動リトライしますが、頻発するなら
--cap-mbpsや並列度を下げて安定化。 - 権限エラー（403）はSASのスコープ/有効期限/許可（w・c・dなど）を再確認。長期ジョブでは余裕を持った有効期限が鉄則。
- ディスク不足は計画ファイルやログの退避ディレクトリを十分な空き容量のある領域に。
監視：進捗の見える化
# ログの追跡
tail -f /var/log/azcopy/azcopy.log | sed -n 's/.*Throughput:.*/&/p'
# 件数やエラーの抽出例
grep -E "INFO|ERROR|WARN" /var/log/azcopy/azcopy.log | tail
# 途中状況をジョブ一覧で確認
azcopy jobs list
azcopy jobs show --with-status=Allセキュリティ実務メモ
- SASトークンの最小権限化：必要な操作だけ許可（例：アップロードのみならWrite/Create）。
- 有効期限管理：推定所要時間＋マージンで設定。更新が必要になりそうなら、早めに止めてresume。
- 発行元の保護：SASをファイルに保存する場合はパーミッション
600程度を徹底。
よくある失敗と回避策
| 症状 | 原因 | 対策 |
|---|---|---|
| SSH切断でジョブが消える | 前面実行でTTYに紐づいたまま | 最初からnohupまたはscreen/tmuxで起動。既に走っていれば停止→jobs resume。 |
| 再実行で重複アップロード | copyの上書きルール理解不足 | jobs resumeを優先。最終整合はsyncで。 |
| 長時間ジョブで途中失敗 | 帯域飽和やSAS期限切れ | --cap-mbpsで抑制、SASの期限を長めに。途中なら一度停止し、期限延長後にresume。 |
| ログが巨大化 | 単一ファイルに出力し続け | logrotateを設定。AZCOPY_LOG_LOCATIONを専用ディレクトリへ。 |
実行テンプレート（コピペで使える雛形）
安全設計版（nohup＋環境変数）
#!/usr/bin/env bash
set -Eeuo pipefail
SRC_DIR="/data/bulk"
DST_SAS_URL="https://.blob.core.windows.net/?"
LOG_DIR="/var/log/azcopy"
PLAN_DIR="/var/lib/azcopy/plan"
install -d -m 755 "$LOG_DIR"
install -d -m 700 "$PLAN_DIR"
export AZCOPY_LOG_LOCATION="$LOG_DIR"
export AZCOPY_JOB_PLAN_LOCATION="$PLAN_DIR"
export AZCOPY_CONCURRENCY_VALUE="${AZCOPY_CONCURRENCY_VALUE:-32}"
TS="$(date +%Y%m%d-%H%M%S)"
LOG_FILE="$LOG_DIR/azcopy-${TS}.log"
echo "[INFO] start azcopy at $TS"
nohup azcopy copy "${SRC_DIR}/*" "$DST_SAS_URL"
--recursive=true
--log-level=INFO
--cap-mbps=0
> "$LOG_FILE" 2>&1 &
PID=$!
echo "[INFO] pid=$PID log=$LOG_FILE"停止→再開のワンライナー
# 優しく止める
kill -TERM <PID>
# 直近ジョブを特定してresume（例）
JOB=$(azcopy jobs list | awk '/JobId/ {print $2}' | head -1)
azcopy jobs show "$JOB" --with-status=All
azcopy jobs resume "$JOB" --log-level=INFOFAQ（現場の疑問に即答）
Q：Ctrl‑Z → bg → disown なら行けますか？
A：短時間の回避には効くことがありますが、安全性は保証できません。大容量・長時間では停止→resumeが鉄則です。
Q：途中でSAS期限が切れました。resumeできますか？
A：可能です。期限を延ばしたSASで再度認証できるよう整え、jobs resumeを実行してください。開始前に十分なTTLを確保しておくと安心です。
Q：copyとsync、どちらを使うべき？
A：初回はcopyでOK。中断からのjobs resumeで仕切り直し、仕上げにsyncで差分の最終整合を取る構成が実務で安定します。
Q：ジョブ計画ファイルを消してしまいました。
A：jobs resumeが使えず、再スキャン・再転送のコストが増します。計画ファイルは消さない運用に徹してください。
まとめ：最初から「裏送り前提」で設計する
- 新規ジョブは
nohupまたはscreen/tmuxで起動し、ログと計画ファイルを安全な場所へ。 - 実行中ジョブの“後付け裏送り”は設計上リスキー。停止→jobs resumeが本筋。
- 帯域・並列度・ログローテーション・SAS期限など、長時間運用の落とし穴を事前に潰す。
この方針に立てば、「途中で安全に裏へ回す方法」に悩む時間はゼロになり、転送の完了率と再現性が劇的に上がります。現場で最も痛いのは“止まっていたことに気づかない”事故です。設計と運用を先回りし、堅牢なデータ移行を実現しましょう。
付録：チェックリスト（そのまま使える）
| 項目 | 推奨設定/確認 | 備考 |
|---|---|---|
| 起動方法 | nohup or screen/tmux | 前面起動は避ける |
| ログ出力 | AZCOPY_LOG_LOCATIONを固定、logrotate | 監視対象に |
| 計画ファイル | AZCOPY_JOB_PLAN_LOCATIONを固定 | resumeに必須、消さない |
| 帯域制御 | --cap-mbps、AZCOPY_CONCURRENCY_VALUE | 他業務の影響最小化 |
| SAS期限 | 所要時間＋マージン | 期限切れは失敗の王道 |
| 最終整合 | jobs resume → 必要に応じsync | 重複/漏れをゼロに |
補足：質問と解決策の要点（再掲）
以下は冒頭の要点を、現場で見返しやすい形で整理し直したものです。
| シナリオ | 推奨アクション | 補足説明 |
|---|---|---|
| 転送をこれから開始する場合 | nohup azcopy copy '/path/to/files/*' \ 'https://<storage>.blob.core.windows.net/container?<SAS>' \ --recursive=true > azcopy.log 2>&1 & | nohup：ログアウトや切断でもプロセスが終了しない。 &：バックグラウンド実行。 標準出力・標準エラーはazcopy.logにリダイレクト。 進捗確認はtail -f azcopy.log。 |
| すでに前面で動いている場合 | ps aux | grep azcopyでPIDを確認。 転送が再開可能であればkill <PID>（必要なら-9）で停止。 上記nohup &方式、またはscreen / tmuxで再実行。 | azcopyは再実行時に同じジョブIDを指定すれば差分再開可能（azcopy jobs resume <JobID>）。 既存プロセスをそのまま裏に回す安全な手段はないため、再起動が基本方針。 |
| 長時間転送を安定させたい場合 | screenやtmuxセッション内からazcopyを起動 | セッションをデタッチしても後で再接続できるため、SSH切断に強い。 |
最後に：これだけは守る三箇条
- 最初から裏送り前提で起動する。（
nohupまたはscreen/tmux） - ログと計画ファイルを固定ディレクトリに置き、消さない。
- 中断は怖くない。止めてから
jobs resumeで確実に戻す。
この3点を徹底するだけで、夜間バッチや休日の大容量移行でもヒヤリを大幅に減らせます。今日からの運用に、ぜひ取り入れてください。
コメント