从又拍云到七牛云：一次博客图床的紧急迁移实录
前言
我的博客图床一直放在又拍云。用了挺长时间，图片访问也一直稳定，直到最近，又拍云那边开始出现一些不太对劲的信号。
先是登录控制台收不到短信验证码，接着是数据迁移工具反复报错。折腾了一圈之后，我最终把整个图床从又拍云迁到了七牛云。这篇文章记录一下这次迁移的完整过程，包括踩过的坑和最后真正管用的方法。
为什么要迁移
直接原因很简单：又拍云的服务状态变得不可靠了。
具体表现有几个：
- 登录控制台时，短信验证码一直收不到，导致无法进入后台；
- 公开信息显示，又拍云近期存在经营层面的风险，包括被法院签发限制高消费令、多起被执行案件，以及部分业务下线（如又拍云联盟下架了）。
对于一个依赖图床的博客来说，图床服务不稳定是致命的。图片一旦打不开，读者体验会直接崩掉。所以我决定尽快把数据迁走。
迁移过程中遇到的第一个坑：迁移工具报“bucket is empty”
最开始，我使用的是七牛云自带的数据迁移工具，按照正常流程填写了又拍云的 Endpoint、AccessKey、SecretKey 和桶名，结果任务直接失败：
失败原因：bucket is empty
文件数：0 个失败 / 0 个成功 / 0 个跳过 / 0 个待迁移
一开始我怀疑是 HTTPS 证书过期导致的，但仔细想了一下，这个判断不成立。HTTPS 证书只影响浏览器访问域名时的加密，不影响对象存储 API 的鉴权。 迁移工具走的是 S3 兼容 API，和浏览器打开图片是两条完全不同的通道。
真正的原因，是我无法登录又拍云控制台，也就无法确认或重新获取正确的 S3 API 密钥。虽然博客后台里保存着之前配置的密钥，但七牛云的迁移工具那边，很可能在某个参数上没对上。
转折点：用 rclone验证又拍云 API 是否可用
既然七牛云的工具走不通，我决定换一个更底层、更可控的工具来验证：rclone。
rclone 是一个命令行工具，支持几乎所有主流对象存储的 S3 兼容接口。用它来测试又拍云，可以绕开七牛云迁移工具本身的配置问题，直接判断“又拍云的密钥和桶到底能不能读”。
第一步：安装并配置 rclone
下载 rclone 后解压，在命令行里执行：
.\rclone.exe config file
它会告诉你配置文件的路径。我的路径是：
C:\Users\herbert\AppData\Roaming\rclone\rclone.conf
然后手动创建这个文件，写入又拍云的配置：
[upyun]
type = s3
provider = Other
access_key_id = 你的又拍云AccessKey
secret_access_key = 你的又拍云SecretKey
endpoint = s3.api.upyun.com
这里的 AccessKey 和 SecretKey，是我从博客后台保存的又拍云 S3 配置里找到的。这一点很关键——正因为博客后台还留着这对密钥，我才能在登录不上又拍云的情况下，继续通过 API 访问数据。
第二步：验证连接
执行：
.\rclone.exe ls upyun:你的桶名
结果成功列出了大量文件。这说明：
- 又拍云的 S3 API 密钥是有效的；
- 桶名
你的桶名是正确的； - 数据还在，没有被清空。
问题彻底定位了：不是又拍云读不到数据，而是我在七牛云迁移工具的配置有问题。
正式迁移：用 rclone 把数据从又拍云复制到七牛云
既然 rclone 能正常读取又拍云，我决定直接用 rclone 把数据复制到七牛云，绕开七牛云自带的迁移工具。
第一步：配置七牛云
在同一个 rclone.conf 文件里，追加七牛云的配置。我的七牛云空间在华南-广东区域，所以 endpoint 是：
[qiniu]
type = s3
provider = Other
access_key_id = 你的七牛云AccessKey
secret_access_key = 你的七牛云SecretKey
endpoint = s3.cn-south-1.qiniucs.com
七牛云的 AccessKey 和 SecretKey 在控制台的“密钥管理”里获取。
第二步：验证七牛云连接
.\rclone.exe ls qiniu:image-blog-kk
不报错就说明配置成功。
第三步：查看源端文件总量
在正式迁移前，先统计一下又拍云那边的文件数量：
.\rclone.exe size upyun:image-blog-kk
输出结果：
Total objects: 189.524k (189524)
Total size: 256.797 MiB (269271463 Byte)
将近 19 万个文件，但总大小只有约 257 MiB。这说明文件数量多、单个文件小，迁移的瓶颈不在带宽，而在请求次数和并发能力。
第四步：排除不需要迁移的目录
又拍云桶里有一些日志目录和不需要的文件夹，迁移前用 --exclude 排除掉：
.\rclone.exe copy upyun:image-blog-kk qiniu:image-blog-kk -P --transfers 32 --checkers 32 --exclude "upyun_storage_log_*/**" --exclude "blog/edgeone/**"
参数说明：
-P：显示实时进度；--transfers 32：同时传输 32 个文件，针对海量小文件场景提高并发；--checkers 32：并发检查数；--exclude：排除指定目录。
第五步：校验一致性
迁移完成后，执行校验：
.\rclone.exe check upyun:image-blog-kk qiniu:image-blog-kk --exclude "upyun_storage_log_*/**" --exclude "blog/edgeone/**"
如果显示 0 differences found，就说明两边数据完全一致。
迁移后的收尾工作
数据迁完之后，还需要做几件事：
- 确认博客图片正常显示：打开几篇带图的文章，确认图片都能正常加载；
- 配置七牛云自定义域名和 HTTPS 证书：确保访问安全；
- 处理又拍云账户：如果还有余额，尽早申请提现；确认没有自动续费或按量计费还在跑；
- 重置暴露的密钥：迁移过程中如果密钥曾经暴露，建议在又拍云和七牛云分别重置。
总结
这次迁移的核心难点，不在于数据本身有多大，而在于源端服务不可登录、迁移工具报错、问题定位困难。
真正解决问题的关键有两个：
- 博客后台保存了又拍云的 S3 密钥，让我在登录不上控制台的情况下，依然能通过 API 访问数据；
- rclone 作为底层验证工具，绕开了七牛云迁移工具的配置问题，直接确认了源端数据可用，并最终完成了迁移。
如果你也在使用第三方图床或对象存储，建议提前做好两件事：
- 在安全的地方备份一份云存储的密钥信息；
- 了解并掌握 rclone 这类命令行工具的基本用法，关键时刻能救服务器。
