脚本用了很久了，备份效果是毋庸置疑的，最近加了自动上传，可用性提高不少，感谢作者付出。
不过问题在于旧版本的保存占用太大了，而且我又有回去翻卸载的旧软件的习惯:
texsd@tnas /v/个/t/speed-backup> du -sh *
4.0K special_app.txt
38G speed-backup
26G speed-backup-2.14
37G speed-backup-10.23
34G speed-backup-12.13
34G speed-backup-25.1.23
34G speed-backup-25.7.29
38G speed-backup-26.2.28
现在的“增量”其实是伪增量，比较新旧之间的大小，我也看到过 #62 提出的，tar自身的增量问题确实不好，只能基于一个最旧的版本，我认为在这种场景下不太适合，这也大概是一直搁置的原因。
所以我查了下，有Borg/restic这种解决方案，基于块进行比较。borg先否了，因为扔一个python进来不太现实，那么我觉得go写的restic是一个不错的选择。
tar还是无可替代，因为元数据确实完整，那么脚本可以在备份的时候，管道给restic，然后由restic保存在他的仓库里面，需要的时候，管道输出tar给脚本进行恢复，这样是一种可行的办法吗？算是本人的拙见，抛砖引玉吧。
现代手机支持sha256硬件加速，而且相比落盘每次写数据来说，对比文件差异算是比较轻量了，我觉得性能应该不是什么大问题。
脚本用了很久了，备份效果是毋庸置疑的，最近加了自动上传，可用性提高不少，感谢作者付出。
不过问题在于旧版本的保存占用太大了，而且我又有回去翻卸载的旧软件的习惯:
现在的“增量”其实是伪增量，比较新旧之间的大小，我也看到过 #62 提出的，tar自身的增量问题确实不好，只能基于一个最旧的版本，我认为在这种场景下不太适合，这也大概是一直搁置的原因。
所以我查了下，有Borg/restic这种解决方案，基于块进行比较。borg先否了，因为扔一个python进来不太现实，那么我觉得go写的restic是一个不错的选择。
tar还是无可替代，因为元数据确实完整，那么脚本可以在备份的时候，管道给restic，然后由restic保存在他的仓库里面，需要的时候，管道输出tar给脚本进行恢复，这样是一种可行的办法吗？算是本人的拙见，抛砖引玉吧。
现代手机支持sha256硬件加速，而且相比落盘每次写数据来说，对比文件差异算是比较轻量了，我觉得性能应该不是什么大问题。