# 交接筆記刪錯，最新備份也沒了？restic 找回舊版的 100 份實測

- 網址：https://blog.valenvan.uk/posts/restic-restic.html
- 發布日期：2026-10-22
- 測試設備：Mac mini M4 Pro（12 核、64GB）
- 專案：restic/restic（https://github.com/restic/restic），BSD-2-Clause 授權
- 測試版本：restic 0.14.0
- 實測影片：https://www.youtube.com/shorts/y5ZIohzuzg4

## 重點摘要

- 100份自製筆記先備份，刪1份、覆寫1份後再備份，保留兩個快照。
- 還原最新快照得到99份，誤刪檔案不存在。
- 選回第一版還原，100／100份路徑與SHA256一致，誤刪檔與舊內容均恢復。
- 輸入錯密碼時exit 1拒絕讀取；未測手機、雲端或硬碟故障。
- **結論：** 事先保留快照且選對時間點，本次100份自製筆記可完整還原。
- **適合：** 願意使用命令列，需保留文件歷史的人
- **不適合：** 期待一鍵救回從未備份檔案的人

| 實測項目 | 結果 |
|---|---|
| 第一版 | 100份 |
| 最新還原 | 99份 |
| 第一版還原 | 100／100內容一致 |
| 錯密碼 | exit 1 |

假設你每週整理一次工作筆記，把以為過期的檔案刪掉。隔天同事問起上週交接內容，你才發現刪錯；偏偏昨晚又做過一次備份。這時最想知道的不是備份工具有哪些功能，而是：最新備份也沒有那份文件，還能不用重寫嗎？這是示意情境，以下結果來自自製資料測試，並非真實工作文件事故。

關鍵在於誤刪之前是否已留下備份，以及舊時間點是否仍保留。restic 的這次測試保留兩個快照，也就是兩個不同時間點的文件狀態。第二次備份後，第一版仍在；但若只還原最新版本，拿到的自然是誤刪之後的狀態。工具不會猜哪一份才是你真正需要的版本。

## 先建立可以核對的答案

測試設備：Mac mini M4 Pro（12 核、64GB）。受測版本為 restic 0.14.0，非最新版。沿用 2026-10-22 原片的真實測試與錄影，這次只重做敘事及圖示動畫，沒有重新跑陌生程式，也沒有新增手機、硬碟故障或雲端實測。動畫呈現測試結果，不是操作介面或新錄影。

原測先製作一百份繁體中文小筆記，保存各自的相對路徑及 SHA256，才能在還原後確認內容一致。第一輪備份留下一百份；接著刪掉一份、覆寫另一份，再做第二輪備份，來源剩九十九份，備份庫仍保留兩個快照。

```bash
restic -r /tmp/restic-demo/backup init
restic -r /tmp/restic-demo/backup backup /tmp/restic-demo/notes --json
restic -r /tmp/restic-demo/backup snapshots --json
```

這些是原測核心指令，路徑是自製示範資料，不是可以直接照抄的個人備份設定。初始化與存取需要密碼，正式使用時必須安排自己的備份位置與密碼保存方式。

![最新備份只保存誤刪後的99份，並非工具漏備份](https://blog.valenvan.uk/img/restic-restic-article_1.png)

## 為什麼要選回第一版

先還原 latest，只得到九十九份，刪掉的文件確實不存在。這不是還原失敗，而是選到錯誤時間點：第二版就是少一份的樣子。改選第一個快照，再還原到另一個資料夾，才有機會拿回需要的舊內容，也避免直接覆蓋現在的文件。

```bash
restic -r /tmp/restic-demo/backup restore latest --target /tmp/restic-demo/latest
restic -r /tmp/restic-demo/backup restore <誤刪前的快照ID> --target /tmp/restic-demo/restored
```

原測的來源是絕對路徑，還原目錄內會包含來源路徑層次；核對時實際進入還原的筆記目錄，再逐份比較，不能只看目標根目錄就下結論。

| 原測項目 | 結果 |
|---|---|
| 第一版備份 | 100 份，0.735 秒 |
| 刪1份、覆寫1份後再備份 | 99 份，0.745 秒 |
| 還原最新版本 | 99 份，誤刪檔不存在 |
| 還原第一版 | 100 份，0.747 秒 |
| 路徑與內容指紋 | 100／100 完全一致 |
| 錯密碼讀取 | exit 1，拒絕讀取 |

![第一版還原後，100份內容全部一致](https://blog.valenvan.uk/img/restic-restic-article_2.png)

連被覆寫的舊文字都找回，才是這次真正有用的結論。時間來自單次小樣本，不代表整碟或照片庫速度；原錄影重跑的首次備份為0.711秒、第一版還原為0.792秒，不混成同一次量測，也不挑最快數字宣傳。

## 我會拿來做什麼

若經常修改工作文件，願意使用命令列，我會考慮用 restic 保留可選擇的歷史版本。若只想手機一鍵救回從沒備份過的檔案，這次沒有證明那種能力。錯密碼被拒絕也只是存取測試，不能當完整安全稽核。

另外，同一顆硬碟壞掉時，文件及同處備份都可能失去；這次沒有驗證異地備援、自動排程、大量資料或硬體故障。要減少重寫交接筆記的麻煩，先在事情發生前備份，再練習選對時間點、另存還原，才是可帶走的作法。

專案：[restic/restic](https://github.com/restic/restic)。授權：BSD-2-Clause。原測證據、實錄與版本資料保留於本成品的 evidence 目錄；原始修改意見另存，沒有公開發布。