备份脚本挂了定时监控面板天天绿着。备份目录里每天躺一个新文件，看着挺让人安心。

可真要用它的那天——误删了一张表、或者机器坏了得换一台恢复——不少人才头一次发现：这备份还原不回来。文件是空的、少了几个对象、版本对不上，各种情况都有。

备份「跑成功了」和备份「真能用」，中间隔着一次几乎没人主动做的事：把它还原出来看看。老实说，这篇就干这一件事，把一个 custom 备份还原到临时库。再一项一项验过去——数据对不对、对象全不全、约束还在不在、业务查询跑不跑得通。第 篇讲过的 sys_dump 、sys_restore 参数这里不重复，主要是一套验证的思路。

先给源库留一组基线

备份之前，先在源库查一组数据记下来。注意不是查「表在不在」，而是查几个业务上能说明问题的值：

ksql -h . -p -U system -d backup_src_db -c "select count as order_count。sum as amount_sum,max as last_created_at from t_bak_order;"
ksql -h . -p -U system -d backup_src_db -c "select * from v_bak_customer_amount order by customer_id;"

订单表行数、金额合计、最终一单是 <日期>；视图按客户汇总，张三 单 、李四 单 、王五 单。

为什么不直接 select count 完事？因为行数对得上，不代表数据没错位。少灌了一行金额、某个字段乱了序，单看行数发现不了。金额合计、最终一条时间这种指标，掺进了具体的值，恢复后拿来对账才靠得住。老实说，这组数就是后面验证的「标准答案」。

备份，接下来先别急着还原

备份成 custom 格式。 文件放进一个带日期的目录：

BACKUP_DIR=/acowbo/kingbase/backups/verify_20260630
mkdir -p "$BACKUP_DIR"
sys_dump -h . -p -U system -d backup_src_db -F c -f "$BACKUP_DIR/backup_src_db.dump"
ls -lh "$BACKUP_DIR/backup_src_db.dump"
sys_restore -l "$BACKUP_DIR/backup_src_db.dump" | sed -n ',80p'

文件 .7K，躺在那儿了。其实，但文件存在只是第一层——里面装的东西齐不齐。得用 sys_restore -l 看一眼归档目录再说。

输出头部写着这份归档的身份：dbname: backup_src_db 、TOC Entries: ... 等等。下面 Selected TOC Entries 列出了里面有什么：schema 。两张表 ,,序列,视图 ,表数据,各种约束,索引,外键等。该有的对象都在清单里，

This step’s significance is that you can confirm backup isn’t an empty shell before actually restoring.

还原到临时库。别碰源库

关键点：不要把恢复命令直接指向生产数据库，以免误操作导致不可逆的数据丢失。

ksql -h . -p -U system -d app_db -c "drop database if exists backup_verify_db;"
ksql -h . -p U system d app_db c "create database backup_verify_db;"
sys_restore h . p U system d backup_verify_db v "$BACKUP_DIR/backup_src_db.dump"

The `-v` flag makes `sys_restore` print every step: connect,create schema `wmsys`,create tables and sequences,create view,load data—showing row counts that match source. It proves command succeeded but not that data matches.

数据对不对，两边拉出来比

The easiest way is to run identical aggregation queries against both databases and compare results side‑by‑side.

ksql ... "-c \"select 'backup_src_db' as db_name,count as order_count,sum as amount_sum,max as last_created_at
from t_bak_order\""
ksql ... "-c \"select 'backup_verify_db' as db_name。count ...
from t_bak_order\""
Both sides should return exactly same numbers . If y do not match n something went wrong even if restore reported success.

对象、约束、索引，一个都不能少

A full restore must bring back every object that existed in production:

• Tables & Views:
• \dt shows tables exist.
• \dv lists views – ignore KES internal stats views.
• \dv shows your custom view exists.
• You must explicitly query definitions to ensure y were restored:
sql SELECT c.conname,c.contype,_get_constraintdef AS constraint_def FROM _constraint c WHERE c.conrelid = 'public.t_bak_order'::regclass ORDER BY c.conname;SELECT indexname,indexdef FROM _indexes WHERE schemaname = 'public' AND tablename = 't_bak_order' ORDER BY indexname;Check that all foreign keys,unique constraints,check constraints and indexes are present. Skipping this step could allow dirty data into production later because constraints may have been lost during restore.

跑业务查询。再故意撞一次约束

Your restore is “complete” only when business logic works correctly:

• Select from your view again – results must match source baseline.
sql SELECT * FROM v_bak_customer_amount ORDER BY customer_id;怎么说呢，
• Dangerously try inserting a record that violates a foreign key to verify enforcement:
sql INSERT INTO t_bak_order VALUES;You should receive an error such as: sql ERROR的观点是，insert or update on table "t_bak_order" violates foreign key constraint "t_bak_order_customer_id_fkey" 说到DETAIL。Key = is not present in table "t_bak_customer". If no error occurs n eir constraint was missing or disabled – both unacceptable risks for production recovery.

备份文件本身也得能追溯

• The file size gives an immediate sanity check – any sudden drop indicates corruption during export or transfer.
bash ls "-lh $BACKUP_DIR/backup_src_db.dump" sha256sum "$BACKUP_DIR/backup_src_db.dump" The SHA‑256 hash lets you verify that exact byte stream you saved remains unchanged after transport or archiving. However remember it only proves file integrity—not wher file restores correctly. Combine it with all previous checks for true confidence.

这套流程到底验出了什么？

• The baseline confirms what “good” looks like before any disaster hits.
• `sys_restore –l` guarantees archive isn’t just an empty shell.
• The temporary database preserves source integrity while allowing full inspection of objects and data.
• Synchronized aggregate metrics confirm row counts and sums match exactly.
• An explicit query of constraints & indexes ensures structural fidelity beyond surface level.
• A deliberate constraint violation test confirms runtime enforcement works after restore—something many automated scripts miss.
• The file size & SHA‑256 hash provide a non‑invasive audit trail of physical integrity over time.

If your backup passes every single one of se steps n you can say confidently “this backup will work.” Merely having a successful export command is not enough—you must validate every layer until business logic runs flawlessly against a copy of your live environment. Only n does routine scheduled backing up become more than a green‑light checkbox—it becomes a reliable safety net for true disaster recovery.