用 BLAKE3 校验 17 图库 2.7GB 备份，比 SHA-256 快 6 倍的那次对比
周四凌晨的卡顿最后定位到移动硬盘的 USB 2.0 口。换成 BLAKE3 后，同样的 3124 个文件，耗时从 11 分钟降到 1 分 48 秒。
江晚04-24
实测条目
8 条 · 按写入时间倒序每条都对应一次真实操作。版本号是我电脑上装的，不是官网最新；失败点写得很细，因为我需要的正是这些细节。
rsync --link-dest 做增量快照，第 7 天为什么还是吃掉了 40GB
理论上硬链接不该复制数据。我用 du -sh 一步步查，发现问题出在图库会改写已有文件名，硬链接指向的 inode 变了。
江晚04-22
图库索引库 index.db 的 3 种导出方式，以及其中 1 种会锁表
.backup 命令安全，VACUUM INTO 更干净，直接 cp 在写入中会拿到半个页。我在 3.42.0 上复现了后者。
江晚04-20
把备份还原到另一台机器：我踩到的字符集与权限两个坑
目标机是 Debian 12，源机是 macOS。文件名里的「·」在两边被编码成不同字节，恢复后 68 个文件显示为乱码。
江晚04-18
Restic、Borg、Duplicity 三家在 17 图库上的实测差异
Restic 0.16.4 增量最省心，Borg 1.2 的 prune 策略最难调，Duplicity 的 GPG 加密让我多花了一晚上才跑通。
江晚04-15
一块 2019 年的西数 My Passport：SMART 里 3 个待映射扇区意味着什么
CrystalDiskInfo 报 C5=3。我没有立刻换盘，而是先做了一次全盘镜像再继续。这个决定对不对，我到现在也不确定。
江晚04-12
一个 14 行的 bash 脚本，每晚 3:10 自动备份并记录日志
cron 里我特意错开整点，因为整点任务堆积会让 3:00 那一批跑不完。日志只保留最近 30 天。
江晚04-09
「备份成功」四个字不可信：我随机抽 5% 文件做恢复验收
3124 个文件里抽 156 个，逐个打开比对缩略图。第一次抽检就发现 2 个文件损坏，而备份日志显示全部成功。
江晚04-05
标签索引
12 个 · 与条目一一对应标签按被引用的次数决定字号大小，不是随手加的装饰。
增量快照
BLAKE3 校验
rsync --link-dest
SQLite .backup
VACUUM INTO
Restic 0.16.4
Borg prune 策略
SMART 待映射扇区
字符集乱码
cron 错峰
恢复抽检 5%
USB 2.0 瓶颈
被翻过最多的
近 30 天统计浏览数来自站内计数器，只统计独立会话，刷新不重复计。
-
用 BLAKE3 校验 17 图库 2.7GB 备份的完整过程 校验 / 哈希 · 04-241,284 次浏览
-
图库索引库 index.db 的 3 种导出方式 SQLite · 04-20962 次浏览
-
把备份还原到另一台机器：字符集与权限两个坑 恢复演练 · 04-18837 次浏览
-
rsync --link-dest 第 7 天吃掉 40GB 的排查 快照 · 04-22715 次浏览
-
随机抽 5% 文件做恢复验收的做法 恢复验证 · 04-05604 次浏览
-
Restic、Borg、Duplicity 三家实测差异 工具对比 · 04-15488 次浏览
-
一块 2019 年西数硬盘的 SMART 待映射扇区 硬件 · 04-12327 次浏览