【openGauss】物理备份恢复实战：从gs_backup到gs_probackup的完整操作指南

1. 物理备份基础概念与工具选型第一次接触openGauss物理备份时我被各种工具搞得晕头转向。经过半年实战终于理清了这三个核心工具的使用场景。物理备份就像给数据库拍X光片直接复制数据文件、日志文件这些器官比逻辑备份这种口头描述病情要直观得多。三种工具的定位差异特别重要gs_backup相当于急救包专门备份配置文件($PGDATA/postgresql.conf)和二进制文件。有次我们机房断电导致pg_hba.conf损坏就是用它在3分钟内恢复了认证配置。gs_basebackup是基础CT扫描做全量数据目录拷贝。上周我们误删了测试库用它20GB的备份文件15分钟就完成了恢复。gs_probackup则是高级核磁共振支持增量备份和自动管理。生产环境每月节省了60%存储空间就是靠它的增量合并功能。实际选择时有个简单原则日常维护用gs_probackup紧急故障用gs_basebackup配置文件丢失用gs_backup。最近给某银行做迁移就是先用gs_probackup做全量再用它的增量功能每天同步最后切换时差异不到5分钟。2. gs_backup实战配置文件保卫战2.1 备份操作详解第一次使用gs_backup时我犯了个典型错误没指定-h参数导致备份了所有节点。其实大多数时候我们只需要备份当前节点用这个命令就够了gs_backup -t backup --backup-dir/opt/backup --parameter -h hostname关键参数解析--binary会备份$GAUSSHOME/bin下的工具文件比如gsql、gs_ctl这些--all相当于同时执行--parameter和--binary但会生成两个独立压缩包有次升级前我特意用以下命令做了完整备份gs_backup -t backup --backup-dir/opt/full_backup \ --all -h node1解压后看到这样的结构full_backup/ ├── binary_node1.tar ├── parameter_node1.tar └── backup.log2.2 恢复时的避坑指南恢复操作看似简单但有几个暗坑权限问题必须用omm用户执行有次我用root操作导致文件属主错误目录冲突如果目标文件已存在需要加--force参数版本匹配备份的二进制文件必须与数据库版本严格一致上周处理的一个案例特别典型客户修改了pg_hba.conf后无法连接。我们用备份快速还原gs_backup -t restore --backup-dir/opt/backup \ --parameter -h db01整个过程只用了47秒比手动修改效率高得多。3. gs_basebackup全量备份利器3.1 备份中的表空间陷阱第一次用gs_basebackup时我遇到了这个报错pg_basebackup: error: directory /data/tbs1 exists but is not empty原因是有个表空间指向了绝对路径/data/tbs1。解决方案是用-T参数重定向gs_basebackup -D /backup/db_full \ -T /data/tbs1/backup/db_full/tbs1 \ -p 15400实用技巧备份前用\db查看所有表空间路径每个-T只能映射一个表空间多个表空间需要写多个-T目标路径必须为空且可写3.2 恢复实战案例上个月我们遇到磁盘损坏数据目录完全丢失。恢复步骤如下停库重要gs_om -t stop确认原数据目录位置gs_om -t status --detail | grep data复制备份注意保持目录名一致cp -rp /backup/db_full /opt/opengauss/data/dn处理表空间如有mkdir -p /data/tbs1 chown omm:dbgrp /data/tbs1启动验证gs_om -t start gsql -c SELECT count(*) FROM pg_tablespace整个过程耗时约18分钟数据零丢失。关键点在于保持目录结构和权限一致。4. gs_probackup增量备份大师课4.1 初始化配置详解搭建增量备份环境时最容易漏掉的是这个参数-- 检查cbm跟踪是否开启 SELECT name,setting FROM pg_settings WHERE nameenable_cbm_tracking;如果返回off需要立即修改gs_guc reload -N all -I all \ -c enable_cbm_trackingon初始化步骤示例# 初始化备份仓库 gs_probackup init -B /backup/probackup # 添加实例注意-D是数据目录 gs_probackup add-instance \ --instance prod_db \ -B /backup/probackup \ -D /opt/opengauss/data/dn # 设置连接参数 gs_probackup set-config \ --instanceprod_db \ -B /backup/probackup \ -d postgres -p 154004.2 备份策略实战我们生产环境采用这个备份方案每周日全量备份每天增量备份每月合并一次具体命令# 全量备份 gs_probackup backup --instance prod_db \ -B /backup/probackup -b full \ -E /data/tbs1/backup/probackup/tbs1 # 增量备份 gs_probackup backup --instance prod_db \ -B /backup/probackup -b ptrack # 查看备份链 gs_probackup show -B /backup/probackup输出示例BACKUP INSTANCE prod_db Instance Version ID Recovery Time Mode WAL Mode prod_db 3.0.0 B1V2Q 2023-08-20 00:00:0008 FULL STREAM prod_db 3.0.0 B1V3Q 2023-08-21 00:00:0008 DELTA PTRAK4.3 高级恢复技巧遇到需要PITR(时间点恢复)的情况可以这样操作gs_probackup restore --instance prod_db \ -B /backup/probackup \ -D /opt/opengauss/data/dn_restore \ --time2023-08-20 15:30:00 \ -T /data/tbs1/restore/tbs1 \ --external-mapping/data/tbs1/restore/tbs1关键参数--time指定要恢复到的时间点--timeline用于复杂恢复场景--recovery-target-action控制恢复后行为有次开发误删了重要表我们就是用时间点恢复在6分钟内找回了数据比从逻辑备份恢复快了两个数量级。