Heroku Postgres 使用AWS S3预签名URL恢复数据失败

Windows执行命令报错的原因 #

• Windows cmd/PowerShell 原生将&识别为多命令拼接分隔符，未对URL加引号包裹时，Shell会把URL中&后续的X-Amz-*参数拆分为独立命令执行，直接触发语法报错。

Heroku恢复任务返回400 Bad Request的原因 #

• 签名版本兼容性不匹配：AWS CLI默认生成的预签名URL采用AWS4-HMAC-SHA256（V4）签名，该签名会绑定发起请求的客户端请求头特征；而Heroku的备份拉取服务未适配V4签名的头校验规则，从S3请求资源时直接触发签名校验失败返回400。你观察到的和旧式AWSAccessKeyId参数格式的差异，本质就是V4和V2签名的格式区别。
• URL有效期不足：你生成预签名URL时若采用默认1小时有效期，Heroku的恢复任务存在排队调度延迟，实际发起S3请求时URL已过期，也会返回400错误。
• 无效配置不产生正向作用：你在Heroku应用环境中配置的AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY不会被备份恢复流程调用——恢复流程仅读取你传入的公开/预签名URL拉取文件，不会使用应用环境的凭证请求S3，这部分操作对解决问题无帮助。
• 误判提示：Heroku日志中“检查源URL公开访问权限”是兜底通用报错文案，实际触发400的核心原因不是公开权限不足，而是签名校验不通过、URL过期这类请求格式问题，和你是否开启S3公共访问无直接关联。

• 解决Shell传参拆分问题：执行恢复命令时，必须将完整URL用半角双引号包裹，确保Shell将其识别为单个参数。参考命令格式：

  heroku pg:backups:restore "你的完整预签名URL" HEROKU_POSTGRESQL_实际数据库连接名 --app 你的Heroku应用名
  

• 生成兼容Heroku的预签名URL：调整AWS CLI生成规则，强制使用V2签名格式，同时延长有效期覆盖全流程调度时间：

  aws s3 presign s3://你的存储桶路径/备份文件.dump --signature-version v2 --expires-in 86400
  

  该命令生成的URL会包含传统的AWSAccessKeyId参数，完全匹配Heroku拉取服务的兼容逻辑，且24小时有效期足够覆盖排队、拉取、恢复全流程，避免过期报错。
• 6GB大文件的更优稳定方案（推荐优先采用）：
  跳过S3中转环节，通过本地管道直接将本地PostgreSQL数据导入Heroku Postgres，从根源上避免URL权限、签名、解析的问题：

  pg_dump -Fc --no-acl --no-owner -h 本地数据库地址 -U 本地数据库账号 本地数据库名 | heroku pg:psql --app 你的Heroku应用名 HEROKU_POSTGRESQL_实际数据库连接名
  

  该方式会将本地导出的备份流直接通过CLI管道传给Heroku的Postgres进程，无需上传第三方存储，6GB规模只要网络稳定即可一次完成迁移。
• 迁移后校验：
  执行查询命令对比本地与Heroku库的业务表数据量，确认数据完整即可。由于本地导出的dump文件已包含完整表结构和预置业务数据，无需单独再执行db.create_all()生成空表。

内容的提问来源于stack exchange，提问作者Paul Wilson