场景：作为一家成长型电商平台的数据库管理员，你需要每天备份一个500GB的MySQL数据库和一个200GB的PostgreSQL数据库。备份窗口限制为4小时，但当前备份耗时超过6小时，恢复时间超过12小时，导致SLA面临风险。
症状：备份时间>6小时；恢复时间>12小时；高I/O等待（wa>30）；备份期间复制延迟飙升；磁盘利用率在备份时达到100%；由于压缩导致CPU空闲率低。
诊断：使用iostat检查磁盘吞吐量（例如：$ iostat -x 1），查看是否出现高avgqu-sz和await。对于MySQL，运行SHOW ENGINE INNODB STATUS并检查日志序列号年龄；对于PostgreSQL，使用pg_stat_progress_vacuum和pg_stat_activity。确定备份是I/O密集型（顺序读取）、CPU密集型（压缩）还是网络密集型（远程备份）。例如：单线程的mysqldump很慢；pg_dump默认是单线程。
命令：对于MySQL，使用Percona XtraBackup并行备份：xtrabackup --backup --parallel=4 --compress --compress-threads=4 --target-dir=/backup。为了更快恢复，使用--decompress和--parallel。对于逻辑备份，使用mysqldump的--single-transaction（无锁）并分割表：for i in $(mysql -e 'show tables' -N db); do mysqldump db $i & done; wait。对于PostgreSQL，使用pg_dump的目录格式和并行作业：pg_dump -Fd -j 4 -f /backup/db。对于物理备份，使用pg_basebackup多WAL工作者：pg_basebackup -D /backup -X stream --progress。或者使用pgBackRest并行归档和恢复：pgbackrest --stanza=db --type=full backup; pgbackrest --stanza=db --type=full restore。调整压缩：用pigz（并行gzip）替换gzip，或使用--compress-level=1加快速度但降低压缩比。
风险控制：始终先在测试环境测试备份和恢复。避免在高峰期运行备份。使用单独的存储（如NFS、S3）备份，以减少主磁盘负载。确保保留事务日志用于PITR。使用mylvmbackup或自定义脚本监控备份进度。对于MySQL，使用--lock-ddl-per-table允许备份期间DDL。对于PostgreSQL，通过持续归档WAL确保可恢复性。
回滚：如果备份失败，确保上一次成功的备份可用并已验证。设置自动警报通知故障。如果恢复时发生损坏，准备好旧备份。使用增量备份减少完整备份频率。如果恢复失败，停止并检查日志，然后从另一个有效备份恢复。
验证：备份后验证完整性：对于MySQL，使用xtrabackup --verify-backup；对于PostgreSQL，使用pg_verifybackup（针对备份清单）。定期在独立实例上恢复测试并测量时间。检查恢复数据一致性（例如，计数行、校验表和表）。对于逻辑备份，恢复到测试数据库并运行示例查询。
何时提交OpsGlobal工单：如果备份或恢复时间持续超过SLA的50%且调优无效，如果遇到损坏错误，如果需要跨区域设置灾难恢复解决方案，或者需要带有监控仪表板的自定义备份脚本。OpsGlobal SRE可以审计您的配置，实现并行备份策略，并自动化备份验证。
适用场景
适合正在处理 Database、MySQL, PostgreSQL, 备份, 恢复 相关问题的团队，用于快速建立排查路径和交付标准。
问题背景
学习优化MySQL和PostgreSQL数据库备份和恢复的实用技术，减少停机时间并满足SLA。
排查步骤
先确认影响范围和最近变更，再收集日志、配置、指标和链路数据，最后按风险从低到高执行修复。
命令示例
示例命令请替换为你的真实资源名，并使用环境变量保存账号、密码、token 等敏感信息。
风险说明
生产环境操作前需要确认备份、权限边界、变更窗口和回滚路径，避免扩大故障影响。
回滚方案
保留原配置和发布版本；如修复后指标异常，立即回退配置、镜像或数据库变更并复核日志。
交付清单
问题定位记录、关键命令、修复步骤、验证结果、后续优化建议。
遇到类似技术问题？
如果你的服务器、K8s、Docker、CI/CD、数据库或监控系统出现类似问题，可以提交日志和配置文件，我们帮你远程诊断。