21 年的时候用 Cloudreve 给社团搭建了一个网盘，白嫖了一个朋友的 Onedrive E3 账号。日积月累也存了大概有 160G 的数据了，但是好像说四月份微软就要拉闸了，得赶紧把数据给救回来。综合考虑最后打算使用从机存储的方式，把新的文件放到我的法国大盘鸡上。

2024年6月更新：结果没拉闸。。。

但是老数据怎么办呢？微软拉闸了说不定会把旧数据也删掉，所以也得迁移。但是我查了一下，发现 Cloudreve 要付费版才支持存储策略之间的数据迁移。那还是挺坑爹的。不过看论坛上说，所谓的迁移也只是先下载到本地再上传，感觉对现在 Cloudreve 的 30M 小水管也不是很友好。没办法，只能硬着头皮动手了。Cloudreve 默认是使用 sqlite3 数据库的，当时我想着反正规模也不大，用着也没啥问题就接着用了。如果是使用了 MySQL 部署的也大差不差，表结构应该也是不会变的。

以下是两个相关的表格结构。

  • files

    字段名 类型
    id integer
    created_at datetime
    updated_at datetime
    deleted_at datetime
    name varchar(255)
    source_name text
    user_id integer
    size bigint
    pic_info varchar(255)
    folder_id integer
    policy_id integer
    upload_session_id varchar(255)
    metadata text

  • policies

    字段名 类型
    id integer
    created_at datetime
    updated_at datetime
    deleted_at datetime
    name varchar(255)
    type varchar(255)
    server varchar(255)
    bucket_name varchar(255)
    is_private bool
    base_url varchar(255)
    access_key text
    secret_key text
    max_size bigint
    auto_rename bool
    dir_name_rule varchar(255)
    file_name_rule varchar(255)
    is_origin_link_enable bool
    options text

这两个表格展示了files和policies两个数据库表的结构，包括每个表中字段的名称和数据类型。
从数据库中我们不难发现，存储策略存在一个叫 policies 的表中。文件的映射则保存在 files 表中。其中 files 表中的 policy_id 字段对应的就是 policies 表中的 ID。那样的话就简单了，我们只需要将 files 表中的 policy_id 更新成我们新的存储策略的 ID，然后把数据用 rclone 搬到新机器上就完成了。

数据库命令可以参考我这个，其中 3 是新的存储策略 ID，2 是旧的存储策略 ID。

UPDATE files SET policy_id = 3 WHERE policy_id = 2;