mongoose

rclone 里面有个加密的功能，但是不推荐直接使用
alist 中有个加密的源，大概是使用 rclone 实现的，可以使用 rclone 和 alist 无缝加密、解密
duplicati 提供了一个 web 页面，一目了然，使用了 sqlite 数据库保持一致性，但是很容易建立失败，失败了重建数据库绝大多数时候也会失败，这个时候，你只能删除备份项目和网盘中文件，然后重新建立，很麻烦，而且也会失败。。。。支持增量备份、版本控制。但是这是备份软件，貌似是没有挂载成磁盘让你直接使用的特殊优化
kopia 也提供了一个 web 页面，貌似是特地为网盘做了特殊设计，虽然它的官方介绍页面上说明了它的优势，但是我也和上面那个 duplicati 一样也没成功备份我大概 1T 多的数据。支持增量备份、版本控制。但是这是备份软件，貌似是没有挂载成磁盘让你直接使用的特殊优化
上述都支持一些国外的网盘，谷歌网盘之类的，也支持 webdav （可以使用 alist 将国内的网盘挂载成 webdav ）
restic 之类的，貌似 restic 只支持本地磁盘，那你还需要将 webdav 挂载成文件路径。

其实加解密文件的软件有很多，但是要适合云盘这个场景就可以筛掉一批，比如将文件整体存成一个块的方案（甚至能够提供假密码，解密出假文件的功能，防止被审问被迫说出密码的情况），但是这并不适合网盘。

不仅如此，备份到网盘还需要考虑断点续传，考虑增量备份，考虑版本控制（也需要定时删除），考虑冗余，考虑丢失小部分数据也能恢复，考虑定期扫描，考虑访问速度控制（防止触发网盘的防火墙限制）。

对于国内的网盘，如果原生不支持 webdav 之类的协议，使用的是 alist 破解的协议，还可能会遇到你觉着上传到网盘了，但是实际上是上传到自建的 alist 缓存中，看似上传很快，但是需要 alist 走你的上行带宽慢慢上传到网盘里面，这个过程中可能导致数据不一致，不要小瞧这一点，如果你数据量很大，又遇到访问控制非常严格的网盘，那么你可能不能完成一次完整的备份，剩下的就是无休止的上传、触发网盘限制、失败、重试的漩涡中，在叠加上这个 alist 缓存问题，那排查都排查不完。
有时候网盘反应不过来，这个过程中有的网盘会自动给你增加（ 1 ）后缀，重复上传。有时候，网盘会有审核，是的，你上传的加密、非共享的文件，也会被审核（迅雷网盘），虽然上传成功，但是可能不会被认为上成功，也可能会被审核不通过（我测试过程中过了一会就没有什么正在审核的标志了，但是我并没有在意到底是审核通过了，还是没通过把数据删了）导致丢失数据。

总之问题非常多，我尝试过几次，但是都失败了，所以我暂时放弃了，我觉着，个人数据不宜大于 1T ，最好几十 G 的样子，否则可能遇到各种问题，1T 的数据，按照 5MB/s 的上行速度，一次性上传，大概需要 60 个小时，我觉着肯定会触发网盘的防火墙，大概率这辈子都不能成功上传了，**除非你是慢慢用比较长时间，增量备份上去。**

但如果你的数据只有几十 G 的话，其实什么方案都问题不太大，甚至多花点钱买个 s3 也行，国外的网盘也行，国外也有一些 rsync.net 之类的提供特殊的空间用来备份（其实价格不是很贵），也有一些大容量的 vps 可以选择，这样更加自由了。

总之，国内的网盘，虽然看上去容量很大，但是用来备份严肃的巨量的数据稳定性可能不是很好，如果你所需要的空间大概是几十 G 的话，可能还比较合适，再多就不合适了。但是你就只用几个 G ，你甘心吗？几十 G 的数据如果很重要，你自己本地磁盘也会备份好几份，有没有网盘备份，可能问题都不是很大。

如果你只是打算几个电脑之间同步或者备份数据的话，也可以使用 syncthing 来备份，它自带了简单的回收站的功能。如果是挂载成磁盘，慢慢同步，那类似 freefilesync 之类的 。或者使用 nas 自带的备份功能，这就取决于你自己了

（上面更加侧重于备份这个需求，你如果需要的是使用时加解密，可以直接使用 rclone ，alist ，挂载 webdav 磁盘，之类的关键词搜索，这样反而简单了许多，除非你习惯修改巨大的文件或者有持续不停的读写需求，应该都能满足，再说，都在你眼前了，即使有什么问题，你自己也可以处理了）

unraid 的话，如果不使用 cache 的话，就是单个机械硬盘的速度，根本用不上万兆，2.5G 怎么也都够了，使用了 cache 的话，倒是有可以跑满万兆

你好，能讲讲 kopia 备份有啥莫名其妙问题吗？那个 duplicati 我用过，老是 DB 损毁或者不一致之类的，kopia 有啥问题？

@ijrou #28
@Greendays #32
@wow0o #33
@chjs #21

我根本不用他做什么重负载的任务，我 clone 一个 git 仓库，需要等 10 几分钟，我确实可以认为它速度不快。这是我需要使用过程中无数个步骤中的一个小步骤，虽然我后来测试，我 16 核的 3700x ，也需要 3 分钟，但体感上，10 几分钟真的比 3 分钟长的多了，仔细测试发现，n100 单纯是核心数太少了，可能单核在我这个场景中和 3700x 台式机差不多（在这个场景中差不多，我不用它做什么重负载的任务，对我来说，这就是个低功耗的服务器，能跑一些简单的服务没能满足我的自动化部署流程就可以了）


@wangdk23411 #39
@tywtyw2002 #31

--depth=1 这个参数挺好，能完美解决问题，基本上是秒完成，而且不影响后续可以继续 git pull 来更新

@Laobai #9 我平时只是用它做一些轻度的网络应用，一般都是显示很低的 CPU 占用，只是到今天真的在上面 git clone 一个大仓库的时候才发现怎么耗时那么久，风扇在狂转，界面显示 CPU 占用已经满了，才有了这个帖子。

@INCerry #1
@Ipsum #2
@qazwsxkevin #3
@duanxianze #4
@archxm #5
@my101du #7

我又重新测试了
```bash
❯ time git clone https://gitee.com/felixonmars/dnsmasq-china-list dnsmasq-china-list # on debian-wsl2-3700x
Cloning into 'dnsmasq-china-list'...
remote: Enumerating objects: 601283, done.
remote: Counting objects: 100% (54058/54058), done.
remote: Compressing objects: 100% (18246/18246), done.
remote: Total 601283 (delta 36000), reused 53830 (delta 35812), pack-reused 547225
Receiving objects: 100% (601283/601283), 262.20 MiB | 14.91 MiB/s, done.
Resolving deltas: 100% (400624/400624), done.

real 3m13.987s
user 22m51.862s
sys 0m11.940s
```


```bash
root@n100-debian-docker:/tmp# time git clone https://gitee.com/felixonmars/dnsmasq-china-list dnsmasq-china-list #debian-n100-2cores
正克隆到 'dnsmasq-china-list'...
remote: Enumerating objects: 601283, done.
remote: Counting objects: 100% (60307/60307), done.
remote: Compressing objects: 100% (20695/20695), done.
remote: Total 601283 (delta 40173), reused 59565 (delta 39612), pack-reused 540976
接收对象中: 100% (601283/601283), 261.17 MiB | 14.75 MiB/s, 完成.
处理 delta 中: 100% (400631/400631), 完成.

real 11m53.982s
user 22m44.791s
sys 0m9.638s
```

好吧，似乎并不慢。

可以使用接码平台，不会影响后续，这个只是用来证明你是真人。
不过，我就只成功注册了一个，接下来注册的，根本接收不到短信了，还好，收不到短信不会扣钱。

话说，以前谷歌账号那不是分分钟注册，没想到真的等我想正经注册一个有意义的时候反而注册不了了，当年注册的纯数字的谷歌账号，用了几年了，觉着还是要注册个有意义的账号，否则发邮件都不好意思。

@lany #3 看得我心痒痒的