ファイル移動の上書き事故をゼロにして安全に整理する実務手順

上書き事故を一発で防ぐ「バックアップ付き移動」の基本

mv はデフォルトで移動先に同名ファイルがあると黙って上書きします。確認プロンプトは出ず、元のファイルは即消滅です。これを防ぐには -b（--backup）オプションを付けるだけです。

# 移動先に同名ファイルがある場合、既存ファイルをバックアップしてから移動する
mv -b app.conf /etc/myapp/

移動先に app.conf がすでに存在していた場合、既存ファイルは app.conf~（末尾にチルダ）という名前で退避され、その後に新しいファイルが配置されます。

# 実行後の移動先ディレクトリを確認する例
$ ls -l /etc/myapp/
-rw-r--r-- 1 user user 2048 Jul 10 09:00 app.conf    ← 移動されてきたファイル
-rw-r--r-- 1 user user  512 Jul  9 18:20 app.conf~   ← 上書き前の既存ファイル（バックアップ）

チルダバックアップと番号付きバックアップの違いと使い分け

-b のデフォルト（simple モード）はチルダ付き一世代のみ残す方式です。同じ操作を複数回繰り返すと、前のバックアップが上書きされて消えます。世代管理が必要な場面では --backup=numbered を使います。

# 番号付きバックアップ：.~1~, .~2~ と連番で残る
mv --backup=numbered nginx.conf /etc/nginx/

# 3回実行後の状態イメージ
# nginx.conf       ← 最新
# nginx.conf.~1~  ← 1回目の既存ファイル
# nginx.conf.~2~  ← 2回目の既存ファイル
# nginx.conf.~3~  ← 3回目の既存ファイル

設定ファイルのデプロイを自動化していて同じファイルパスへ繰り返し配置するケースでは、番号付きバックアップが確実です。各世代が追跡できるため、ロールバックが容易になります。

バックアップ方式は --backup の引数で明示的に指定できます。主な選択肢は以下のとおりです。

mv --backup=simple   file dest/   # チルダ一世代（-b と同義）
mv --backup=numbered file dest/   # 番号付き連番バックアップ
mv --backup=existing file dest/   # 番号付きバックアップが既存ならnumbered、なければsimple
mv --backup=none     file dest/   # バックアップなし（デフォルト動作と同じ）

バックアップファイルの拡張子（サフィックス）を変えるには

チルダ付きのファイルは ls のグロブパターンやスクリプトの処理で扱いにくいことがあります。--suffix オプションで任意の文字列に変更できます。

# バックアップファイルの末尾を .bak にする
mv -b --suffix=.bak nginx.conf /etc/nginx/
# 結果: /etc/nginx/nginx.conf（新）、/etc/nginx/nginx.conf.bak（旧）

# バックアップに日付を入れて世代を識別しやすくする
mv -b --suffix=".$(date +%Y%m%d)" nginx.conf /etc/nginx/
# 結果: /etc/nginx/nginx.conf.20260710

環境変数 SIMPLE_BACKUP_SUFFIX にサフィックスをセットしておくと、そのシェルセッション中はすべての mv -b に自動で適用されます。作業前にまとめて設定しておくと効率的です。

export SIMPLE_BACKUP_SUFFIX=.bak
mv -b conf.d/default.conf /etc/nginx/conf.d/
mv -b conf.d/ssl.conf     /etc/nginx/conf.d/

複数ファイルを一括で安全に移動するパターン

複数ファイルを対象にした場合も -b は有効です。移動先に既存ファイルがあるものだけが選択的にバックアップされ、存在しないファイルはそのまま移動されます。

# カレントディレクトリのすべての .conf ファイルを一括移動
mv -b *.conf /etc/myapp/

# find と組み合わせてサブディレクトリ含むファイルを移動する
find ./conf.new -name "*.conf" -exec mv -b {} /etc/myapp/ \;

ある運用現場では、Ansibleで管理しきれない「手動差し替え」の場面で --suffix=".$(date +%Y%m%d_%H%M)" のように時刻まで入れ、バックアップファイルに分単位のタイムスタンプを持たせる運用が定着しているケースがあります。どの作業でいつ差し替えたかが一目瞭然になり、障害発生時の原因特定が速くなります。

注意点と実務でよくある落とし穴

チルダバックアップは一世代しか残らない：同じパスへ mv -b（simple）を2回実行すると、1回目のバックアップが2回目で上書きされます。古い世代を保持したいなら --backup=numbered に切り替えてください。

スクリプト内でのエイリアス問題：多くのディストリビューションでは ~/.bashrc に alias mv='mv -i'（対話確認）が設定されています。シェルスクリプトから mv を呼び出す際にエイリアスが展開されると、インタラクティブでない実行環境でハングアップすることがあります。スクリプト内では command mv またはフルパス /usr/bin/mv を使ってください。

#!/bin/bash
# スクリプト内でエイリアスを無効化して安全に呼び出す
command mv -b --suffix=.bak "$src" "$dest"

# またはフルパス指定
/usr/bin/mv -b --suffix=.bak "$src" "$dest"

クロスファイルシステムの移動：mv は同一ファイルシステム内であれば iノードのリネームだけで完了しますが、パーティションをまたぐ場合（例: /tmp → /home）はコピー＋削除になります。大容量ファイルでは時間がかかるうえ、コピー中に中断すると中途半端なファイルが残ります。そのようなケースでは rsync --remove-source-files を検討する場面もあります。

本番環境での作業前確認：/etc 配下など本番ファイルを操作する前は、ls -la 移動先/ で現状を必ず確認してから実行してください。-b でバックアップを作っても、root 権限で誤って削除すれば取り戻せません。バックアップファイルの扱いも操作手順の一部として意識してください。