真正可靠的 Linux 存储备份必须分层、异构、可验证：本地快照层（LVM/btrfs）支持秒级回退；近线层用 rsync+hardlink 实现多版本增量归档；离线层通过 rclone 加密同步至对象存储并校验；恢复层需每月真机还原测试。
Linux 存储备份不是“配个 rsync 定时任务就完事”，真正可靠的体系必须分层、异构、可验证。单点故障（比如备份盘和源盘共用同一块 主板 SATA 控制器）、静默损坏（bit rot）、误删未及时发现、恢复流程从未实测——这些才是压垮备份的真正原因。
本地快照层：LVM 或 btrfs 的秒级回退能力
这一层解决“刚删错文件”“配置改崩了”这类分钟级恢复需求，不依赖外部设备，延迟低、开销小。
-
lvm快照需在创建逻辑卷时预留足够lvcreate -L 10G -s -n snap_root /dev/vg0/root空间，否则快照写满即失效（snapshot is full错误） -
btrfs子卷快照更轻量：btrfs subvolume snapshot /mnt/data /mnt/data/.snapshots/20240520，但注意它不自动去重跨子卷，且btrfs filesystem usage才能真实反映写入放大 - 快照本身不防硬件损坏，必须配合上层异地备份；且 LVM 快照对高 IO 负载有性能拖累，生产库建议关掉或仅用于维护窗口
近线备份层：rsync + hardlink 增量归档到独立 硬盘
目标是保留多版本、节省空间、避免全量传输。核心靠 rsync --link-dest 复用未变文件的硬链接，而非拷贝。
- 目录结构必须固定，例如：
/backup/hostname/daily.0,/backup/hostname/daily.1…… 每次运行前mv daily.0 daily.1; mv daily.1 daily.2，再用--link-dest=/backup/hostname/daily.0同步到daily.0 -
rsync必须加-aHAX：保留硬链接（-H）、ACL（-A）、扩展属性（-X），否则权限 /SELinux 上下文丢失 - 不要用
--delete直接清理旧备份，先find /backup/hostname -maxdepth 1 -name 'daily.*' -mtime +30 -delete按时间删，防止同步中途失败导致整层被清空
离线 / 异地层：rclone 加密同步到对象存储或远程服务器
解决火灾、勒索软件、磁盘批量损坏等场景。关键在加密前置、传输可控、校验闭环。
- 本地加密必须用
rclone mount或rclone sync的--crypt远程，而非先gpg再传——前者支持流式加密 + 断点续传，后者大文件易失败且无法增量 - 对象存储如
s3或backblaze b2，务必启用服务端加密（server_side_encryption = AES256），但注意这不替代客户端加密，两者应并存 - 每次同步后必须跑
rclone check对比本地与远端的--size-only或--checksum（后者慢但准），并把结果写入日志，失败则告警——没验证过的备份等于没备份
恢复验证层：每月一次真机还原测试
所有备份策略最终要落在“能否恢复”上。自动化脚本不能只做 ls -l 或 stat，必须走完整路径。
- 挑一台闲置机器或 VM，从裸机开始：用
dd写入备份的系统盘镜像（如有），或从rsync快照重建根目录，再chroot修复引导 - 应用数据单独验证：比如 PostgreSQL 备份，要
pg_restore到临时实例，连上去SELECT COUNT(*)随机表，确认数据可读 - 记录每次恢复耗时与失败点——很多团队直到真正出事才发现
rsync备份里漏了/etc/crypttab，导致恢复后无法解密 LUKS 分区
最常被跳过的其实是恢复验证和快照空间监控。一个 lvs 输出没人看，直到某天 lvconvert --merge 报错说快照已满；一次 rclone check 脚本权限写错，三个月备份其实全是空壳。备份体系的脆弱点，永远藏在“以为它在工作”的地方。
