折腾了好几天终于把宝塔面板和 Rustfs 这件事理顺了。起因其实很简单一台跑着宝塔的服务器想找个轻量的 S3 兼容存储来放网站备份和附件不想每次备份都往云 OSS 传也不想为了一个备份功能再单独装一套 MinIO。后来看到 Rustfs单文件、Rust 写的、内存占用低又兼容 S3 协议理论上应该十几分钟就能搞定结果一路踩坑踩到怀疑人生。这篇文章把这几天遇到的所有问题、排查过程、最后解决的办法都记下来给同样在宝塔里折腾 Rustfs 的朋友做个参考。我把整个流程分成了几个部分先说为什么选 Rustfs 这个方案再说安装和启动阶段的坑然后是 PHP、Pythonboto3分别怎么连接最后是宝塔备份、进程守护这些自动化相关内容。你会发现大部分问题其实都不是 Rustfs 本身的问题而是宝塔环境和 S3 协议之间的一些“默契”没对上但只要把这些点摸清楚后面就顺了。1. 为什么要在宝塔里接 Rustfs先想清楚方案再动手1.1 Rustfs 是什么和 MinIO 有什么区别Rustfs 是一个用 Rust 编写的、兼容 S3 API 的开源文件存储服务最大的特点是单文件分发不依赖 Java、不依赖数据库下载下来直接就能跑。它对外暴露的是标准的 S3 接口也就是说只要是支持 S3 协议的工具和 SDK都可以直接连上去用包括但不限于云厂商的 CLI、宝塔自带的备份插件、Python 的 boto3、PHP 的 AWS SDK 等。提到自建对象存储很多人第一反应是 MinIO。MinIO 确实够成熟功能全面但它的资源占用相对高一些部署起来也要多几步要下客户端、要处理后台账号体系、要配置控制台端口和 API 端口。而 Rustfs 的核心定位就是“轻量”一个二进制文件、一个配置文件、一个数据目录内存占用通常只有几十兆特别适合在低配服务器、NAS、或者只是需要一个内部简单存储的场景使用。从协议角度看Rustfs 和 MinIO 并没有本质区别都是实现 S3 协议。如果你只是想把备份文件传上去、定期拉取、偶尔从代码里读写对象Rustfs 完全够用。但如果你的场景很重比如需要跨地域复制、需要细粒度的生命周期管理、需要对象锁和版本控制那还是直接上 MinIO 或者云厂商 OSS 更省心。我做选择时的判断标准很简单需求越简单越值得用 Rustfs。1.2 我在什么场景下需要它我这次的使用场景很典型一台宝塔面板管理的云服务器部署了网站和一些 API 服务数据库是 PostgreSQL 和 MySQL网站附件、备份文件都在服务器本地磁盘。服务器的数据盘不大备份文件多了很快就满了而且本地备份最大的问题在于“同一台机器上的备份严格来说不算备份”——磁盘坏了或者机器被重置备份一样跟着没。我一开始考虑过直接买云 OSS后来想了一下手头已经有一台闲置的 NAS 和一台低配小鸡NAS 空间大、长期在线与其按月付费给云厂商不如在 NAS 或者那台小鸡上跑一个 Rustfs把宝塔的备份定时同步过去。这样既省了对象存储的费用又实现了“异地备份”的效果。S3 协议的好处在于宝塔面板、各种脚本、代码 SDK 全都认这个协议今天接 Rustfs明天想换回 MinIO 或者云 OSS只需要改端点和密钥代码几乎不用动。如果你和我类似手头有闲置机器想把宝塔的备份、附件、日志放到一个自己能完全掌控的存储里Rustfs 是值得尝试的方案。这篇文章里记录的问题绝大多数都是“宝塔 S3 兼容存储”这个组合本身会遇到的问题和具体用 Rustfs 还是 MinIO 关系不大所以即使你用的是别的 S3 存储也建议往下看。1.3 方案选型时的几个关键判断在动手之前有几个判断会影响后面的整体架构我在踩完坑之后回头看觉得这些判断比安装步骤本身更重要第一Rustfs 部署在哪台机器上。建议单独跑在一台机器上不要和宝塔跑在同一台机器里。因为做备份的一个重要目的就是“单点故障隔离”如果 Rustfs 和宝塔绑定在同一台服务器服务器挂了存储也挂了备份就失去了意义。我就是放在了另外一台闲置机器上用单独的数据目录存储后续维护也互不干扰。第二是否走公网访问。如果宝塔服务器和 Rustfs 部署的机器不在同一个内网那就需要公网访问。这里一定要想清楚传输安全S3 协议本身走 HTTP 也可以但密钥在传输过程中是明文带在请求头里的公网环境必须加一层 HTTPS。常见做法是用 Nginx 反向代理 Rustfs 端口配一张证书宝塔那边连的是 HTTPS 端点。这个点后面会单独讲属于最容易忽略但最要命的问题。第三数据目录的规划。Rustfs 会把所有数据放在你指定的目录下这个目录建议单独挂一块数据盘不要放在系统盘。同时要考虑好目录权限和所有者尤其是启动用户的问题。我在实际使用中因为用户不对先后踩了“无法写入”和“重启后进程权限不对”两个坑后面会详细说。2. 环境准备和 Rustfs 安装问题从这里开始2.1 下载与初始化版本一定要对Rustfs 的安装过程本身非常简单去 Releases 页面下载对应平台的二进制文件传到服务器上给执行权限然后写一个配置文件启动。但就是这一步我第一次就踩了坑——下载了不匹配硬件架构的版本启动直接报错。建议在下载前先检查机器架构uname -m # x86_64 就选 amd64aarch64 就选 arm64解压之后放到/usr/local/bin/rustfs或者你习惯的目录然后chmod x给执行权限。我后来把二进制放在了/opt/rustfs/目录下数据目录放在/data/rustfs-data/配置文件统一放在/opt/rustfs/config.toml这样结构清晰一点也方便写 systemd 服务。配置文件是 TOML 格式最基础的配置长这样# config.toml bind 0.0.0.0:9000 data_dir /data/rustfs-data access_key 你生成的一串随机字符 secret_key 另一串更长的随机字符这里两个最关键的坑第一个坑是bind地址。我第一次配置的时候写的是127.0.0.1:9000结果宝塔服务器那边怎么都连不上当时以为是防火墙问题查了半天才发现是 Rustfs 只监听了本机回环地址外部根本进不来。在宝塔面板所在的服务器场景里如果 Rustfs 部署在独立的机器上bind一定写0.0.0.0:9000确保监听所有网卡。第二个坑是密钥生成。access_key和secret_key一定要用足够长的随机字符串不要用简单密码。我一开始图省事用了一个短密钥看起来能用但当我把访问日志打印出来排查错误时发现短密钥被暴力尝试的次数明显变多。建议直接用openssl rand -hex 16和openssl rand -hex 32生成。2.2 启动之前必须确认的三件事启动 Rustfs 之前有三件事一定先确认好都是我用血的教训换来的第一数据目录权限。如果你用 root 启动 Rustfs数据目录属于 root之后如果切换到其他用户启动就写不进去。宝塔面板的 PHP 进程一般是以www用户运行的如果 PHP 代码要直接写 Rustfs 数据目录有些场景会这样干就必须保证www用户对数据目录有读写权限。建议统一用www用户启动 Rustfs并把数据目录的所有者改成wwwchown -R www:www /data/rustfs-data chown -R www:www /opt/rustfs第二防火墙和宝塔安全组。很多宝塔用户装了 BT 面板之后只会在“面板设置-安全”里放行端口但实际服务器还有一层防火墙firewalld 或 ufw云厂商还有安全组。端口要放行就必须三个地方都放行宝塔安全页、系统防火墙、云厂商安全组。我这次就是宝塔安全页放行了 9000 端口但云厂商安全组忘了加导致外部一直连不上。检查命令如下# 查看系统防火墙状态 firewall-cmd --state # 放行端口firewalld firewall-cmd --permanent --add-port9000/tcp firewall-cmd --reload # 或者使用 ufw ufw allow 9000/tcp第三端口冲突。9000 是 Rustfs 默认端口但很多机器上这个端口可能已经被其他服务占用了尤其是宝塔环境里跑的东西多。启动之前先检查端口占用ss -lntp | grep 9000如果端口被占就换一个不常用的端口比如 9100 或 8900改配置里的bind即可后面所有客户端连接时把端口一起改掉。完成以上三件事后可以用一个简单命令验证 Rustfs 是否启动成功/opt/rustfs/rustfs -c /opt/rustfs/config.toml curl http://127.0.0.1:9000/看到类似S3-compatible storage ready之类的响应就说明服务起来了。如果curl返回connection refused那说明进程可能没起来或者端口不对如果返回超时大概率是防火墙问题回到上面的排查。3. PHP 和网站代码里调用 Rustfs 的实操3.1 宝塔 PHP 环境用 S3 SDK 还是直接用命令行在宝塔环境里写 PHP 代码操作 Rustfs常见的有两种方式一种是用 AWS S3 SDK for PHP更规范也更灵活另一种是直接用命令行调用aws cli或者 curl 发请求。我个人建议如果你的网站代码要读写文件直接用 SDK因为 SDK 帮你处理了签名、重试、超时这些细节代码也好维护。PHP 环境安装 SDK 的步骤很简单宝塔的 PHP 一般都自带 Composercd /www/wwwroot/你的项目目录 composer require aws/aws-sdk-php然后写代码的时候最关键的一点是 S3 客户端的配置。很多人在这个环节踩坑原因是按照 AWS 的默认方式填写配置结果连不上自建服务。区别在于endpoint必须指定为你 Rustfs 的地址同时要设置use_path_style_endpoint为true因为自建 S3 服务通常用的是路径风格访问而不是虚拟主机风格。代码大概长这样?php require vendor/autoload.php; use Aws\S3\S3Client; $s3 new S3Client([ version latest, region us-east-1, endpoint http://你的Rustfs地址:9000, credentials [ key 你的access_key, secret 你的secret_key, ], use_path_style_endpoint true, ]);这段代码里有两个细节值得展开说第一个是region。如果你用 AWS SDK 连接 AWSregion 必须和桶所在的区域一致。但连接自建 S3 服务时理论上 region 可以是任何字符串甚至可以填us-east-1。不过我实测发现如果 region 留空某些版本的 SDK 会报错所以建议还是显式写一个保持一致性。第二个是endpoint要不要带路径。有些教程会让你写成http://地址:9000/你的桶名这是不对的。SDK 会根据你调用的 Bucket 参数自动拼路径endpoint只需要写到服务的根地址。3.2 上传下载的代码样例明确流程连接配置写好之后上传、下载、删除就很简单了。这里给一个完整的例子把流程走一遍// 创建桶如果还没创建的话 try { $s3-createBucket([Bucket my-backup-bucket]); } catch (\Aws\Exception\AwsException $e) { // 桶已存在会抛出 BucketAlreadyExists可以忽略 } // 上传文件 $filePath /www/wwwroot/my-site/backup/backup-2025-01-01.zip; $result $s3-putObject([ Bucket my-backup-bucket, Key backup/backup-2025-01-01.zip, // 注意 Key 是对象在桶里的完整路径 SourceFile $filePath, StorageClass STANDARD, ]); echo 上传完成ETag: . $result[ETag] . \n; // 列出桶里的对象 $objects $s3-listObjects([ Bucket my-backup-bucket, Prefix backup/, // 只列出 backup/ 前缀下的对象 ]); foreach ($objects[Contents] as $obj) { echo $obj[Key] . \n; } // 下载到本地 $s3-getObject([ Bucket my-backup-bucket, Key backup/backup-2025-01-01.zip, SaveAs /tmp/restore-2025-01-01.zip, ]); // 删除对象 $s3-deleteObject([ Bucket my-backup-bucket, Key backup/backup-2025-01-01.zip, ]);这里有一个很容易忽略的点createBucket这一步。S3 协议里对象必须存储在某个桶里桶是需要先创建的。Rustfs 本身在启动时不会自动创建默认桶你必须在代码里或者用客户端先创建。宝塔面板的备份插件在配置时也会要求填写桶名如果你还没在 Rustfs 里创建对应的桶插件测试连接会一直报“桶不存在”这一步很多人会卡住。3.3 权限和路径的坑实际测试后的心得PHP 在宝塔里跑的时候最容易出的问题就是文件权限和路径分隔符。AWS SDK 里Key参数使用的是/作为路径分隔符这个没问题但如果你的文件路径本身就含有反斜杠或者空格建议先处理一下否则上传后的对象名会和你预期的不一致。另外一个我踩到的坑是PHP 代码里如果调用getObject时指定了SaveAs参数目标目录必须可写而且目录必须存在SDK 不会自动创建目录。我一开始没注意这个下载的时候一直报“无法打开本地文件”后来手动创建了目录才解决。还有一个和 PHP 配置相关的坑宝塔的 PHP 默认open_basedir可能会有路径限制如果你在网站根目录外的路径读写文件会被 PHP 拦截。这个和 Rustfs 本身没有关系但只要你的 PHP 代码涉及临时目录、备份目录等非站点目录就会中招。解决方法是把需要访问的目录加到open_basedir配置里或者干脆关闭限制如果有权限的话。4. Python/boto3 连接 Rustfs 的完整姿势4.1 boto3 连接配置别再被 endpoint 卡住Python 场景里最常用的 S3 客户端库是 boto3这也是热搜词里“boto3如何连接rustfs”常见的来源。boto3 连接 Rustfs 和连接 AWS S3 最大的区别同样在endpoint_url参数上如果你只填aws_access_key_id和aws_secret_access_key不填endpoint_urlboto3 默认会把请求发到 AWS S3 的正式地址自然连不上你的 Rustfs。正确写法如下import boto3 from botocore.config import Config s3 boto3.client( s3, endpoint_urlhttp://你的Rustfs地址:9000, aws_access_key_id你的access_key, aws_secret_access_key你的secret_key, region_nameus-east-1, configConfig( signature_versions3v4, s3{addressing_style: path}, connect_timeout5, read_timeout10, ) ) # 测试连接列出所有桶 response s3.list_buckets() print(连接成功桶列表) for bucket in response[Buckets]: print(f - {bucket[Name]})很多人的坑在于signature_version。Rustfs 默认使用 S3 签名协议但 boto3 在不同版本里默认的签名版本可能不同。如果签名版本不匹配你会看到类似SignatureDoesNotMatch或者The request signature we calculated does not match the signature you provided的报错。强制指定signature_versions3v4能解决绝大多数签名问题。4.2 签名不对的排查网上方案未必适合你签名报错这个问题网上搜索很多解决方案但很多时候它们的原理并不适用于 Rustfs。我把我实际排查的过程记录下来给大家一个可复用的思路第一步确定客户端时间和服务端时间一致。S3 签名里带时间戳如果客户端时间偏移超过几分钟签名校验就会失败。在服务器上分别执行date然后用ntpdate或chronyc同步时间。我遇到过一次诡异的 403最后发现是运行脚本的机器时间慢了 4 分钟。第二步确认密钥没有多余字符。有时候从网页复制密钥可能复制到空格或者不可见字符导致签名计算错误。建议在代码里把密钥打印出来人眼确认一下长度和前缀。第三步确认addressing_style。boto3 默认在某些配置下使用 virtual-hosted style也就是bucket.endpoint的形式访问而自建服务通常只支持 path style也就是endpoint/bucket的形式。这个不匹配会导致连接不上或者签名报错。在Config里明确写上s3{addressing_style: path}可以避免这个问题。如果以上都确认过还不行抓包看一下实际发送的 Authorization 头看看签名里的 AccessKey 是不是和你配置的一致。这一步比较进阶但能很直观地定位问题。我最终就是通过看请求头确认了密钥被某些环境变量覆盖了改成显式传入之后就好了。4.3 桶和目录的命名规范提前做好规划用 Python 和 boto3 操作 Rustfs建议在写代码之前就规划好桶名和对象 Key 的命名规范。因为对象存储的“目录”实际上是对象 Key 的前缀它不像本地文件系统那样有真实的层级结构。比如你上传一个对象Key 是backup/site/2025-01-01.tar.gz那在控制台里看起来就像是backup/site/目录下的文件其实它只是一个扁平的字符串。命名规范上我个人总结了几条经验桶名使用小写字母、数字、短横线不要用下划线因为 S3 协议对桶名有严格限制某些 S3 兼容实现不支持下划线。对象的 Key 统一用/作为分隔符不要混用\。日期前缀建议用YYYY-MM-DD形式方便按时间范围列出对象。如果有多台服务器同时使用同一个 Rustfs建议在桶名或者 Key 前缀里加上服务器标识比如server-a/和server-b/避免对象名冲突。这些规范看似简单但真的到了备份文件多了、需要定期清理老备份的时候命名规范能让你少花很多功夫。比如清理 30 天前的备份只需要用list_objects加Prefix前缀然后按LastModified过滤删除就好。5. 宝塔备份、进程守护和自动化5.1 让备份任务定期跑起来宝塔计划任务宝塔面板最基本的用法是“计划任务”可以在指定时间执行 shell 脚本或 Python 脚本。只要 Rustfs 连接通了剩下的工作就是写一个备份脚本然后挂到计划任务里。我这里用 boto3 写了一个简单的备份上传脚本核心逻辑是压缩网站目录、上传到 Rustfs、清理本地临时文件#!/bin/bash # /opt/scripts/backup_site.sh # 变量定义 SITE_DIR/www/wwwroot/my-site BACKUP_DIR/tmp/my-site-backup DATE$(date %Y-%m-%d) BACKUP_FILE$BACKUP_DIR/site-$DATE.tar.gz # 创建临时目录 mkdir -p $BACKUP_DIR # 压缩网站目录 tar -czf $BACKUP_FILE $SITE_DIR # 调用 Python 脚本上传 python3 /opt/scripts/upload_to_rustfs.py $BACKUP_FILE然后upload_to_rustfs.py里就是 4.1 节写的 boto3 上传逻辑用命令行参数接收文件路径上传后打印结果。最后在宝塔的“计划任务”里添加每天凌晨 2 点执行这个脚本即可。这个方案的好处是简单直接不依赖宝塔内置的“备份到对象存储”插件也不受插件对 S3 兼容存储支持度的限制。缺点是需要自己管理备份文件的保留策略不过这也是可控的在脚本末尾加一段删除远端 30 天前文件的操作或者用list_objects筛选后删除即可。5.2 进程守护的正确打开方式systemd 优先Rustfs 作为后台服务一旦进程挂了所有连接都会失败。宝塔面板提供了“进程守护管理器”插件很多人的第一反应是用它来守护 Rustfs。这个思路没错但我在实际使用中发现了一些细节问题导致守护效果不理想。宝塔的“进程守护管理器”底层用的是 Supervisor。如果你在 Supervisor 里配置启动命令要注意两个点工作目录和启动用户。Rustfs 的配置文件里如果用了相对路径而 Supervisor 的工作目录设置不对就会找不到配置文件或者数据目录。另外如果你用 root 用户启动 Supervisor 管理的进程Rustfs 的数据目录所有者就必须是 root否则会写不进去。为了统一我最终选择了用 systemd 来管理 Rustfs宝塔进程守护则留给其他的 Web 服务进程。systemd 服务文件长这样# /etc/systemd/system/rustfs.service [Unit] DescriptionRustfs S3-compatible storage Afternetwork.target [Service] Typesimple Userwww Groupwww WorkingDirectory/opt/rustfs ExecStart/opt/rustfs/rustfs -c /opt/rustfs/config.toml Restartalways RestartSec3 [Install] WantedBymulti-user.target启用服务systemctl daemon-reload systemctl enable rustfs systemctl start rustfs systemctl status rustfs为什么我更推荐 systemd 而不是 Supervisor因为 systemd 是系统级服务管理器开机自启、崩溃重启、日志管理都更原生化也不依赖宝塔面板启动就能跑。唯一要注意的是宝塔面板的“计划任务”和系统 crontab 是两套你如果用 systemd 管理 Rustfs记得不要同时用 Supervisor 也去拉一个 Rustfs 进程否则端口会被占用两个进程会互相打架。5.3 宝塔备份 pgsql 报错的处理热搜词里有一个特别具体的宝塔无法备份 pgsql。这个问题我恰好遇到过而且一开始误以为是 Rustfs 的问题排查了很久。现象是这样的宝塔面板里创建了 PostgreSQL 数据库备份任务备份目标是“对象存储”配置好 Rustfs 的端点、密钥和桶名后测试连接是成功的但正式备份时报错错误信息提示无法连接到数据库或备份失败。检查日志发现是pg_dump执行失败。后来确认了问题根因宝塔面板备份 pgsql 依赖系统里安装的pg_dump工具。如果你只安装了 PostgreSQL 数据库服务但没安装对应的客户端工具postgresql-client或者pg_dump的版本和数据库版本不兼容就会导致备份失败。这个和 Rustfs 本身一毛钱关系都没有。解决办法很简单先确认pg_dump是否存在并且版本匹配which pg_dump pg_dump --version如果没有按照 PostgreSQL 版本安装对应的客户端工具。装好之后再重新执行备份任务就正常了。如果你用宝塔的“备份到对象存储”插件时遇到类似的问题建议先看日志判断失败发生在“备份数据库”阶段还是“上传到对象存储”阶段不要一上来就怀疑 Rustfs 有兼容性问题。另外如果你要备份 PostgreSQL 数据库到 Rustfs我建议直接用宝塔的“数据库备份”功能先把备份文件生成到本地然后在计划任务里通过脚本上传对象存储这样比直接配置“备份到对象存储”更可控出错时也更容易排查。6. 常见问题排查速查表把我这次踩过的坑、以及与朋友交流中高频出现的问题整理成一张速查表方便大家直接对照症状可能原因解决方式外部无法访问 Rustfscurl 超时防火墙/安全组未放行Rustfs 监听 127.0.0.1bind 改为 0.0.0.0放行宝塔安全页、系统防火墙、云安全组boto3 连接报 SignatureDoesNotMatch客户端时间与服务端不一致签名版本不匹配同步时间显式指定 signature_versions3v4SDK 提示 Unable to connectendpoint_url 缺失或写错端口不对检查 endpoint_url 是否包含端口确认 Rustfs 监听端口创建桶报 BucketAlreadyExists桶已存在但客户端不知道忽略该异常或先调用 head_bucket 判断PHP 上传成功但网页访问 404对象 Key 路径和预期不一致查看 SDK 生成的 Key确认是相对路径而非绝对路径宝塔备份 pgsql 失败pg_dump 未安装或版本不匹配安装匹配的 postgresql-client重启后 Rustfs 服务没起来没有配置 systemd 或 Supervisor进程守护配置错误使用 systemd 的 Restartalways 配置上传大文件时连接断开超时时间太短带宽受限调大 read_timeout或分片上传跨内网访问很慢默认走了公网流量确认 endpoint_url 是否填了内网地址7. 断点续传和分片上传Rustfs 也要会处理7.1 什么时候需要分片上传如果只是传一些小备份文件put_object就够了。但当你需要把数据库的完整备份、整站打包文件甚至几个 GB 的日志归档传到 Rustfs 时直接用put_object很容易出问题一方面网络不稳定会中途失败另一方面服务端对单次请求大小可能有限制。S3 协议里解决这个问题的方式是多部分上传Multipart Upload。把一个大文件拆成多个分片依次上传最后组装成一个对象。好处有三个单个分片失败只需要重传这个分片不用整个文件从头再来可以并发上传多个分片充分利用带宽可以随时查看上传进度。boto3 的upload_file方法会自动处理分片逻辑通常不需要手动实现每个步骤你只需要调用一次s3.upload_file( /path/to/large-backup.tar.gz, my-backup-bucket, backup/large-backup.tar.gz )upload_file底层会在文件大小超过阈值时自动切换为多部分上传并且可以通过Config参数调整分片大小from boto3.s3.transfer import TransferConfig config TransferConfig( multipart_threshold8 * 1024 * 1024, # 超过8MB触发分片 multipart_chunksize8 * 1024 * 1024, # 每个分片8MB max_concurrency4, # 并发数 ) s3.upload_file( /path/to/large-backup.tar.gz, my-backup-bucket, backup/large-backup.tar.gz, Configconfig )PHP SDK 也有对应的MultipartUploader如果文件超过 100MB建议直接上 MultipartUploader 而不是putObject能在很大程度上避免大文件上传超时问题。7.2 分片上传过程中的常见坑分片上传虽然方便但有两个坑值得单独说第一个是分片未完成会占用服务端存储。如果你启动了一个多部分上传但是中途放弃了已上传的分片会一直挂在服务端很多服务商会保留一段时间或者直到你调用abort_multipart_upload。你每次用list_multipart_uploads可以看到这些未完成的上传记录。清理方法# 列出所有未完成的多部分上传 uploads s3.list_multipart_uploads(Bucketmy-backup-bucket) if Uploads in uploads: for upload in uploads[Uploads]: s3.abort_multipart_upload( Bucketmy-backup-bucket, Keyupload[Key], UploadIdupload[UploadId] )第二个是分片上传完成后服务端返回的 ETag 不是简单的 MD5而是一个带分片数量的后缀。如果你依赖 ETag 做完整性校验直接用这个值会踩坑。更可靠的做法是在上传完成后从 Rustfs 下载对象并计算 MD5 或 SHA256 进行比对。7.3 备份到远端后怎么验证完整性文件传上去不等于备份成功了至少要做一次可恢复性验证。我的习惯是每次上传完成后在脚本里调用head_object获取对象大小和本地文件大小比对如果一致基本可以确认传输正常。如果对安全性要求更高再下载回来算一下哈希。在脚本里做校验的示例# 获取远端对象信息 meta s3.head_object(Bucketmy-backup-bucket, Keyobject_key) remote_size meta[ContentLength] # 对比本地文件大小 local_size os.path.getsize(local_path) if remote_size ! local_size: raise Exception(f大小不一致: local{local_size}, remote{remote_size}) else: print(f校验通过: {local_size} bytes)这种做法不能检测文件内容被篡改但足以发现传输过程中的数据损坏。对大多数备份场景来说够了。8. 写到最后的一些体会折腾完这一整套我最大的感受是Rustfs 本身其实很稳真正容易出问题的地方几乎都在“S3 协议兼容性”和“宝塔环境自身限制”这两个层面。S3 客户端各有各的默认行为有的默认虚拟主机风格访问有的默认虚拟签名版本不对这些默认值在连 AWS 时都恰到好处一连自建服务就全开始捣乱。所以最关键的还是要掌握排查思路看到签名报错往时间、密钥、签名版本三个方向查看到连接不上往监听地址、防火墙、安全组三个方向查大方向对了问题都能快速收敛。对我个人来说最实用的一个经验是不要一开始就引入复杂的自动化体系先把“手动上传一个文件到 Rustfs”这个最小闭环打通再逐步加上备份脚本、计划任务、进程守护、分片上传。每一步都验证通过再走下一步这样即使出问题也知道该去哪个环节排查。如果后面还有机会我会进一步整理 Rustfs 在 Docker 环境下的部署方式以及如何把它和飞牛 NAS 这类家庭存储设备配合使用。到时候再出一篇续篇。 宝塔面板+Rustfs：S3兼容存储部署与备份全攻略
折腾了好几天终于把宝塔面板和 Rustfs 这件事理顺了。起因其实很简单一台跑着宝塔的服务器想找个轻量的 S3 兼容存储来放网站备份和附件不想每次备份都往云 OSS 传也不想为了一个备份功能再单独装一套 MinIO。后来看到 Rustfs单文件、Rust 写的、内存占用低又兼容 S3 协议理论上应该十几分钟就能搞定结果一路踩坑踩到怀疑人生。这篇文章把这几天遇到的所有问题、排查过程、最后解决的办法都记下来给同样在宝塔里折腾 Rustfs 的朋友做个参考。我把整个流程分成了几个部分先说为什么选 Rustfs 这个方案再说安装和启动阶段的坑然后是 PHP、Pythonboto3分别怎么连接最后是宝塔备份、进程守护这些自动化相关内容。你会发现大部分问题其实都不是 Rustfs 本身的问题而是宝塔环境和 S3 协议之间的一些“默契”没对上但只要把这些点摸清楚后面就顺了。1. 为什么要在宝塔里接 Rustfs先想清楚方案再动手1.1 Rustfs 是什么和 MinIO 有什么区别Rustfs 是一个用 Rust 编写的、兼容 S3 API 的开源文件存储服务最大的特点是单文件分发不依赖 Java、不依赖数据库下载下来直接就能跑。它对外暴露的是标准的 S3 接口也就是说只要是支持 S3 协议的工具和 SDK都可以直接连上去用包括但不限于云厂商的 CLI、宝塔自带的备份插件、Python 的 boto3、PHP 的 AWS SDK 等。提到自建对象存储很多人第一反应是 MinIO。MinIO 确实够成熟功能全面但它的资源占用相对高一些部署起来也要多几步要下客户端、要处理后台账号体系、要配置控制台端口和 API 端口。而 Rustfs 的核心定位就是“轻量”一个二进制文件、一个配置文件、一个数据目录内存占用通常只有几十兆特别适合在低配服务器、NAS、或者只是需要一个内部简单存储的场景使用。从协议角度看Rustfs 和 MinIO 并没有本质区别都是实现 S3 协议。如果你只是想把备份文件传上去、定期拉取、偶尔从代码里读写对象Rustfs 完全够用。但如果你的场景很重比如需要跨地域复制、需要细粒度的生命周期管理、需要对象锁和版本控制那还是直接上 MinIO 或者云厂商 OSS 更省心。我做选择时的判断标准很简单需求越简单越值得用 Rustfs。1.2 我在什么场景下需要它我这次的使用场景很典型一台宝塔面板管理的云服务器部署了网站和一些 API 服务数据库是 PostgreSQL 和 MySQL网站附件、备份文件都在服务器本地磁盘。服务器的数据盘不大备份文件多了很快就满了而且本地备份最大的问题在于“同一台机器上的备份严格来说不算备份”——磁盘坏了或者机器被重置备份一样跟着没。我一开始考虑过直接买云 OSS后来想了一下手头已经有一台闲置的 NAS 和一台低配小鸡NAS 空间大、长期在线与其按月付费给云厂商不如在 NAS 或者那台小鸡上跑一个 Rustfs把宝塔的备份定时同步过去。这样既省了对象存储的费用又实现了“异地备份”的效果。S3 协议的好处在于宝塔面板、各种脚本、代码 SDK 全都认这个协议今天接 Rustfs明天想换回 MinIO 或者云 OSS只需要改端点和密钥代码几乎不用动。如果你和我类似手头有闲置机器想把宝塔的备份、附件、日志放到一个自己能完全掌控的存储里Rustfs 是值得尝试的方案。这篇文章里记录的问题绝大多数都是“宝塔 S3 兼容存储”这个组合本身会遇到的问题和具体用 Rustfs 还是 MinIO 关系不大所以即使你用的是别的 S3 存储也建议往下看。1.3 方案选型时的几个关键判断在动手之前有几个判断会影响后面的整体架构我在踩完坑之后回头看觉得这些判断比安装步骤本身更重要第一Rustfs 部署在哪台机器上。建议单独跑在一台机器上不要和宝塔跑在同一台机器里。因为做备份的一个重要目的就是“单点故障隔离”如果 Rustfs 和宝塔绑定在同一台服务器服务器挂了存储也挂了备份就失去了意义。我就是放在了另外一台闲置机器上用单独的数据目录存储后续维护也互不干扰。第二是否走公网访问。如果宝塔服务器和 Rustfs 部署的机器不在同一个内网那就需要公网访问。这里一定要想清楚传输安全S3 协议本身走 HTTP 也可以但密钥在传输过程中是明文带在请求头里的公网环境必须加一层 HTTPS。常见做法是用 Nginx 反向代理 Rustfs 端口配一张证书宝塔那边连的是 HTTPS 端点。这个点后面会单独讲属于最容易忽略但最要命的问题。第三数据目录的规划。Rustfs 会把所有数据放在你指定的目录下这个目录建议单独挂一块数据盘不要放在系统盘。同时要考虑好目录权限和所有者尤其是启动用户的问题。我在实际使用中因为用户不对先后踩了“无法写入”和“重启后进程权限不对”两个坑后面会详细说。2. 环境准备和 Rustfs 安装问题从这里开始2.1 下载与初始化版本一定要对Rustfs 的安装过程本身非常简单去 Releases 页面下载对应平台的二进制文件传到服务器上给执行权限然后写一个配置文件启动。但就是这一步我第一次就踩了坑——下载了不匹配硬件架构的版本启动直接报错。建议在下载前先检查机器架构uname -m # x86_64 就选 amd64aarch64 就选 arm64解压之后放到/usr/local/bin/rustfs或者你习惯的目录然后chmod x给执行权限。我后来把二进制放在了/opt/rustfs/目录下数据目录放在/data/rustfs-data/配置文件统一放在/opt/rustfs/config.toml这样结构清晰一点也方便写 systemd 服务。配置文件是 TOML 格式最基础的配置长这样# config.toml bind 0.0.0.0:9000 data_dir /data/rustfs-data access_key 你生成的一串随机字符 secret_key 另一串更长的随机字符这里两个最关键的坑第一个坑是bind地址。我第一次配置的时候写的是127.0.0.1:9000结果宝塔服务器那边怎么都连不上当时以为是防火墙问题查了半天才发现是 Rustfs 只监听了本机回环地址外部根本进不来。在宝塔面板所在的服务器场景里如果 Rustfs 部署在独立的机器上bind一定写0.0.0.0:9000确保监听所有网卡。第二个坑是密钥生成。access_key和secret_key一定要用足够长的随机字符串不要用简单密码。我一开始图省事用了一个短密钥看起来能用但当我把访问日志打印出来排查错误时发现短密钥被暴力尝试的次数明显变多。建议直接用openssl rand -hex 16和openssl rand -hex 32生成。2.2 启动之前必须确认的三件事启动 Rustfs 之前有三件事一定先确认好都是我用血的教训换来的第一数据目录权限。如果你用 root 启动 Rustfs数据目录属于 root之后如果切换到其他用户启动就写不进去。宝塔面板的 PHP 进程一般是以www用户运行的如果 PHP 代码要直接写 Rustfs 数据目录有些场景会这样干就必须保证www用户对数据目录有读写权限。建议统一用www用户启动 Rustfs并把数据目录的所有者改成wwwchown -R www:www /data/rustfs-data chown -R www:www /opt/rustfs第二防火墙和宝塔安全组。很多宝塔用户装了 BT 面板之后只会在“面板设置-安全”里放行端口但实际服务器还有一层防火墙firewalld 或 ufw云厂商还有安全组。端口要放行就必须三个地方都放行宝塔安全页、系统防火墙、云厂商安全组。我这次就是宝塔安全页放行了 9000 端口但云厂商安全组忘了加导致外部一直连不上。检查命令如下# 查看系统防火墙状态 firewall-cmd --state # 放行端口firewalld firewall-cmd --permanent --add-port9000/tcp firewall-cmd --reload # 或者使用 ufw ufw allow 9000/tcp第三端口冲突。9000 是 Rustfs 默认端口但很多机器上这个端口可能已经被其他服务占用了尤其是宝塔环境里跑的东西多。启动之前先检查端口占用ss -lntp | grep 9000如果端口被占就换一个不常用的端口比如 9100 或 8900改配置里的bind即可后面所有客户端连接时把端口一起改掉。完成以上三件事后可以用一个简单命令验证 Rustfs 是否启动成功/opt/rustfs/rustfs -c /opt/rustfs/config.toml curl http://127.0.0.1:9000/看到类似S3-compatible storage ready之类的响应就说明服务起来了。如果curl返回connection refused那说明进程可能没起来或者端口不对如果返回超时大概率是防火墙问题回到上面的排查。3. PHP 和网站代码里调用 Rustfs 的实操3.1 宝塔 PHP 环境用 S3 SDK 还是直接用命令行在宝塔环境里写 PHP 代码操作 Rustfs常见的有两种方式一种是用 AWS S3 SDK for PHP更规范也更灵活另一种是直接用命令行调用aws cli或者 curl 发请求。我个人建议如果你的网站代码要读写文件直接用 SDK因为 SDK 帮你处理了签名、重试、超时这些细节代码也好维护。PHP 环境安装 SDK 的步骤很简单宝塔的 PHP 一般都自带 Composercd /www/wwwroot/你的项目目录 composer require aws/aws-sdk-php然后写代码的时候最关键的一点是 S3 客户端的配置。很多人在这个环节踩坑原因是按照 AWS 的默认方式填写配置结果连不上自建服务。区别在于endpoint必须指定为你 Rustfs 的地址同时要设置use_path_style_endpoint为true因为自建 S3 服务通常用的是路径风格访问而不是虚拟主机风格。代码大概长这样?php require vendor/autoload.php; use Aws\S3\S3Client; $s3 new S3Client([ version latest, region us-east-1, endpoint http://你的Rustfs地址:9000, credentials [ key 你的access_key, secret 你的secret_key, ], use_path_style_endpoint true, ]);这段代码里有两个细节值得展开说第一个是region。如果你用 AWS SDK 连接 AWSregion 必须和桶所在的区域一致。但连接自建 S3 服务时理论上 region 可以是任何字符串甚至可以填us-east-1。不过我实测发现如果 region 留空某些版本的 SDK 会报错所以建议还是显式写一个保持一致性。第二个是endpoint要不要带路径。有些教程会让你写成http://地址:9000/你的桶名这是不对的。SDK 会根据你调用的 Bucket 参数自动拼路径endpoint只需要写到服务的根地址。3.2 上传下载的代码样例明确流程连接配置写好之后上传、下载、删除就很简单了。这里给一个完整的例子把流程走一遍// 创建桶如果还没创建的话 try { $s3-createBucket([Bucket my-backup-bucket]); } catch (\Aws\Exception\AwsException $e) { // 桶已存在会抛出 BucketAlreadyExists可以忽略 } // 上传文件 $filePath /www/wwwroot/my-site/backup/backup-2025-01-01.zip; $result $s3-putObject([ Bucket my-backup-bucket, Key backup/backup-2025-01-01.zip, // 注意 Key 是对象在桶里的完整路径 SourceFile $filePath, StorageClass STANDARD, ]); echo 上传完成ETag: . $result[ETag] . \n; // 列出桶里的对象 $objects $s3-listObjects([ Bucket my-backup-bucket, Prefix backup/, // 只列出 backup/ 前缀下的对象 ]); foreach ($objects[Contents] as $obj) { echo $obj[Key] . \n; } // 下载到本地 $s3-getObject([ Bucket my-backup-bucket, Key backup/backup-2025-01-01.zip, SaveAs /tmp/restore-2025-01-01.zip, ]); // 删除对象 $s3-deleteObject([ Bucket my-backup-bucket, Key backup/backup-2025-01-01.zip, ]);这里有一个很容易忽略的点createBucket这一步。S3 协议里对象必须存储在某个桶里桶是需要先创建的。Rustfs 本身在启动时不会自动创建默认桶你必须在代码里或者用客户端先创建。宝塔面板的备份插件在配置时也会要求填写桶名如果你还没在 Rustfs 里创建对应的桶插件测试连接会一直报“桶不存在”这一步很多人会卡住。3.3 权限和路径的坑实际测试后的心得PHP 在宝塔里跑的时候最容易出的问题就是文件权限和路径分隔符。AWS SDK 里Key参数使用的是/作为路径分隔符这个没问题但如果你的文件路径本身就含有反斜杠或者空格建议先处理一下否则上传后的对象名会和你预期的不一致。另外一个我踩到的坑是PHP 代码里如果调用getObject时指定了SaveAs参数目标目录必须可写而且目录必须存在SDK 不会自动创建目录。我一开始没注意这个下载的时候一直报“无法打开本地文件”后来手动创建了目录才解决。还有一个和 PHP 配置相关的坑宝塔的 PHP 默认open_basedir可能会有路径限制如果你在网站根目录外的路径读写文件会被 PHP 拦截。这个和 Rustfs 本身没有关系但只要你的 PHP 代码涉及临时目录、备份目录等非站点目录就会中招。解决方法是把需要访问的目录加到open_basedir配置里或者干脆关闭限制如果有权限的话。4. Python/boto3 连接 Rustfs 的完整姿势4.1 boto3 连接配置别再被 endpoint 卡住Python 场景里最常用的 S3 客户端库是 boto3这也是热搜词里“boto3如何连接rustfs”常见的来源。boto3 连接 Rustfs 和连接 AWS S3 最大的区别同样在endpoint_url参数上如果你只填aws_access_key_id和aws_secret_access_key不填endpoint_urlboto3 默认会把请求发到 AWS S3 的正式地址自然连不上你的 Rustfs。正确写法如下import boto3 from botocore.config import Config s3 boto3.client( s3, endpoint_urlhttp://你的Rustfs地址:9000, aws_access_key_id你的access_key, aws_secret_access_key你的secret_key, region_nameus-east-1, configConfig( signature_versions3v4, s3{addressing_style: path}, connect_timeout5, read_timeout10, ) ) # 测试连接列出所有桶 response s3.list_buckets() print(连接成功桶列表) for bucket in response[Buckets]: print(f - {bucket[Name]})很多人的坑在于signature_version。Rustfs 默认使用 S3 签名协议但 boto3 在不同版本里默认的签名版本可能不同。如果签名版本不匹配你会看到类似SignatureDoesNotMatch或者The request signature we calculated does not match the signature you provided的报错。强制指定signature_versions3v4能解决绝大多数签名问题。4.2 签名不对的排查网上方案未必适合你签名报错这个问题网上搜索很多解决方案但很多时候它们的原理并不适用于 Rustfs。我把我实际排查的过程记录下来给大家一个可复用的思路第一步确定客户端时间和服务端时间一致。S3 签名里带时间戳如果客户端时间偏移超过几分钟签名校验就会失败。在服务器上分别执行date然后用ntpdate或chronyc同步时间。我遇到过一次诡异的 403最后发现是运行脚本的机器时间慢了 4 分钟。第二步确认密钥没有多余字符。有时候从网页复制密钥可能复制到空格或者不可见字符导致签名计算错误。建议在代码里把密钥打印出来人眼确认一下长度和前缀。第三步确认addressing_style。boto3 默认在某些配置下使用 virtual-hosted style也就是bucket.endpoint的形式访问而自建服务通常只支持 path style也就是endpoint/bucket的形式。这个不匹配会导致连接不上或者签名报错。在Config里明确写上s3{addressing_style: path}可以避免这个问题。如果以上都确认过还不行抓包看一下实际发送的 Authorization 头看看签名里的 AccessKey 是不是和你配置的一致。这一步比较进阶但能很直观地定位问题。我最终就是通过看请求头确认了密钥被某些环境变量覆盖了改成显式传入之后就好了。4.3 桶和目录的命名规范提前做好规划用 Python 和 boto3 操作 Rustfs建议在写代码之前就规划好桶名和对象 Key 的命名规范。因为对象存储的“目录”实际上是对象 Key 的前缀它不像本地文件系统那样有真实的层级结构。比如你上传一个对象Key 是backup/site/2025-01-01.tar.gz那在控制台里看起来就像是backup/site/目录下的文件其实它只是一个扁平的字符串。命名规范上我个人总结了几条经验桶名使用小写字母、数字、短横线不要用下划线因为 S3 协议对桶名有严格限制某些 S3 兼容实现不支持下划线。对象的 Key 统一用/作为分隔符不要混用\。日期前缀建议用YYYY-MM-DD形式方便按时间范围列出对象。如果有多台服务器同时使用同一个 Rustfs建议在桶名或者 Key 前缀里加上服务器标识比如server-a/和server-b/避免对象名冲突。这些规范看似简单但真的到了备份文件多了、需要定期清理老备份的时候命名规范能让你少花很多功夫。比如清理 30 天前的备份只需要用list_objects加Prefix前缀然后按LastModified过滤删除就好。5. 宝塔备份、进程守护和自动化5.1 让备份任务定期跑起来宝塔计划任务宝塔面板最基本的用法是“计划任务”可以在指定时间执行 shell 脚本或 Python 脚本。只要 Rustfs 连接通了剩下的工作就是写一个备份脚本然后挂到计划任务里。我这里用 boto3 写了一个简单的备份上传脚本核心逻辑是压缩网站目录、上传到 Rustfs、清理本地临时文件#!/bin/bash # /opt/scripts/backup_site.sh # 变量定义 SITE_DIR/www/wwwroot/my-site BACKUP_DIR/tmp/my-site-backup DATE$(date %Y-%m-%d) BACKUP_FILE$BACKUP_DIR/site-$DATE.tar.gz # 创建临时目录 mkdir -p $BACKUP_DIR # 压缩网站目录 tar -czf $BACKUP_FILE $SITE_DIR # 调用 Python 脚本上传 python3 /opt/scripts/upload_to_rustfs.py $BACKUP_FILE然后upload_to_rustfs.py里就是 4.1 节写的 boto3 上传逻辑用命令行参数接收文件路径上传后打印结果。最后在宝塔的“计划任务”里添加每天凌晨 2 点执行这个脚本即可。这个方案的好处是简单直接不依赖宝塔内置的“备份到对象存储”插件也不受插件对 S3 兼容存储支持度的限制。缺点是需要自己管理备份文件的保留策略不过这也是可控的在脚本末尾加一段删除远端 30 天前文件的操作或者用list_objects筛选后删除即可。5.2 进程守护的正确打开方式systemd 优先Rustfs 作为后台服务一旦进程挂了所有连接都会失败。宝塔面板提供了“进程守护管理器”插件很多人的第一反应是用它来守护 Rustfs。这个思路没错但我在实际使用中发现了一些细节问题导致守护效果不理想。宝塔的“进程守护管理器”底层用的是 Supervisor。如果你在 Supervisor 里配置启动命令要注意两个点工作目录和启动用户。Rustfs 的配置文件里如果用了相对路径而 Supervisor 的工作目录设置不对就会找不到配置文件或者数据目录。另外如果你用 root 用户启动 Supervisor 管理的进程Rustfs 的数据目录所有者就必须是 root否则会写不进去。为了统一我最终选择了用 systemd 来管理 Rustfs宝塔进程守护则留给其他的 Web 服务进程。systemd 服务文件长这样# /etc/systemd/system/rustfs.service [Unit] DescriptionRustfs S3-compatible storage Afternetwork.target [Service] Typesimple Userwww Groupwww WorkingDirectory/opt/rustfs ExecStart/opt/rustfs/rustfs -c /opt/rustfs/config.toml Restartalways RestartSec3 [Install] WantedBymulti-user.target启用服务systemctl daemon-reload systemctl enable rustfs systemctl start rustfs systemctl status rustfs为什么我更推荐 systemd 而不是 Supervisor因为 systemd 是系统级服务管理器开机自启、崩溃重启、日志管理都更原生化也不依赖宝塔面板启动就能跑。唯一要注意的是宝塔面板的“计划任务”和系统 crontab 是两套你如果用 systemd 管理 Rustfs记得不要同时用 Supervisor 也去拉一个 Rustfs 进程否则端口会被占用两个进程会互相打架。5.3 宝塔备份 pgsql 报错的处理热搜词里有一个特别具体的宝塔无法备份 pgsql。这个问题我恰好遇到过而且一开始误以为是 Rustfs 的问题排查了很久。现象是这样的宝塔面板里创建了 PostgreSQL 数据库备份任务备份目标是“对象存储”配置好 Rustfs 的端点、密钥和桶名后测试连接是成功的但正式备份时报错错误信息提示无法连接到数据库或备份失败。检查日志发现是pg_dump执行失败。后来确认了问题根因宝塔面板备份 pgsql 依赖系统里安装的pg_dump工具。如果你只安装了 PostgreSQL 数据库服务但没安装对应的客户端工具postgresql-client或者pg_dump的版本和数据库版本不兼容就会导致备份失败。这个和 Rustfs 本身一毛钱关系都没有。解决办法很简单先确认pg_dump是否存在并且版本匹配which pg_dump pg_dump --version如果没有按照 PostgreSQL 版本安装对应的客户端工具。装好之后再重新执行备份任务就正常了。如果你用宝塔的“备份到对象存储”插件时遇到类似的问题建议先看日志判断失败发生在“备份数据库”阶段还是“上传到对象存储”阶段不要一上来就怀疑 Rustfs 有兼容性问题。另外如果你要备份 PostgreSQL 数据库到 Rustfs我建议直接用宝塔的“数据库备份”功能先把备份文件生成到本地然后在计划任务里通过脚本上传对象存储这样比直接配置“备份到对象存储”更可控出错时也更容易排查。6. 常见问题排查速查表把我这次踩过的坑、以及与朋友交流中高频出现的问题整理成一张速查表方便大家直接对照症状可能原因解决方式外部无法访问 Rustfscurl 超时防火墙/安全组未放行Rustfs 监听 127.0.0.1bind 改为 0.0.0.0放行宝塔安全页、系统防火墙、云安全组boto3 连接报 SignatureDoesNotMatch客户端时间与服务端不一致签名版本不匹配同步时间显式指定 signature_versions3v4SDK 提示 Unable to connectendpoint_url 缺失或写错端口不对检查 endpoint_url 是否包含端口确认 Rustfs 监听端口创建桶报 BucketAlreadyExists桶已存在但客户端不知道忽略该异常或先调用 head_bucket 判断PHP 上传成功但网页访问 404对象 Key 路径和预期不一致查看 SDK 生成的 Key确认是相对路径而非绝对路径宝塔备份 pgsql 失败pg_dump 未安装或版本不匹配安装匹配的 postgresql-client重启后 Rustfs 服务没起来没有配置 systemd 或 Supervisor进程守护配置错误使用 systemd 的 Restartalways 配置上传大文件时连接断开超时时间太短带宽受限调大 read_timeout或分片上传跨内网访问很慢默认走了公网流量确认 endpoint_url 是否填了内网地址7. 断点续传和分片上传Rustfs 也要会处理7.1 什么时候需要分片上传如果只是传一些小备份文件put_object就够了。但当你需要把数据库的完整备份、整站打包文件甚至几个 GB 的日志归档传到 Rustfs 时直接用put_object很容易出问题一方面网络不稳定会中途失败另一方面服务端对单次请求大小可能有限制。S3 协议里解决这个问题的方式是多部分上传Multipart Upload。把一个大文件拆成多个分片依次上传最后组装成一个对象。好处有三个单个分片失败只需要重传这个分片不用整个文件从头再来可以并发上传多个分片充分利用带宽可以随时查看上传进度。boto3 的upload_file方法会自动处理分片逻辑通常不需要手动实现每个步骤你只需要调用一次s3.upload_file( /path/to/large-backup.tar.gz, my-backup-bucket, backup/large-backup.tar.gz )upload_file底层会在文件大小超过阈值时自动切换为多部分上传并且可以通过Config参数调整分片大小from boto3.s3.transfer import TransferConfig config TransferConfig( multipart_threshold8 * 1024 * 1024, # 超过8MB触发分片 multipart_chunksize8 * 1024 * 1024, # 每个分片8MB max_concurrency4, # 并发数 ) s3.upload_file( /path/to/large-backup.tar.gz, my-backup-bucket, backup/large-backup.tar.gz, Configconfig )PHP SDK 也有对应的MultipartUploader如果文件超过 100MB建议直接上 MultipartUploader 而不是putObject能在很大程度上避免大文件上传超时问题。7.2 分片上传过程中的常见坑分片上传虽然方便但有两个坑值得单独说第一个是分片未完成会占用服务端存储。如果你启动了一个多部分上传但是中途放弃了已上传的分片会一直挂在服务端很多服务商会保留一段时间或者直到你调用abort_multipart_upload。你每次用list_multipart_uploads可以看到这些未完成的上传记录。清理方法# 列出所有未完成的多部分上传 uploads s3.list_multipart_uploads(Bucketmy-backup-bucket) if Uploads in uploads: for upload in uploads[Uploads]: s3.abort_multipart_upload( Bucketmy-backup-bucket, Keyupload[Key], UploadIdupload[UploadId] )第二个是分片上传完成后服务端返回的 ETag 不是简单的 MD5而是一个带分片数量的后缀。如果你依赖 ETag 做完整性校验直接用这个值会踩坑。更可靠的做法是在上传完成后从 Rustfs 下载对象并计算 MD5 或 SHA256 进行比对。7.3 备份到远端后怎么验证完整性文件传上去不等于备份成功了至少要做一次可恢复性验证。我的习惯是每次上传完成后在脚本里调用head_object获取对象大小和本地文件大小比对如果一致基本可以确认传输正常。如果对安全性要求更高再下载回来算一下哈希。在脚本里做校验的示例# 获取远端对象信息 meta s3.head_object(Bucketmy-backup-bucket, Keyobject_key) remote_size meta[ContentLength] # 对比本地文件大小 local_size os.path.getsize(local_path) if remote_size ! local_size: raise Exception(f大小不一致: local{local_size}, remote{remote_size}) else: print(f校验通过: {local_size} bytes)这种做法不能检测文件内容被篡改但足以发现传输过程中的数据损坏。对大多数备份场景来说够了。8. 写到最后的一些体会折腾完这一整套我最大的感受是Rustfs 本身其实很稳真正容易出问题的地方几乎都在“S3 协议兼容性”和“宝塔环境自身限制”这两个层面。S3 客户端各有各的默认行为有的默认虚拟主机风格访问有的默认虚拟签名版本不对这些默认值在连 AWS 时都恰到好处一连自建服务就全开始捣乱。所以最关键的还是要掌握排查思路看到签名报错往时间、密钥、签名版本三个方向查看到连接不上往监听地址、防火墙、安全组三个方向查大方向对了问题都能快速收敛。对我个人来说最实用的一个经验是不要一开始就引入复杂的自动化体系先把“手动上传一个文件到 Rustfs”这个最小闭环打通再逐步加上备份脚本、计划任务、进程守护、分片上传。每一步都验证通过再走下一步这样即使出问题也知道该去哪个环节排查。如果后面还有机会我会进一步整理 Rustfs 在 Docker 环境下的部署方式以及如何把它和飞牛 NAS 这类家庭存储设备配合使用。到时候再出一篇续篇。