一、打通网络（核心前提）
FC 部署在阿里云 VPC 内，而公司备份服务器位于内网机房 ，需要通过VPC 与公司内网的连接方案实现互通，以下三种方案均可行：
方案 A：专线接入（推荐）
通过物理/虚拟专线将本地数据中心与阿里云 VPC 连接起来，在两端距离很远的情况下仍能提供低延迟、低丢包率、高带宽的内网级通信质量 。适合长期使用、数据量大、对稳定性要求高的场景。
方案 B：VPN 网关
使用 IPsec-VPN 将本地数据中心网络（或公司办公网）与阿里云 VPC 连接，办公网内部 PC 无需修改任何配置即可直接与云上 VPC 中的云资源通信。适合预算有限、数据量适中的场景。
方案 C：反向代理 + 内网穿透引擎（临时/快速方案）
在备份服务器上部署 FRP、Ngrok、rathole等内网穿透工具主动发起出站连接，FC 直连代理服务反代回备份服务器，适合临时测试或低频传输场景。
如果内网备份服务器本身没有公网 IP，且 IT 部门不愿在出口做端口映射，这是唯一的快速验证方案。生产环境长期使用仍建议走专线或 VPN。
行动建议：与运维/网络部门确认 公司是否已与阿里云建立专线或 VPN，若已打通，FC 可直接用内网 IP 访问备份服务器；若未打通，从VPN 网关起步快速验证，后续再评估是否升级专线。
二、备份文件传输的三种优先级方案
网络打通后，备份传输在代码层实现，以下是三种由低到高的实现方案。
方案一（最低成本，仅 1～2 行代码改动）：在下载函数中完成备份
定位 ：在 FC 的下载函数中，CSV 成功写入 OSS 后，立即从 OSS 读回并用 SFTP/SCP 推送到公司内网服务器。
python
# download_module.py def run_download(item_id, context): # 1. 从 ASP 下载 CSV，写入 OSS（原有逻辑） csv_content = fetch_csv_from_asp(item_id) upload_to_oss(bucket, item_id, csv_content) # 2. 备份：从 OSS 读回 -> 推送到本地备份服务器 csv_content = download_from_oss(bucket, item_id) # 复用已有方法 push_to_backup_server(csv_content, item_id, context)
其中 push_to_backup_server 使用 Python 标准库 paramiko 实现 SFTP：
python
import paramiko def push_to_backup_server(csv_content, item_id, context): backup_host = os.environ['BACKUP_SERVER_IP'] # FC 环境变量管理 backup_path = f"/backup/csv/{item_id}.csv" transport = paramiko.Transport((backup_host, 22)) transport.connect(username=os.environ['BACKUP_USER'], password=os.environ['BACKUP_PASS']) sftp = paramiko.SFTPClient.from_transport(transport) with sftp.open(backup_path, 'w') as f: f.write(csv_content.encode('utf-8')) sftp.close() transport.close()
OSS 到备份服务器的读流量会产生外网下行费用，建议评估每日 CSV 总大小。
方案二（解耦更优）：用 OSS 触发器实现自动备份函数
在 OSS 控制台为目标 Bucket 的 PutObject 事件创建触发器，绑定一个专门负责备份的 FC 函数。下载函数将 CSV 写入 OSS 后，触发器自动调用备份函数，该函数从 OSS 读 CSV 并推送至公司备份服务器。
yaml
# s.yaml 中为 upload-func 新增 OSS 触发器 - ossTrigger: name: backup-on-upload type: oss properties: bucketName: your-bucket-name events: - oss:ObjectCreated:PutObject filter: Key: Prefix: csv_data/
备份函数核心实现：
python
def backup_handler(event, context): # OSS 触发器自动传入 JSON 格式事件 for record in event['events']: bucket_name = record['oss']['bucket']['name'] object_key = record['oss']['object']['key'] # 从 OSS 下载 CSV 内容 csv_content = download_from_oss_by_key(bucket_name, object_key) # 推送到公司备份服务器 push_to_backup_server(csv_content, object_key, context)
对比：
| 维度 | 方案一（下载函数直接备份） | 方案二（OSS 触发器备份） |
|---|---|---|
| 代码耦合度 | 高（备份逻辑侵入下载函数） | 低（备份逻辑完全独立） |
| 备份失败影响 | 阻塞下载流程（需自行处理异常） | 仅影响备份本身，下载不受影响 |
| 对原代码的侵入 | 需修改下载函数的源码 | 只需在 s.yaml 中增加触发器配置 |
| 可独立重试 | 难（需重新下载整个 CSV） | 可独立重试备份任务 |
| 适用场景 | 简单、备份成功率极高 | 生产环境、对可靠性有要求 |
方案三（企业级方案，但成本最高）：OSS 数据迁移隧道
通过阿里云的数据迁移服务，在本地数据中心部署迁移代理（Agent），直接与 OSS 建立加密隧道。支持断点续传，适合长期自动同步 或超大文件/海量 CSV 的场景。配置复杂度较高，需在公司备份服务器上部署 Agent，建议作为长期演进的目标方案。
三、备份策略增补
3.1 OSS Bucket 复制（云上自动备份层）
在 OSS 控制台为源 Bucket 配置跨区域复制（CRR） 或同区域复制（SRR） ，CSV 写入源 Bucket 后自动异步复制 到目标 Bucket（可位于不同地域）。作为云上备份层 ，即使内网备份服务器宕机或网络中断，CSV 数据仍受 OSS 的 99.9999999% 持久性保护。建议作为最强兜底备份策略叠加使用。
3.2 备份保留策略
-
备份服务器侧：用 crontab 或脚本定期清理 30 天之前的旧 CSV。
-
OSS 侧 ：配置生命周期规则 ，将
csv_data/前缀下的对象在 30 天后自动删除或转归档存储，控制存储成本。
四、三个方案的最终汇总对比
| 方案 | 备份触发方式 | 对原项目的影响 | 网络依赖 | 推荐场景 |
|---|---|---|---|---|
| 方案一：下载函数一并推送 | 下载函数内主动推送 | 低（增加几行代码） | FC 能访问内网备份服务器即可 | 初期快速验证 |
| 方案二：OSS 触发器备份 | 自动触发备份函数 | 极低（只需添加触发器） | 同上 | 生产环境主选 |
| 方案三：数据迁移隧道 | 自动同步 | 零（完全独立） | 需在内网部署 Agent | 企业级长期方案 |
| 备份策略 OSS Bucket 复制 | 异步自动复制 | 零（仅 OSS 配置） | 无（纯云上操作） | 强力兜底备份 |
生产环境推荐组合：
网络已打通 → 采用 方案二（OSS 触发器备份） ，并在 OSS 控制台额外开启 Bucket 跨区域复制 作为兜底备份层。备份失败时可按需重试备份函数，不影响主流程稳定性。