跳到主要内容

BitaHub断点续传功能

更新时间：2026-10-15 03:20:56

在使用 BitaHub 命令行工具（CLI / 快传工具）进行大型数据集、模型权重或工程代码的传输时，网络抖动或人为中断是常见现象。为了帮助用户更高效地管理文件传输，本文详细介绍命令行工具在上传与下载两种场景下的断点续传处理机制及操作注意事项。

一、传输行为对照与特性概览​

传输方向是否支持断点续传有效保留时间续传触发方式中断后文件处理机制
文件上传 (Upload)已支持1 天内 (24 小时)执行完全相同的上传命令自动接续已上传分块，无需从头重传
文件下载 (Download)不支持不适用重新执行下载命令重新全量下载，需手动清理旧临时文件

二、上传中断与断点续传机制​

1. 续传规则与有效期​

当使用命令行工具向 BitaHub 文件存储、数据集或代码空间上传文件时，底层采用分块传输机制：

  • 一天内有效：如果上传过程中断（如终端关闭、网络超时或主动终止任务），服务端会为已上传的数据分块保留 1 天（24 小时）。
  • 自动续传：在中断发生后的 24 小时内，只要在终端重新执行与之前完全一致的上传命令，工具会自动校验服务端分块索引，直接从之前已上传的内容位置继续上传，而不会从头重新开始。
  • 超时失效：若中断超过 24 小时未重新触发，服务端暂存的未完成分块将被自动清理，此时再次执行命令将触发全新的全量上传。

2. 操作示例​

以从控制台复制的上传命令为例：

执行上传命令
bita upload -e https://www.bitahub.com -b b20261015031704741kbnjhd -o dataset/train -l ./noisy-breeze.yaml

若在上传传输过程中因网络波动或中断退出，只要在 24 小时（1 天）内，在终端重新执行完全相同的命令：

一天内重新执行相同上传命令触发断点续传
bita upload -e https://www.bitahub.com -b b20261015031704741kbnjhd -o dataset/train -l ./noisy-breeze.yaml

服务端会自动校验已接收的数据分块索引，直接从之前已上传的分块进度继续接续上传，而不会从头重新上传。

三、下载中断机制与临时文件清理​

1. 下载中断处理规则与命令示例​

当使用命令行工具从平台下载文件至本地时，例如执行以下下载命令：

执行下载命令
bita download -e https://www.bitahub.com -b b20261015031704741kbnjhd -o noisy-breeze.yaml -l ./
  • 全量重传机制：下载操作目前暂不支持断点续传。若下载过程中断，再次执行上述相同命令时，工具将从头重新开始下载整个文件。
  • 临时文件占用：下载过程中未完成的残留数据会以临时文件形式保留在本地目标路径中，重新下载不会自动覆盖或合并已损毁的片段，可能导致本地磁盘空间被额外占用。

2. 手动清理未完成临时文件​

为避免磁盘空间浪费或文件名冲突，在重新发起下载前，必须手动清除之前中断产生的未完成临时文件：

在终端进入下载目标目录，检查并删除未完成的临时文件或半截文件：

清理未完成下载文件
# 查看当前目录下残留的不完整文件
ls -lh ./noisy-breeze.yaml*

# 手动删除未完成文件或临时文件
rm -f ./noisy-breeze.yaml

清理完成后，再次执行下载命令即可正常完整拉取文件。

四、注意事项与最佳建议​

最佳实践建议
  1. 网络不稳定环境下的大文件上传：若上传超大文件（如大于 50GB），建议保持上传命令参数一致，中断后尽早在 24 小时内重新发起，避免分块过期失效。
  2. 下载前确认本地磁盘配额：下载前请通过 df -h（Linux）或查看磁盘属性（Windows）确认本地目标分区有足够的空闲空间，防止因空间不足导致中途写盘中断。
  3. 关联文档：更多命令行工具的安装与登录排障指引，请参考 命令行工具使用常见问题FAQ。
此页面对您有帮助吗？
最后于 更新