前言

无限容量网盘的凋零

前段时间Google Workspace砍了一大批土区无限容量用户（大部分都是单人车），大批用户转而选择了Dropbox Advanced plan，笔者也是这个时候和小伙伴三个人选择了入坑。Dropbox的无限容量和Google Workspace常规车很像，它需要在用完或者快用完容量时和客服沟通来申请更多的容量空间。一开始在Dropbox用户体量不大的时候，客服给容量可谓慷慨至极，看论坛上有小伙伴一次性申请到500T，笔者最多的一次是申请到了100T；随着用户增多，客服改成了一周只能申请10T，后来是一个月1T。最后干脆发公告封了车，修改了Dropbox Advanced订阅为每个许可证5T容量，现有用户所申请的容量只能再使用一年。至此Dropbox Advanced无限容量彻底落幕。

Dropbox官网修改Dropbox Advanced方案公告

网盘替代的选择

笔者研究了一番后，了解到一些其他的替代方案有：

1. Google Workspace多人车（估计被砍也是时间问题）
2. Box Business Plus（单文件最大15G,需要rclone chunker）
3. 115网盘（购买容量卡 or 永久会员5pb）

虽然笔者的Workspace多人车尚在，但是小伙伴们的前车之鉴告诉了我们还是趁早备份吧。巧合的是笔者正好之前也使用了115网盘，也上车了会员，虽然只有80T的容量，但也足够转移在Workspace中的文件了。因此，从Google Drive转移文件到115网盘便成了当务之急。

Google Drive转移数据到115网盘的方案

115服务器支持秒传的功能，这为我们的云盘之间的迁移和传输节约了大量的网络流量和时间，提供了极大的便利。秒传机制是一种可以快速完成文件传输的技术，它的工作原理是在上传文件前先获取文件的哈希值，然后将哈希值发送到服务器，服务器根据哈希值检查文件是否已经存在。如果文件已经存在，服务器就不需要再接收文件数据，而是直接创建一个新的文件记录，指向已存在的文件数据，从而实现秒传。在添加上传时，需要等待115服务器校验hash，如果校验文件hash通过后可以直接秒传，否则就需要等待文件上传，上传速度取决于服务器的带宽以及上传服务器与115服务器的连接性。笔者在这里将Google Drive转移到115网盘的方案分为了Windows端和Linux端分别进行介绍。

Windows平台的备份

Windows端的机器的备份相对来说比较简单，只需要去官网下载客户端，客户端内进行上传操作即可。Google Drive则可以通过rclone挂载甚至是Google Drive官方客户端挂载到本地进行食用。值得一提的是，如果使用rclone挂载到本地时，需要加上--vfs-cache-mode full参数，否则上传大文件时会报错。

如果采用本地Windows机器来进行上传的话，会面临两个问题：1. Google Drive无法直连中国大陆骨干网，需要进行代理上网的方式，而代理的流量无论是买机场还是自建的VPS都相对来说比较高昂 2.本地的上传网络带宽相对而言较小，大部分都是50Mbps，如果数据量庞大，即使可以秒传其中的大部分文件，上传剩余部分文件的过程也是相当的漫长。因此，采用本地的Windows机器来实现大量的云盘文件转移确实不是一个明智的选择。

因而更多的问题是找一台合适的Windows服务器，它既要满足能够直连Google Drive的需求，更多的是它需要无限容量，同时最好本地能够有60GB以上的硬盘容量可供缓存从Google Drive下载后的文件以上传115服务器。

小插曲

笔者之前想入手ColoCrossing家的黑五24刀VPS，配置为：3C 4G 60G 无限流量，且可以安装Windows，感觉比较合适用来迁移云盘。不过在听闻论坛其他的小伙伴们使用CCS服务器上传115网盘速度不甚理想，且笔者手中有一些比较闲置的其他机器时，便最终选择了放弃。

Linux平台的备份

Linux的服务器，可供的选择可太多了，有人说最好选亚太地区机房的机器，速度会快一些，笔者使用的是德国机房的机器，速度也还可以。
Linux平台可以使用rclone来挂载Google Drive，且体验极佳，而对于115网盘遗憾的是rclone则并没有提供支持，笔者只好寻求其他的替代，Alist和Clouddrive2两款工具是大多数用用户的解决方案，通过它们可以实现把网盘挂载到本地，从而实现数据迁移，两款工具均可通过docker compose部署。

version: "2.1"
services:
 cloudnas:
   image: cloudnas/clouddrive2
   container_name: clouddrive2
   environment:
     - TZ=Asia/Shanghai
     - CLOUDDRIVE_HOME=/Config
   volumes:
     - <path to accept cloud mounts>:/CloudNAS:shared
     - <path to app data>:/Config
     - <other local shared path>:/media:shared #optional media path of host
   devices:
     - /dev/fuse:/dev/fuse
   restart: unless-stopped
   pid: "host"
   privileged: true
   network_mode: "host"
   #ports:
     #- 127.0.0.1:19798:19798

version: '3.3'
services:
   alist:
       restart: always
       volumes:
           - '/etc/alist:/opt/alist/data'
       ports:
           - 127.0.0.1:5244:5244
       environment:
           - PUID=0
           - PGID=0
           - UMASK=022
       container_name: alist
       image: 'xhofe/alist:latest'

Alist与Clouddrive2对比表

总的来说，就115网盘而言，Clouddrive2相比于Alist的兼容性更佳，不仅支持web端在线播放，并且支持一键挂载，相比于Alist使用体验更好，唯一的缺点是Clouddrive2需要收费，月费￥4.99，终生会员￥499，不算便宜。因为担心作者提桶跑路，笔者买的是月费，价格也还算能接受吧。

一开始笔者的迁移云盘的方式是，把Google Drive和115网盘均挂载到服务器本地，对本地存储空间进行操作，可以使用命令行，也可以使用类似filebrowser的文件管理器，网页上点点点就行。由于本地的缓存空间有限，怕把服务器存储空间给塞爆了，只能手动慢慢的记录迁移，并且还要随时记录迁移的位置，迁移的过程可谓是相当的痛苦。不禁让笔者想念起了当年Google Drive迁移Dropbox直接rclone copy一把梭哈的快乐。好在大部分文件都可以秒传，速度其实尚可。

附上灯大魔改的filebrowser的docker compose

version: "2.1"
services:
    filebrowser:
        container_name: fb
        image: 80x86/filebrowser:2.9.4-amd64
        restart: unless-stopped
        volumes:
            - $HOME/docker/fb/config:/config
            - $HOME/docker/fb/myfiles:/myfiles
        tmpfs:
            - /tmp
        ports:
            - 127.0.0.1:8081:8081
        environment:
            - PUID=0
            - PGID=0
            - WEB_PORT=8081
            - FB_AUTH_SERVER_ADDR=127.0.0.1
            - FB_BASEURL=/filebrowser

不久，Clouddrive2作者最近刚更新了0.6.x版本，6以上的版本都更新了多云盘备份功能，此功能可以实现云盘之间数据备份，且无需事先从Google Drive下载到本地缓存。这个功能瞬间吸引了笔者，便尝试了这个功能来进行迁移，只要设置要源文件夹为Google Drive文件夹和目的文件夹为115网盘文件夹，即可全面扫描一次备份的目录和目标目录比对，直接比对了hash把能秒传的文件都秒传了，剩余部分文件再慢慢进行上传。

笔者总共文件夹中大约40000个文件，秒传了其中的36000个，还剩下3500多个慢慢传输，115的影视文件秒传率还是很高的，可以说真的是非常的效率了。说一下该功能的优点和缺点吧。

优点：

1. 不需要缓存到本地即可快速比对目标文件夹总所有的文件的hash，实现快速秒传，节省大量时间。
2. 传输不能秒传的文件，也不占用本地空间，理论上小容量的VPS，只要流量足够也可以用来备份了。
3. 后续如果源文件夹再添加文件的话可以实现数据同步。

缺点：

1. 如果无法秒传的话，相比于第一种缓存到本地再进行上传的模式，这种模式下的速度下降了很多。笔者测试了一下，缓存到本地再进行上传的是速率平均大约在10MBps,而直接备份上传的平均速率大约在5MBps，整整打折了一半。
2. 文件传输错误/中断率明显提高，传输错误/中断时需要重新上传，然后很大概率会再次传输错误，尤其是大文件，笔者未能使用该功能上传超过25GB以上的文件。
3. 出现了文件夹配置完成后，没有自动开始扫描文件夹中的内容，点击手动扫描也没有开始扫描。只有重启容器才恢复正常，不知道是不是个例。

总结

笔者最终选择了Linux + Clouddrive2 + rclone的备份模式，其中也不乏有一些反复出现的小问题：

• 大文件传输超过5h后会中断，然后重新传输
• 传输过程中会反复出现速度的起伏，不够稳定，这一点在午间到傍晚时间段尤其明显。

虽然新的Clouddrive2备份功能中间有一些小问题，但是也瑕不掩瑜，总算不用自己手动备份啦，依赖于115网盘的强大秒传功能，至此完成的数据的迁移。在这样一个无限容量网盘凋零的年代，不知道115又能坚持多久呢？能玩一天是一天吧，且玩且珍惜。