误带-v flag备份Docker Postgres，如何恢复数据？

问题根源 #

你遇到的备份损坏和恢复错误，不是-v参数的问题，而是docker exec加了-t参数导致的：

• -t会给容器分配伪终端，终端模式下会自动将换行符\n（0A）转换为\r\n（0D0A），而-F c生成的是二进制备份文件，这种转换会插入多余的0D（回车符），直接破坏备份的归档结构，导致恢复时出现"unexpected EOF"或"file is not an archive"错误。
• 至于-v参数，它只是将pg_dump的日志输出到stderr，不会混入stdout的备份数据，你的备份文件里出现的"pg_dump: reading table..."日志，应该是误把stderr也重定向到了备份文件（比如用&>而不是>），但核心问题还是-t导致的二进制文件损坏。

修复现有备份文件 #

针对已经生成的带多余0D字符的备份，用以下命令批量清理：

Linux/macOS #

sed -i 's/\r//g' /path/to/your/db.bak

Windows（PowerShell） #

(Get-Content -Raw "C:\path\to\your\db.bak") -replace "`r", "" | Set-Content -Raw "C:\path\to\your\db.bak"

清理后可以用pg_restore --list db.bak验证备份是否有效，能列出表结构说明归档已修复。

解决恢复时的"out of memory"错误 #

修复归档后架构能恢复但数据导入内存不足，试试这些方法：

1. 并行恢复：用--jobs参数指定并行任务数（建议设为CPU核心数），分散内存压力：

   pg_restore -d your_database --jobs=4 /path/to/db.bak
   

2. 跳过非必要操作：加上--no-acl --no-owner跳过权限和所有者设置，减少处理开销：

   pg_restore -d your_database --no-acl --no-owner /path/to/db.bak
   

3. 临时调大PostgreSQL内存参数：
   进入PostgreSQL命令行执行：

   ALTER SYSTEM SET work_mem = '64MB'; -- 根据服务器内存调整，比如128MB
   SELECT pg_reload_conf();
   

   恢复完成后记得改回原配置，避免影响日常性能。
4. 分表恢复：如果单表数据量过大，逐个恢复表：

   pg_restore -d your_database -t table_name /path/to/db.bak
   

   可以先用pg_restore --list db.bak列出所有表，按顺序恢复。

正确的备份脚本写法（避免重复踩坑） #

修改备份命令，去掉-t参数，同时将日志单独输出：

# 带日志的备份命令
docker exec crm-database-1 pg_dump --dbname=postgresql://postgres:**************@localhost:5432/********** -F c -b -Z 9 -E UTF8 -v > $path/db.bak 2> $path/pg_dump.log

# 不带日志的简化命令
docker exec crm-database-1 pg_dump --dbname=postgresql://postgres:**************@localhost:5432/********** -F c -b -Z 9 -E UTF8 > $path/db.bak

备份完成后，一定要用pg_restore --list $path/db.bak验证备份有效性，同时定期测试恢复流程，避免紧急时刻掉链子。

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