GitHub Actions Runner Images 完全指南：托管 Runner 虚拟机镜像的构成、发布策略与自定义构建
2026/9/15 22:24:00
在内网机器上部署对象存储，很多人第一反应是拉源码自己编译，要么干脆docker run一把梭。这两种方式在测试环境都挺好使，可真到了生产环境，尤其是有几十台 Linux 服务器要管版本、分批升级、出问题要回滚的时候，RPM/DEB 包反而是最不起眼也最顺手的路。RustFS 是一个用 Rust 写的 S3 对象存储服务，官方会发布 RPM 和 DEB 两种安装包，分别覆盖 RHEL 系和 Debian 系两大 Linux 生态。这篇文章就把我在 Linux 上通过 RPM/DEB 包部署 RustFS 的完整过程、遇到的坑和排查思路整理出来，适合正在做对象存储选型，或者刚接手服务器想快速落地 RustFS 的人参考。
1. RustFS 安装方式怎么选：RPM/DEB 包的地位
1.1 为什么包管理器比源码编译更适合生产环境
RustFS 这种用 Rust 写的服务，源码编译本身并不是不行，但生产环境里要算一笔综合成本。Rust 的依赖树非常重，编译需要先安装完整的 Rust 工具链，然后从 crates.io 拉几十上百个第三方库。在内网环境，每次构建都要处理网络不通、版本锁定、缓存共享这些问题，单是构建环境维护就是一个持续负担。更麻烦的是，源码编译出来的二进制没有进入系统包数据库，过三个月你想知道自己装的是哪个版本、改过哪些编译参数，几乎无从查起。
包管理器解决的就是这个"可追溯"的问题。RPM 和 DEB 包背后有专门的数据库，记录软件本身的版本、文件清单、配置文件位置、依赖关系。装上之后，rpm -q或dpkg -l能看到版本，rpm -V或debsums能校验文件完整性，rpm -e或apt purge能干净卸载。这套机制在公网源和内网私有源里都成立，运维规范和自动化工具也围绕它展开。换句话说，用包管理器装 RustFS，等于把"怎么装、装了什么、怎么卸"这件事交给系统去记账，而不是靠个人笔记。
1.2 三种安装方式的对比
把常见的三种方式放在一起看会更直观。我整理了一张对比表，你在选型时可以对着看。
| 对比项 | 源码编译 | 二进制压缩包解压 | RPM/DEB 包 |
|---|---|---|---|
| 依赖处理 | 手动装构建工具链和系统库 | 手动拷贝，依赖难查 | 安装器自动检查依赖 |
| 版本记录 | 无统一记录 | 靠文件名或 readme | 系统数据库统一记录 |
| 升级方式 | 重新编译替换 | 下载新包覆盖，易混淆 | rpm -U / dpkg -i |
| 服务集成 | 手动写 systemd 单元 | 手动写 systemd 单元 | 安装包自带单元文件 |
| 卸载清理 | 手动删文件和用户 | 手动删，残留多 | 包管理器统一清理 |
| 适用场景 | 开发调试、特殊优化 | 快速体验、绿色运行 | 生产环境、批量纳管 |
源码编译适合你确实需要修改源码或者做架构定制的情况，二进制压缩包适合临时跑一下验证功能，真正到了生产落地，RPM/DEB 包基本是首选。这不是说包管理器一定比别的方案高级，而是它把"可运维性"这个生产环境最重要的属性提前内置了。
1.3 先搞清楚你的 Linux 属于哪个生态
很多人在安装踩坑，根源不是命令不对，而是没分清发行版生态。Debian、Ubuntu、Linux Mint 以及大量基于这些系统的衍生版，用的是 DEB 包和 dpkg/apt 工具链；RHEL、CentOS、Rocky Linux、AlmaLinux、Fedora、openSUSE 这类系统，用的是 RPM 包和 rpm/dnf/yum 工具链。这两套体系彼此不兼容，DEB 包在 RPM 系统上装不了，RPM 包在 DEB 系统上也跑不起来。
我拿到一台新服务器，第一件事永远是先确认系统身份，再想下载哪种包。命令很简单：
cat /etc/os-release uname -m/etc/os-release会告诉你系统的 ID 和版本，uname -m告诉你是 x86_64 还是 aarch64。下载 RustFS 安装包时，架构和生态对应错了，后面白折腾半小时。另外还建议顺手确认一下当前有没有装过旧版本：
rpm -qa | grep -i rustfs dpkg -l | grep -i rustfs有旧版本的话，后面安装流程要按升级逻辑走，而不是直接覆盖安装。
2. DEB 包安装全流程：从下载到服务启动
2.1 安装前的环境检查
在 Debian/Ubuntu 系系统上部署 RustFS，我是建议先把下面几个项目核一遍。第一，确认系统软件源能正常用，因为后面一旦缺依赖，要依赖apt去补；第二，确认系统时间准确，对象存储的签名验证对时间敏感，时间偏了可能导致客户端鉴权失败；第三，检查有没有旧服务占用目标端口，RustFS 默认监听 9000 端口，如果之前装过 MinIO 或者别的对象存储，先把冲突解决掉。
还有一个容易被忽略的细节是 libssl 动态库。RustFS 官方很多时候提供的是静态编译版本，但也有部分构建会依赖 OpenSSL 的动态链接库。安装前可以先看一眼：
ldd /usr/bin/rustfs | grep 'not found'如果这条命令报出有 so 文件找不到，说明当前系统缺运行库，在 Debian/Ubuntu 上直接apt install libssl-dev或者apt install libssl3补齐。
2.2 用 dpkg 安装与依赖处理
拿到 DEB 包后，最基础的安装命令是：
sudo dpkg -i rustfs_1.2.3_amd64.deb这里有一个非常常见的坑：dpkg -i本身不做依赖解析，它只负责把包解开、文件放到位、运行安装脚本。如果系统里缺依赖库，它只会告诉你 "dependency problems" 然后报错退出。这时候不需要慌，执行：
sudo apt -f install或者用我平时更习惯的方式：
sudo gdebi rustfs_1.2.3_amd64.debgdebi是专门用来安装本地 deb 包的工具，它会在安装之前自动解析依赖顺序，把缺的包用 apt 拉下来再装，比dpkg -i加apt -f install的组合要省一步。很多桌面用户双击 deb 包闪退，本质也是因为系统自带的图形安装器没有把依赖关系处理好，后面我会在问题排查部分专门讲。
如果安装过程没有任何输出报错，用dpkg -l | grep rustfs检查状态，正常会看到ii开头，代表 installed 成功。
2.3 首次启动与服务配置
Debian 系的安装包通常会自带 systemd 单元文件，安装完成后直接运行：
sudo systemctl enable --now rustfsenable会让服务开机自启，--now表示立即启动一次。启动后建议立刻看三样东西：服务状态、监听端口、日志。
systemctl status rustfs ss -lntp | grep 9000 journalctl -u rustfs -f服务状态显示active (running)的时候，端口监听和日志大概率也没问题。RustFS 的配置文件一般会放在/etc/rustfs/目录下，第一次启动前如果不想用默认配置，可以先编辑config.toml再启服务。配置文件的具体项目我在第 4 节展开讲，这里先提一个原则：不管改什么参数，改完都要手动systemctl restart rustfs才能生效。
安装好后，可以用dpkg -L rustfs列出包的文件清单，查看它把二进制、配置、文档分别放到了哪里。这个习惯非常有用，后面排查"文件到底装到哪了"就靠它。
2.4 升级与卸载细节
DEB 包的升级思路比较简单，直接安装新版本包：
sudo dpkg -i rustfs_1.3.0_amd64.deb包管理器会识别到这是已安装软件的新版本，按升级流程处理。升级时最需要注意配置文件的问题：如果你手改过/etc/rustfs/config.toml，新包自带的模板文件一般不会直接覆盖你的修改，但可能弹出 conffile 的询问，问你是保留现有配置还是使用新包默认配置。生产环境我强烈建议选保留现有配置，然后手动对比新版本的示例配置，把新增字段补进去。
卸载分为两种程度：
sudo apt remove rustfs # 卸载软件，保留配置和数据 sudo apt purge rustfs # 卸载软件，清理配置注意，无论哪种卸载方式，数据目录/var/lib/rustfs下的数据都不会被动，需要自己手动确认处理。这算是一个安全设计，防止误删数据，但也意味着卸载完要记得自己备份或清理。
3. RPM 包安装全流程：从"没找到 rpm 命令"说起
3.1 为什么总会有人说"没找到 rpm 命令"
"没找到 rpm 命令"是我在网上看到非常多的一条报错，也是很多人第一天接触 Linux 包管理时最容易懵的地方。这个问题的本质很简单：你在 Debian 系系统里敲rpm -ivh，系统当然告诉你command not found，因为它默认就不装 rpm 工具。
我自己的判断流程是这样的：先看/etc/os-release，如果里面写的是ID=ubuntu、ID=debian这类，说明这是 DEB 系，安装 RustFS 应该去找.deb包，用dpkg或apt处理；如果写的是ID=centos、ID=rhel、ID=rocky、ID=almalinux、ID=fedora、ID=opensuse这类，才是 RPM 系。
有些 DEB 系系统上，你也可以通过apt install rpm把 rpm 命令装上去。装上之后 rpm 命令可以用来查看 RPM 包的信息和内容，比如rpm -qpl xx.rpm看一下包里面有什么文件，但绝对不要指望它能真正在 DEB 系系统上完成安装。我见过有人在 Ubuntu 上把 RPM 包解开硬跑的，结果服务起不来，最后还得回来找 DEB 包，纯属浪费时间。
3.2 用 dnf/yum 配置软件源安装
在 RHEL/CentOS 系系统上安装 RustFS，有两种常见方式。第一种是配置官方软件源，把 repo 文件放到/etc/yum.repos.d/下，然后从源里装。以官方提供的源地址为例，/etc/yum.repos.d/rustfs.repo里大致是这样：
[rustfs] name=RustFS baseurl=https://packages.rustfs.org/rpm/$basearch enabled=1 gpgcheck=1 gpgkey=https://packages.rustfs.org/RPM-GPG-KEY-rustfs配置完成后：
sudo dnf install rustfs第二种方式是直接下载 RPM 包文件安装。新版本 dnf 可以直接识别本地路径：
sudo dnf install ./rustfs-1.2.3-1.x86_64.rpm老一点的版本或习惯用 yum 的话：
sudo yum localinstall rustfs-1.2.3-1.x86_64.rpmlocalinstall和本地路径安装的好处是 dnf/yum 会自动处理依赖，不会像裸rpm -ivh那样缺一个依赖就报错。裸跑rpm -ivh也不是不行，但生产环境我一般不推荐，因为 RPM 的依赖解析是你手动管的，一旦系统里缺共享库，你得一个个手动装，麻烦且容易漏。另外，不管用哪种方式，gpgcheck=1最好保持开启，安装前把 GPG 公钥导进去，确认你装的包确实来自官方，防止软件包被篡改。
3.3 RPM 服务的 systemd 集成与文件布局
RPM 包安装完，文件布局和 DEB 包大同小异，二进制一般放到/usr/bin或/usr/sbin，配置放到/etc/rustfs/，数据目录默认是/var/lib/rustfs。用两条命令可以快速了解包内容：
rpm -ql rustfs # 列出包文件列表 rpm -qc rustfs # 只列出配置文件启动服务仍然是：
sudo systemctl enable --now rustfs在 RHEL 系系统上有一个 DEB 系不太常见的变量需要留意，就是 SELinux。如果你的系统是 enforcing 模式，RustFS 想读写/var/lib/rustfs目录，可能会被 SELinux 策略拦下来，服务状态显示启动失败，但直接看 journal 日志可能又觉得莫名其妙。这时候要去看 SELinux 审计日志：
ausearch -m avc -ts recent确认是 SELinux 阻断后，再决定调整策略还是给目录打合适的上下文标签，不要一上来就setenforce 0，那样会把整个系统的安全策略全部关掉，后面出问题更难查。
3.4 RPM 升级：rpm -Uvh 与覆盖安装的区别
RPM 的升级参数有三个容易混淆：-i是安装新包，-U是升级，-F是只升级已安装的包。生产环境升级 RustFS 时，最常用的是：
sudo rpm -Uvh rustfs-1.3.0-1.x86_64.rpm-U遇到老版本会自动替换，遇到没装过的情况会直接安装，使用上比较省心。不建议用-i去覆盖安装一个已经存在的包，虽然有时候能成功，但方式比较粗暴，可能留下老版本的配置文件，也可能让包数据库记录变得混乱。
升级前我习惯先做两件事：第一，用rpm -V rustfs校验现有安装的文件完整度，确认没人手改过二进制；第二，备份/etc/rustfs配置目录。RPM 升级和 DEB 类似，一般不会覆盖你修改过的配置文件，但"类似"不代表"一定"，而且新版本可能引入新的配置项，备份一份旧配置对比着改，最稳妥。
如果需要回滚到旧版本，可以这样操作：
sudo dnf downgrade rustfs-1.2.3-1.x86_64.rpm或者用rpm -Uvh --oldpackage。回滚操作在正式环境里不要轻易做，务必先确认数据目录的格式和版本兼容性，尤其要注意 RustFS 底层数据目录的版本结构在升级前后有没有变化，否则版本回退了数据反而读不出来。
4. 安装完成后的核心配置与数据安全
4.1 配置文件逐项解析
安装完成不代表能立即投入使用，RustFS 有自己的一套配置需要按生产环境要求梳理。它的主配置文件一般是 TOML 格式，位于/etc/rustfs/config.toml，关键字段大致是这样：
bind_addr = "0.0.0.0:9000" data_dir = "/var/lib/rustfs" region = "us-east-1" access_key = "your-access-key" secret_key = "your-secret-key" tls_enabled = false这段配置里，bind_addr是重中之重。默认监听0.0.0.0:9000表示所有网卡都会绑定，如果在公网环境，等于把对象存储端口直接暴露出去，风险相当大。我的建议是生产环境显式指定内网地址，例如bind_addr = "192.168.10.20:9000"，需要跨网段访问再通过内部负载均衡做转发。
access_key和secret_key相当于 S3 协议的用户名密码，安装包默认值必须改掉，用openssl rand -base64 32生成随机密钥再填进去，保存到安全的地方。region可以保持默认，但客户端连接时的 region 参数要跟这里保持一致，否则部分 S3 SDK 会提示签名区域不匹配。tls_enabled这里先说明，生产环境如果打算用 HTTP 明文，最好只在内网可信环境里这么干，公网流量务必启用 TLS 或者在前面挂一层网关。
4.2 创建系统用户与目录权限
RustFS 的安装包一般会自动创建rustfs用户，但有些情况下，比如你是自己打包的 RPM/DEB，可能不会自动建用户。确认方式：
id rustfs没有的话手动创建：
sudo useradd -r -s /sbin/nologin rustfs这个用户是给 RustFS 服务进程用的，-r表示系统用户，-s /sbin/nologin表示禁止登录，最小权限原则。
创建好后，数据目录和配置目录的属主要有意识地设置：
sudo chown -R rustfs:rustfs /var/lib/rustfs /etc/rustfs sudo chmod 750 /var/lib/rustfs sudo chmod 640 /etc/rustfs/config.toml数据目录 750 是让属主和属组能读能进，其他人一律不可见；配置文件 640 是为了防止普通用户读到你写进去的 access_key 和 secret_key。这个权限问题看起来基础，但我见过不少生产事故，服务装好跑不起来，最后发现就是目录权限不对，服务进程没有写权限，启动时直接报Permission denied。权限这种东西，装完顺手设好，比回头排查省力得多。
4.3 用 systemd 管理服务生命周期
RPM/DEB 安装包的另一个好处是会把 systemd 单元文件装好。你不需要自己写/etc/systemd/system/rustfs.service，系统里已经有现成的了。常见的操作就这么几条：
| 操作 | 命令 |
|---|---|
| 设置开机自启并立即启动 | sudo systemctl enable --now rustfs |
| 查看服务状态 | systemctl status rustfs |
| 重启服务 | sudo systemctl restart rustfs |
| 停止服务 | sudo systemctl stop rustfs |
| 查看日志 | journalctl -u rustfs -f |
| 确认当前是否在运行 | systemctl is-active rustfs |
有个细节值得注意：安装包自带的 unit 文件里通常已经写好了Restart=on-failure，意思是服务进程异常退出时 systemd 会自动拉起。但如果你是从源码或者压缩包方式安装的，容易漏掉这个配置。没有这个参数，程序一旦崩溃，服务就停在那不会自己恢复，等到监控报警才发现已经晚了。所以不管用什么方式装 RustFS，都建议确认一下单元文件里有没有这一行：
grep Restart /lib/systemd/system/rustfs.service如果是服务方式管理，我还习惯看一眼进程文件描述符限制。压力测试时并发连接数上去，默认的LimitNOFILE可能成为瓶颈，如果单元文件里有相关配置可以按需调大，没有的话也可以自己在 drop-in 目录里追加。
4.4 碎片文件与磁盘空间排查
对象存储和普通文件系统不太一样，删除对象不一定马上释放底层空间。RustFS 的数据目录/var/lib/rustfs底下是一层层的桶、对象、元数据文件，当上层 API 发出删除请求后，数据块可能要等后台清理任务真正跑完，才会物理释放。所以你可能会遇到这种情况：通过 S3 API 删了一大批文件，df -h一看磁盘空间一点没变。
这跟 WSL 里删文件后 vhdx 不自动缩容是同一个逻辑，逻辑删除和物理回收是两码事。排查时不要只看df -h，还要看数据目录的实际占用：
df -h /var/lib/rustfs du -sh /var/lib/rustfsdf看的是分区剩余空间，du看的是目录实际占用。两者不一致是正常的，因为底层可能还有未回收的预分配空间。运维上建议定期观察这两个值的走势，容量超过 70% 时就要考虑扩容或者清理策略。另外提醒一句，千万不要为了省事在生产环境直接rm -rf /var/lib/rustfs下面某个目录，对象存储的目录结构跟系统目录不一样，手删很容易把元数据和数据块的关联搞乱，造成数据不可读。
5. 常见问题排查与避坑清单
5.1 安装报错速查表
把我在部署过程中遇到的高频问题整理成一个速查表，基本覆盖了从下载到启动全流程的报错场景。
| 报错信息 | 原因 | 处理方案 |
|---|---|---|
rpm: command not found | 当前是 DEB 系系统 | 改用 dpkg/apt 安装 DEB 包 |
dependency problems | DEB 包缺少依赖 | sudo apt -f install或改用 gdebi |
Failed dependencies | RPM 包缺少依赖 | 用 dnf/yum 安装，自动补齐依赖 |
NOKEY/gpgkey import failed | 未导入 GPG 公钥或公钥过期 | 导入官方公钥，并确认系统时间正确 |
PORT 9000 already in use | 端口被其他服务占用 | ss -lntp | grep 9000找占用进程处理 |
Permission denied | 数据目录无权限 | chown rustfs:rustfs并确认 SELinux 策略 |
config parse error | 配置文件语法错误 | 检查 TOML 格式，临时文件不要混入 |
这张表背后的排查思路是：先把报错信息读完整，再定位是哪一层出了问题。依赖问题交给包管理器的自动依赖处理机制，端口和权限问题通过系统命令一步步缩小范围，别一上来就重装或者关防火墙，那样反而是给自己埋坑。
5.2 deb 包在桌面环境里双击闪退的原因
网上关于 deb 包安装闪退的讨论不少，其实深挖下去基本都是同一个原因：桌面环境自带的图形安装器对依赖处理不完整。Ubuntu、以及一些基于 Debian 体系的国产桌面发行版，双击.deb文件会唤起软件中心，软件中心在背后调的是 dpkg 的图形封装，可一旦遇到依赖缺失，它往往会直接弹失败或者闪退，而不是像命令行那样告诉你到底缺了什么。
解决办法很直接，绕开图形界面，回到命令行。要么用gdebi，要么用dpkg -i配合apt -f install。用命令行还有一个额外好处，就是你能看到完整的日志，哪怕是安装脚本里的一个小错误，也会明明白白打印出来。
还有一个情况要单独说明：有人双击 deb 包安装完后，觉得"没图标"或者"打开没反应"，以为安装失败了。对于 RustFS 这种服务端软件，本来就不应该出现在应用菜单里，它没有桌面图标是正常的。安装成功的标志是 systemd 服务能正常启动，端口能监听，或者命令行能连上，而不是桌面环境里多了一个图标。
5.3 服务起不来：日志比猜重要
服务启动失败的时候，我见过很多人不看日志，先去改配置、重启系统甚至重装服务，这个顺序是反的。正确的排查顺序是先看服务状态，再看日志，最后才动手改东西。
systemctl status rustfs journalctl -u rustfs --since "5 minutes ago"常见的启动失败原因有这么几类：端口被占用、数据目录权限不对、配置文件语法错误、依赖库缺失。这些在日志里基本都有直接证据。比如日志里出现bind: Address already in use，那就去查端口占用；出现Permission denied，就去查文件权限和 SELinux；出现parse error，就检查 TOML 配置，尤其注意有没有复制粘贴时混入了非法字符。
调试的时候还有一个实用技巧：不要把journalctl十几屏的日志一拉到底，可以先按错误级别过滤：
journalctl -u rustfs --since today -p err只显示 error 级别的信息，能帮你快速定位关键报错，减少干扰。
5.4 升级后配置被覆盖怎么办
升级本来应该是顺利的，但配置被覆盖这个坑我踩过不止一次。RPM 和 DEB 包在升级时对配置文件的策略虽然一般会保留你修改过的文件，但有两种情况它保不住：一种是你没有修改过配置文件，新包会直接替换成默认配置；另一种是打包者把新版本配置文件标记成了一种需要强制覆盖的状态，这时候你手工改的内容就会被覆盖。
所以我强烈建议，每次升级前养成备份配置的习惯：
sudo cp -a /etc/rustfs /etc/rustfs.bak.$(date +%F)万一升级后服务起不来，可以先对比一下新旧配置差异：
diff -u /etc/rustfs.bak.$(date +%F)/config.toml /etc/rustfs/config.toml新版本的默认配置一般都会放在/usr/share/doc/rustfs/或者类似的文档目录里，也有的是内置在二进制里通过命令导出。找到官方示例配置，和老配置一起比对，把新增字段手动合并进去再重启，基本上就能救回来。这个过程不复杂，但手忙脚乱的时候有个备份在手，心态完全不一样。
5.5 基于 Debian 体系的国内发行版上安装 deb 的兼容性
在基于 Debian 体系的国内发行版上装 RustFS，底层逻辑和 Ubuntu/Debian 基本一致，dpkg、apt、gdebi这些工具链都是通用的，DEB 包直接装一般不会有太大问题。要注意的主要是两点：一是系统的软件源可能指向内网源，如果包装的时候缺依赖，apt可能拉不到；二是有些发行版会额外加一层安全策略或签名要求，离线安装时要留意包管理器的提示信息。
反过来，如果是 openEuler 这类 RPM 系国产系统，就不要尝试装 DEB 包了，老老实实走 RPM 安装流程。简单总结就是：不管什么发行版，第一步永远是确认它属于哪个体系，再用对应的包格式。体系认准了，剩下的命令逻辑基本都是通用的。
6. 生产上线前补这几步，RustFS 才能真正放心跑
6.1 密钥和安全基线
RustFS 装好后，默认的 access_key 和 secret_key 必须换掉，这个我在前面已经提过。这里再补充一点建议，密钥不要直接写死在业务代码的配置文件里，至少用环境变量的方式引用，有条件的话接入密钥管理服务。生产环境还应该考虑启用 TLS，不让 S3 流量在网络上明文传输。如果暂时没有证书条件，至少也要保证服务只监听内网地址，通过内部网关或负载均衡对外提供服务。
6.2 备份与升级演练
对象存储上放的数据通常是要长期保存的，备份策略就尤其重要。最基础的方式是定期对/var/lib/rustfs做快照或者 tar 归档，但要注意备份前必须保证数据一致，最好先停写或者用文件系统快照，而不是直接拷贝正在写入的文件。另外，升级动作不要直接在生产环境第一次尝试，先在测试环境完整跑一遍dpkg -i或rpm -Uvh的升级流程，确认配置兼容、数据目录没有异常，再安排生产升级窗口。把安装包和 GPG 公钥缓存到内部软件源，这样生产机器不需要每次从公网拉取，速度和可靠性都有保障。
6.3 日志、监控与容量规划
服务上线只是开始，真正考验人的是后续的运维。日志方面，建议把 journald 的日志转发到集中的日志平台，不要等到出问题才去一台台机器翻日志。监控方面，确认 RustFS 是否暴露 metrics 接口，有的话接到 Prometheus 这类监控系统，重点看请求延迟、错误率、连接数这几个指标。容量规划上，每天至少看一眼数据目录的du -sh和磁盘分区的df -h，超过 70% 就开始规划扩容或清理。
我自己的经验是，新加数据盘时，把data_dir指过去是最顺手的扩容方式。迁移步骤也不复杂：先停服务，用rsync把旧数据目录同步到新盘，修改配置文件里的data_dir，起服务前先校验一次目录结构和权限，再启动确认日志正常。这套流程操作几次后会很熟练，但过程中每一步都不要省，尤其是权限校验，新盘如果不加noexec且属主不对，服务起不来的概率很大。
最后再分享一个小技巧：装完 RustFS 之后，把安装包、配置文件示例、GPG 公钥、升级记录文档化，放在团队的内部知识库里。这不算什么高深技术，但等到半年后要升级或者迁环境的时候，你会发现这些记录比任何人的记忆都可靠。生产落地的本质不是把服务跑起来，而是让这个服务在一台台服务器之间可复制、可维护、可交接。