ブログの下書き作業に使っているMacのフォルダを眺めていたら、こんな名前のファイルが並んでいました。

wp_draft.py
wp_draft.py.bak-20261018
wp_draft.py.bak-20261018b
wp_draft.py.bak-20261024

wp_draft.py は、WordPressへ下書きを送るための小さなプログラムです。その下にある .bak-日付 が付いたものは、書き換える前に残したコピーです。

ぱっと見ると散らかっているようですが、読み返してみると、これがなかなか便利な記録になっていました。今回は、ファイルを書き換える前に日付入りのコピーを残す方法を、Macのターミナルを初めて触る方にも分かるようにまとめます。

「消してしまった」は、たいてい「上書きした」

ファイルのトラブルというと、うっかり削除を思い浮かべるかもしれません。でも実際に多いのは、内容を書き換えて保存したら、前の状態に戻せなくなったというものです。

私のブログにも、形の違う記録が2つ残っていました。

1つは2017年の「メールソフトThunderbirdのデータが消えた？」です。起動すると初期画面になっていて驚きましたが、データ自体は残っていて、設定ファイルの prefs.js が書き換わっていました。今の prefs.js を prefs.js-bak に改名し、同じ場所にあった日付の新しい prefs-2.js を prefs.js にしたら元に戻りました。

もう1つは2026年10月の、WordPressの記事の話です。開きっぱなしにしていた古い編集画面で保存してしまい、7か月分の追記が消えました。このときはWordPressの「リビジョン」のおかげで取り戻せました。

どちらも助かったのは、前の状態がどこかに残っていたからです。ただ、手元のファイルには、WordPressのリビジョンのような仕組みが最初から付いているわけではありません。

Web制作の仕事でも、サーバー上のファイルを直す前に別名でコピーを取るのは昔からの基本です。コピーを取るコマンドは1行

Macのターミナルでは、cp（コピー）というコマンドを使います。

cp -p wp_draft.py wp_draft.py.bak-20261104

「wp_draft.py を、wp_draft.py.bak-20261104 という名前でコピーする」という意味です。これだけで保険ができます。

-p は、ファイルの更新日時などを元のまま引き継ぐオプションです。付けないと、コピーした時刻が更新日時になります。テスト用のファイルで試したところ、次のように違いが出ました。

Oct 18 09:00  sample.py（元のファイル）
Oct 18 09:00  sample.py.bak-20261104（-p を付けたコピー）
Nov  4 05:39  sample.py.bak-plain（-p なしのコピー）

日付を毎回打つのが面倒なら、今日の日付を自動で入れることもできます。

cp -p wp_draft.py wp_draft.py.bak-$(date +%Y%m%d)

$(date +%Y%m%d) の部分が 20261104 のような今日の日付に置き換わります。

名前の付け方で、あとから読める記録になる

実際のフォルダの中で、いちばん新しいコピーを ls -l で見ると、こう表示されます（見やすいように一部省略しています）。

14455  Oct 24 06:38  wp_draft.py
14385  Oct 18 18:28  wp_draft.py.bak-20261024

名前の日付は「10月24日に直す前のコピー」、更新日時は「中身が最後に変わったのは10月18日」と読めます。1つのファイルから、2つの情報が分かるわけです。

日付を入れておく良さは、ほかにもあります。

• 名前順に並べると、古いものから順に並ぶ
• 「いつの時点の版か」を開かなくても分かる
• 「この日に何かを直した」という作業の目印になる

日付を先頭に付けるファイル名の話は以前の記事にも書きましたが、コピーの場合は元の名前を先頭に残し、末尾に日付を足しています。元のファイルのすぐ下に並ぶので、対応関係が一目で分かるからです。

同じ日に2回取るときは要注意

ここが、いちばんの落とし穴です。cp は、コピー先に同じ名前のファイルがあっても、何も聞かずに上書きします。

同じ日に2回修正すると、1回目のコピーが2回目の状態で上書きされて、せっかくの保険が消えてしまいます。私のフォルダに -20261018b や -20261017b のように b の付いたファイルがあるのは、同じ日に2回コピーを取った跡です。

うっかり上書きが心配なら、-n を付けます。

cp -np wp_draft.py wp_draft.py.bak-20261104

-n は「同じ名前があれば上書きしない」というオプションです。同じ名前のコピーがある状態で試したところ、中身は元のまま変わりませんでした。その場合は末尾に b を付けるなど、別の名前で取り直します。

フォルダごとコピーするときは -R を足します。

cp -Rp 作業フォルダ 作業フォルダ.bak-20261104

直した後は diff で「何が変わったか」を見る

コピーを残しておくと、もう1つ良いことがあります。diff（ディフ）というコマンドで、新旧の違いだけを表示できるのです。

diff wp_draft.py.bak-20261024 wp_draft.py

実際に試すと、現在の版との違いは2行（古い行と新しい行が1行ずつ）だけでした。< で始まるのが古い行、> で始まるのが新しい行です。この修正は、本文の画像がURLで書かれているときに、手元のファイルとして扱わないようにするものでした。

他のコピーと比べた差分の行数も出してみました。

| 比べたコピー | 現在の版と違う行数 |
|---|---|
| wp_draft.py.bak-20261018 | 12行 |
| wp_draft.py.bak-20261018b | 4行 |
| wp_draft.py.bak-20261024 | 2行 |

数字が小さくなっていくので、少しずつ手を入れてきた流れが見えます。別のプログラムのコピーでは84行、25行と、もっと大きく違うものもありました。

最近はこうした修正をAIに手伝ってもらうことが増えました。AIが書き換えた内容を、ざっと自分の目で確かめる手段としても diff は役に立ちます。

元に戻すときも、今の状態を残してから

戻すのも cp です。ただし、いきなり戻すと今の状態が消えるので、先に今の版にも名前を付けておくと安心です。

cp -p wp_draft.py wp_draft.py.before-restore
cp -p wp_draft.py.bak-20261024 wp_draft.py

10月18日に、記事の本文から不要な横線を取り除く作業をしたときも、同じ考え方でした。articles/backup というフォルダに、直す前のHTMLが14個残っています。ファイル名に before-remove-hr（横線を消す前）のように、何をする前のコピーかを入れてあるので、あとから見ても理由が分かります。

【要確認：これらのコピーから実際に元へ戻した経験があるか。あれば、そのときの話を追記】

この方法でカバーできないこと

手軽な方法ですが、万能ではありません。

1. Macそのものの故障には効かない

コピーが同じMacの中にあるので、本体が壊れれば一緒に失われます。Macには外付けディスクなどに自動でバックアップを取るTime Machineという機能があるので、役割を分けて考えるのがよいと思います。

2. コピーは増え続ける

.bak ファイルは放っておくと増えます。プログラムが安定して、もう戻さないと判断できたら整理しましょう。ただ、あわてて消すこともありません。文字だけのファイルなら、数個あっても容量はほとんど気にならない大きさです。

3. パスワードが入ったファイルは増やさない

パスワードや認証情報を入れたファイルのコピーを作ると、それだけ気を配る場所が増えます。こうしたファイルは、気軽にコピーしないほうが無難です。

4. 本格的な履歴管理にはGitがある

変更履歴をきちんと管理する道具として、Gitという仕組みがあります。ただ、私のこの作業フォルダはGitを使っていません。個人の小さな作業なら、まずは cp 1行から始めるのでもよいと思います。

まとめ

書き換える前のコピーは、時間にすれば数秒の作業です。

1. 書き換える前に cp -p 元の名前 元の名前.bak-日付 でコピーを取る
2. 同じ日に2回取るときは、上書きに注意する（-n を付ける、名前に b を足す）
3. 直した後は diff で変更箇所を確かめる
4. 戻す前には、今の状態にも別の名前を付けておく
5. Mac本体の故障に備えるバックアップは別に考える

フォルダに並んだ .bak ファイルは、一見すると片付け忘れのようです。でも読み返すと、いつ、どこを直してきたのかが分かる作業の記録でもありました。大事なファイルに手を入れる前に、まず1行、試してみてください。