备份 · XB 现场笔记

pg_dump 拍一张一致的快照

Fri, 14 Jan 2028 00:00:00 +0000

pg_dump 使用事务数据的一致视图导出一个 PostgreSQL 数据库，同时允许其他会话继续提交变化。它避免了普通逐表复制的问题：前一张表和后一张表不会因为读取时间不同，就混入彼此不一致的已提交状态。但快照只是备份契约的一部分；归档还必须覆盖需要的数据范围，能被兼容工具读取，并且实际恢复成可使用的数据库。

理解快照覆盖什么

导出期间，快照可见的行构成稳定视图。后续提交不会因为某张表读得晚，就逐渐混进同一次导出。并行导出让各 worker 使用同步快照，而不是各自随时读取。并行 dump 要求 directory 格式；custom 格式支持并行恢复，但不支持并行导出。格式选择应根据导出与恢复两边的需求分别判断，不能把两个方向混为一谈。

数据库快照不会自动让整个业务流程原子化。如果应用分两个事务提交批次头和明细，一致快照完全可能合法地落在这两次提交之间。序列状态也不是普通的 MVCC 行数据，外部文件和其他服务更不在数据库快照范围内。恢复需要满足什么业务不变量，必须结合真实事务边界和所需数据源定义，不能只凭“同一快照”推断所有业务状态都完整。

计算负载和依赖

普通读取和写入通常可以在导出期间继续，但 pg_dump 仍获取 ACCESS SHARE 锁，也消耗 CPU、I/O、连接和快照存活时间。冲突的 DDL 可能等待，也可能使导出失败；长快照会阻止某些旧行版本被清理。增加并行 worker 只是用更多并发资源换时间，不会让备份开销消失。应记录事务年龄和线上负载，避免把备份的影响误认为无关故障。

使用备库可以分担读取，但要考虑恢复冲突与复制延迟，而且从备库导出会排除非日志表内容。一次 pg_dump 也不包含集群级角色和表空间。扩展、所有者、权限、排序规则行为及目标配置，都需要通过合适机制纳入恢复计划。把整个库拆成互不协调的单表 dump，可能丢失共同快照，也可能遗漏这些表依赖的对象，不能当成免费的优化。

坏掉的样子

归档目录能够列出，不代表恢复一定成功。目标缺少角色或扩展时，表数据可能只恢复了一部分。应把归档加载到隔离空库，明确处理错误，再验证业务不变量和代表性查询。pg_restore 默认遇到 SQL 错误仍会继续，最后汇总错误数量；只看到最后一条查询有输出是不够的。小型演练可使用单事务恢复获得原子性，但这个模式不能与并行 job 同用。

工具版本是另一条边界。pg_dump 客户端会拒绝比自身主版本更新的服务器，输出主要面向相同或更新的目标版本，不能保证可以加载到更旧的主版本。应核对客户端、源库、目标库、扩展和恢复选项的实际组合，而不是只说“都是 PostgreSQL 所以可以恢复”。即使语法兼容，排序规则或权限差异也可能改变应用行为。

逻辑导出可以满足经测量确认的恢复目标，但不能任意重放到两次导出之间的时刻。物理基础备份加完整保留的 WAL 链，才提供对应的时间点恢复路径。导出间隔是否可接受，取决于允许的数据丢失窗口和恢复时间，不存在“短于一天就一定不行”的统一阈值。必须按实际要求设计留存与恢复链条。

快速验证

把 Bash 代码保存为 dump.sh。它自行创建实验 PostgreSQL 集群，并在退出时删除。可以用非 root 用户运行 PostgreSQL 18 工具，也可以使用下面的隔离容器；命令不发布网络端口，不挂载宿主机数据。两个数据库、归档和成功标记都只存在于实验临时目录及集群中。

docker run --rm --network none --user postgres --entrypoint bash -i \
 postgres:18-alpine < dump.sh

#!/usr/bin/env bash
set -euo pipefail
dump_lab=$(mktemp -d /tmp/pgdump-lab.XXXXXX)
cleanup() {
 if [ -f "$dump_lab/data/postmaster.pid" ]; then
 pg_ctl -D "$dump_lab/data" -m fast -w stop >/dev/null
 fi
 rm -rf -- "$dump_lab"
}
trap cleanup EXIT
initdb -D "$dump_lab/data" --no-locale --encoding=UTF8 --auth=trust >/dev/null
pg_ctl -D "$dump_lab/data" -l "$dump_lab/server.log" \
 -o "-k $dump_lab -p 55432 -c listen_addresses=''" -w start >/dev/null
export PGHOST="$dump_lab" PGPORT=55432 PGDATABASE=source_db
export DUMP_FILE="$dump_lab/source.dump" DUMP_OK="$dump_lab/dump-ok"
createdb source_db
createdb restored_db
psql -X -v ON_ERROR_STOP=1 <<'SQL'
CREATE TABLE customers (id integer PRIMARY KEY, name text);
CREATE TABLE orders (id integer PRIMARY KEY, customer_id integer REFERENCES customers(id));
INSERT INTO customers VALUES (1,'before');
INSERT INTO orders VALUES (10,1);
BEGIN ISOLATION LEVEL REPEATABLE READ READ ONLY;
SELECT pg_export_snapshot() AS snapshot_id \gset
\setenv DUMP_SNAPSHOT :snapshot_id
\! psql -X -v ON_ERROR_STOP=1 -c "BEGIN; INSERT INTO customers VALUES (2,'after'); INSERT INTO orders VALUES (20,2); COMMIT;" && pg_dump --format=custom --snapshot="$DUMP_SNAPSHOT" --file="$DUMP_FILE" && touch "$DUMP_OK"
COMMIT;
SQL
test -f "$DUMP_OK"
pg_restore --list "$DUMP_FILE" > "$dump_lab/archive-list"
pg_restore --exit-on-error --single-transaction --dbname=restored_db "$DUMP_FILE"
counts='SELECT (SELECT count(*) FROM customers), (SELECT count(*) FROM orders)'
test "$(psql -X -Atc "$counts")" = '2|2'
test "$(psql -X -d restored_db -Atc "$counts")" = '1|1'
test "$(psql -X -d restored_db -Atc 'SELECT count(*) FROM orders o LEFT JOIN customers c ON c.id=o.customer_id WHERE c.id IS NULL')" = 0
psql -X -d restored_db -v ON_ERROR_STOP=1 -c \
 'SELECT c.name,o.id FROM customers c JOIN orders o ON o.customer_id=c.id'
pg_dump --version
printf 'PASS: source=2|2 restored=1|1 orphan_orders=0\n'

第一个会话导出快照时，库中只有一位客户和一笔订单。在该事务保持打开时，第二个会话提交另一组有关联的数据。pg_dump 明确导入较早快照，所以恢复后计数是 1|1，源库当前计数则为 2|2。关联查询返回名为 before 的客户和十号订单，悬空订单检查结果为零。这样验证的是确定的并发时序，不依赖导出恰好跑得够慢。

PostgreSQL 18.6 上完整恢复与断言均通过。嵌套 shell 只有在写入和 dump 都成功后才创建标记，防止 psql 在外部命令失败后继续运行而掩盖失败。这个实验验证夹具中的快照选择和恢复，不代表已经测出真实应用的恢复时间。生产备份仍需保留实际恢复演练、归档校验值、留存策略与依赖记录，才能让一次成功导出成为可审阅的恢复能力。

来源

PostgreSQL pg_dump，快照、格式、范围与版本兼容，已核验 2026-09-10。
PostgreSQL pg_restore，恢复错误处理和事务选项，已核验 2026-09-10。

Postgres WAL 归档实现时间点恢复

Fri, 25 Jun 2027 00:00:00 +0000

时间点恢复从一份有效的物理基础备份开始，重放到指定恢复目标所需的 WAL。目标必须位于这份备份及其可用时间线能够覆盖的历史中。开启归档并不会自动获得恢复到任意更早日期的能力，也不会修复基础备份与期望终点之间已经丢失的一段日志。恢复范围由真正保存并可读取的材料决定。

坏掉的样子

复制出来的数据目录不会自动成为有效的在线备份。应采用受支持的备份方式，保存必要日志与时间线历史，并检查备份清单。清单校验程序能发现许多完整性问题，但它运行成功，不能证明更晚的归档日志存在，也不能证明业务期望的恢复目标对应正确状态。后两者需要实际启动恢复，再检查恢复出来的数据。

选择目标也需要明确边界。时间、事务标识、日志位置以及命名恢复点表达的含义不同；对适用的目标类型，是否包含目标边界由对应参数控制。本实验使用命名恢复点，避免依赖人工判断某个墙上时钟时间，但这个标记必须由管理操作事先写入日志。复用同一个名字可能使恢复停在首个同名位置，而不是操作人员心中较新的那个位置。

快速验证

在 Linux 环境中使用非超级操作系统账户运行脚本，准备 PostgreSQL 18 服务端、客户端以及支持保留属性复制、临时文件、硬链接和按文件同步的工具。本次在 PostgreSQL 18.6 上实际执行。集群位于私有临时目录，使用独立 Unix 套接字并关闭网络监听。本地归档用于演练恢复机制，不代表能够抵抗整台宿主机丢失。

#!/bin/sh
set -eu
umask 077
lab=$(mktemp -d /tmp/xbcatm-pitr.XXXXXX)
mkdir "$lab/socket" "$lab/archive"
primary=$lab/primary
restored=$lab/restored
missing=$lab/missing
cleanup() {
 for cluster in "$missing" "$restored" "$primary"; do
 if test -f "$cluster/postmaster.pid"; then
 pg_ctl -D "$cluster" -m fast -w stop >/dev/null
 fi
 done
}
trap cleanup EXIT
initdb -D "$primary" --no-locale --encoding=UTF8 --auth-local=trust --auth-host=reject >/dev/null
cat >> "$primary/postgresql.conf" <<CONF
listen_addresses = ''
unix_socket_directories = '$lab/socket'
port = 56432
wal_level = replica
archive_mode = on
archive_command = '$lab/archive-copy.sh "%p" "%f" "$lab/archive"'
CONF
cat > "$lab/archive-copy.sh" <<'ARCHIVE_HELPER'
#!/bin/sh
set -eu
wal_source=$1
wal_name=$2
archive_directory=$3
archive_target=$archive_directory/$wal_name
if test -e "$archive_target"; then
 cmp -s "$wal_source" "$archive_target"
 sync "$archive_target" "$archive_directory"
 exit 0
fi
archive_temporary=$(mktemp "$archive_directory/.incoming.XXXXXX")
trap 'rm -f "$archive_temporary"' EXIT HUP INT TERM
cp "$wal_source" "$archive_temporary"
sync "$archive_temporary"
ln "$archive_temporary" "$archive_target" || cmp -s "$wal_source" "$archive_target"
sync "$archive_target" "$archive_directory"
ARCHIVE_HELPER
chmod 700 "$lab/archive-copy.sh"
pg_ctl -D "$primary" -l "$lab/primary.log" -w -t 15 start >/dev/null
export PGHOST=$lab/socket PGPORT=56432 PGDATABASE=postgres PGUSER=$(id -un)
export PGCONNECT_TIMEOUT=2
psql -X -v ON_ERROR_STOP=1 -qAt <<'SQL'
CREATE TABLE marker (id integer PRIMARY KEY,value text);
INSERT INTO marker VALUES (1,'base');
SQL
pg_basebackup -D "$lab/base" -X stream -c fast -w
pg_verifybackup -q "$lab/base"
psql -X -v ON_ERROR_STOP=1 -qAt -c 'SELECT pg_switch_wal()' >/dev/null
psql -X -v ON_ERROR_STOP=1 -qAt <<'SQL'
INSERT INTO marker VALUES (2,'keep');
SELECT pg_create_restore_point('before_bad_change');
UPDATE marker SET value='bad' WHERE id=1;
DELETE FROM marker WHERE id=2;
SQL
segment=$(psql -X -v ON_ERROR_STOP=1 -qAt -c 'SELECT pg_walfile_name(pg_current_wal_lsn())')
psql -X -v ON_ERROR_STOP=1 -qAt -c 'SELECT pg_switch_wal()' >/dev/null
attempt=0
while ! test -f "$lab/archive/$segment"; do
 attempt=$((attempt+1))
 test "$attempt" -lt 100 || { echo 'archive segment did not arrive' >&2; exit 1; }
 sleep 0.1
done
printf 'primary_now '
psql -X -v ON_ERROR_STOP=1 -qAt -c "SELECT string_agg(id||':'||value,',' ORDER BY id) FROM marker"
mkdir "$restored"
cp -a "$lab/base/." "$restored/"
cat >> "$restored/postgresql.conf" <<CONF
port = 56433
archive_mode = off
restore_command = 'cp "$lab/archive/%f" "%p"'
recovery_target_name = 'before_bad_change'
recovery_target_action = 'pause'
CONF
touch "$restored/recovery.signal"
pg_ctl -D "$restored" -l "$lab/restored.log" -w -t 15 start >/dev/null
attempt=0
while test "$(PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt -c "SELECT pg_get_wal_replay_pause_state()='paused'")" != t; do
 attempt=$((attempt+1))
 test "$attempt" -lt 100 || { echo 'restore target was not reached' >&2; exit 1; }
 sleep 0.1
done
PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt <<'SQL'
SELECT pg_is_in_recovery(),pg_get_wal_replay_pause_state();
SELECT id,value FROM marker ORDER BY id;
DO $$ BEGIN
 IF (SELECT string_agg(id||':'||value,',' ORDER BY id) FROM marker)
 IS DISTINCT FROM '1:base,2:keep' THEN
 RAISE EXCEPTION 'point-in-time result mismatch';
 END IF;
END $$;
SQL
test ! -e "$lab/base/pg_wal/$segment"
mkdir "$lab/archive-missing" "$missing"
for archived_file in "$lab/archive/"*; do
 if test "${archived_file##*/}" != "$segment"; then
 cp "$archived_file" "$lab/archive-missing/"
 fi
done
cp -a "$lab/base/." "$missing/"
cat >> "$missing/postgresql.conf" <<CONF
port = 56434
archive_mode = off
restore_command = 'cp "$lab/archive-missing/%f" "%p"'
recovery_target_name = 'before_bad_change'
recovery_target_action = 'pause'
CONF
touch "$missing/recovery.signal"
if pg_ctl -D "$missing" -l "$lab/missing.log" -w -t 15 start >/dev/null 2>&1; then
 echo 'missing-segment server was briefly available'
fi
attempt=0
while pg_ctl -D "$missing" status >/dev/null 2>&1; do
 attempt=$((attempt+1))
 test "$attempt" -lt 100 || { echo 'missing-segment server did not stop' >&2; exit 1; }
 sleep 0.1
done
grep -F 'recovery ended before configured recovery target was reached' "$lab/missing.log"
test -f "$lab/archive/$segment"
echo missing_segment_target_unreachable
printf 'lab_directory %s\nrequired_segment %s\n' "$lab" "$segment"

主库最初只有第一行，值为 base。取得并验证基础备份后，脚本切换日志段，再插入值为 keep 的第二行，并创建错误修改之前的命名恢复点。只有在标记之后，才把第一行改成 bad、删除第二行。输出中的主库当前状态应只剩 1:bad，证明错误修改确实已经发生，不能把没有真正写入的错误当作成功排除的对象。

恢复使用基础备份的独立副本。恢复信号文件请求归档恢复，恢复命令提供归档文件，命名目标和暂停动作让回放停下来供检查。脚本等待暂停状态函数明确返回已经暂停。仅用另一个布尔函数得到真，只能证明暂停请求已发出，不一定证明回放此刻已经停止；两者在并发恢复时不能互换。

预期结果先表示实例仍在恢复且已暂停，再显示第一行为 base、第二行为 keep。SQL 断言核对两行组合后的精确内容。这同时证明较早的正确事务被保留，较晚的错误变更被排除，比“数据库已经接受连接”更有说服力：服务可能在恢复尚未到达目标时，就允许只读连接进入。

负向对照另外复制归档，但排除备份完成后必需的日志段。原归档保持完整，并且先确认基础备份本身没有带上被排除的那一段。使用不完整副本恢复时，最终必须因配置的目标尚未到达而发生致命错误。脚本等待该实验服务确实停止，并核对日志中的原因，而不是只凭首次启动命令的退出码下结论。缺段目标不可到达的标记，表示这项预期失败已经被观察到。

所有实验集群都会在脚本退出时停止，打印目录保留日志与数据便于复核。这次演练不会把恢复副本提升或交给业务应用使用，恢复到正确内容与接管生产流量是不同的验证事项。复制出来的失败实验也不会破坏原始归档，便于在同一套材料上再次复现成功路径。

接受恢复结果之前先核对

目标处的暂停给了核对业务不变量的机会。除了总行数，还应检查关联记录、事务边界和最后一项可以接受的操作。恢复目标处继续执行会结束恢复，不等于请求任意重放目标之后的所有变更。若要追求更晚的目标，应按文档规定停止实例、调整目标再继续，避免错误理解暂停与继续的含义。

记录基础备份身份、可用时间线、目标选择、恢复事实和实际耗时。配置文件及必需的外部软件也应纳入恢复方案，因为 WAL 不会恢复所有外部依赖。实验期间保护原始备份和归档，使不同目标的尝试有共同可信起点。一次成功证明的是一个具体目标；随着备份轮换，持续跨保留区间演练，才能判断承诺的恢复窗口是否始终可用。

来源

PostgreSQL 18 连续归档，基础备份、归档恢复与时间线要求，已核验 2026-09-10。
PostgreSQL 18 恢复目标，目标边界、暂停行为以及未到达目标时的致命失败，已核验 2026-09-10。
PostgreSQL 18 管理函数，命名恢复点及实际回放暂停状态，已核验 2026-09-10。
PostgreSQL 18 pg_verifybackup，清单验证及仍需实际恢复测试的原因，已核验 2026-09-10。

没验证的备份只是空想

Wed, 02 Jun 2027 00:00:00 +0000

备份任务完成，证明备份过程生成了一份材料；恢复演练则要证明这份材料、现有工具以及必要环境，能共同恢复出可用系统。这是不同的结论。恢复证据应明确使用了哪份备份、恢复到什么状态、补齐了哪些依赖，以及花了多久才让结果对应用真正有用。不能只保留一个任务成功时间，就省略后面的验证。

坏掉的样子

合法的数据库归档仍然可能依赖范围之外的对象。PostgreSQL 的单库导出工具只导出一个数据库，角色却属于整个集群。在独立集群里恢复带授权信息的备份时，可能因为被引用的角色不存在而失败。如果演练始终在原集群进行，这种缺少恢复材料的问题就会被环境中已有的角色掩盖。

恢复错误也需要明确处理。恢复工具默认可以在 SQL 出错后继续，并在末尾报告错误数量。部分表能够查询，不代表半恢复状态就可以接受。这个小型夹具选择把恢复放进一个事务，使成功具有原子性；发生预期失败时，也不会留下已经恢复了一半的表，便于确认依赖修正之后重新执行的结果。

恢复位置正确是另一项要求。完全恢复成功的备份，也可能按设计不包含它之后发生的变更。校验和证明材料与记录一致，不证明其中包含最新业务事件。同样，总行数相同，并不能排除金额、关联关系或权限错误。验证项需要表达应用语义，不能因为容易查询就只检查几个不能区分正确与错误状态的数字。

快速验证

在 Linux 环境中使用非超级操作系统账户运行脚本，准备 PostgreSQL 18 服务端、客户端和摘要校验工具。本次实际执行版本是 PostgreSQL 18.6。脚本建立互相独立的临时源集群与目标集群，使用私有 Unix 套接字，不打开网络监听。实验角色没有登录能力，通过受控角色切换验证授权，不涉及真实账户凭据。

#!/bin/sh
set -eu
umask 077
lab=$(mktemp -d /tmp/xbcatm-restore.XXXXXX)
mkdir "$lab/socket"
source=$lab/source
target=$lab/target
cleanup() {
 for cluster in "$target" "$source"; do
 if test -f "$cluster/postmaster.pid"; then
 pg_ctl -D "$cluster" -m fast -w stop >/dev/null
 fi
 done
}
trap cleanup EXIT
for cluster in "$source" "$target"; do
 initdb -D "$cluster" --no-locale --encoding=UTF8 --auth-local=trust --auth-host=reject >/dev/null
 cat >> "$cluster/postgresql.conf" <<CONF
listen_addresses = ''
unix_socket_directories = '$lab/socket'
CONF
done
printf 'port = 56432\n' >> "$source/postgresql.conf"
printf 'port = 56433\n' >> "$target/postgresql.conf"
pg_ctl -D "$source" -l "$lab/source.log" -w -t 15 start >/dev/null
pg_ctl -D "$target" -l "$lab/target.log" -w -t 15 start >/dev/null
export PGHOST=$lab/socket PGPORT=56432 PGDATABASE=postgres PGUSER=$(id -un)
export PGCONNECT_TIMEOUT=2
psql -X -v ON_ERROR_STOP=1 -qAt <<'SQL'
CREATE ROLE backup_reader NOLOGIN;
CREATE TABLE customers (id integer PRIMARY KEY,name text NOT NULL);
CREATE TABLE orders (id integer PRIMARY KEY,customer_id integer REFERENCES customers,amount_cents integer CHECK (amount_cents>0));
INSERT INTO customers VALUES (1,'Ada');
INSERT INTO orders VALUES (10,1,4210),(11,1,1865);
CREATE VIEW order_totals AS SELECT c.name,sum(o.amount_cents) AS total_cents FROM customers c JOIN orders o ON o.customer_id=c.id GROUP BY c.id,c.name;
GRANT SELECT ON customers,orders,order_totals TO backup_reader;
SQL
pg_dump -Fc -w -f "$lab/snapshot.dump" postgres
sha256sum "$lab/snapshot.dump" > "$lab/snapshot.sha256"
psql -X -v ON_ERROR_STOP=1 -qAt -c 'INSERT INTO orders VALUES (12,1,1000)'
printf 'source_after_backup_orders '
psql -X -v ON_ERROR_STOP=1 -qAt -c 'SELECT count(*) FROM orders'
sha256sum -c "$lab/snapshot.sha256"
if PGPORT=56433 pg_restore --single-transaction --exit-on-error -w -d postgres "$lab/snapshot.dump" >"$lab/missing-role.log" 2>&1; then
 echo 'restore unexpectedly ignored a missing role' >&2
 exit 1
fi
grep -F 'role "backup_reader" does not exist' "$lab/missing-role.log"
test "$(PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt -c "SELECT to_regclass('public.orders') IS NULL")" = t
echo failed_restore_rolled_back
PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt -c 'CREATE ROLE backup_reader NOLOGIN'
PGPORT=56433 pg_restore --single-transaction --exit-on-error -w -d postgres "$lab/snapshot.dump"
PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt <<'SQL'
SELECT count(*) FROM orders;
SELECT name,total_cents FROM order_totals;
SELECT has_table_privilege('backup_reader','orders','SELECT'),has_table_privilege('backup_reader','orders','INSERT');
DO $$ BEGIN
 IF (SELECT count(*) FROM orders)<>2 OR
 (SELECT string_agg(id||':'||amount_cents,',' ORDER BY id) FROM orders) IS DISTINCT FROM '10:4210,11:1865' OR
 (SELECT total_cents FROM order_totals WHERE name='Ada') IS DISTINCT FROM 6075 OR
 (SELECT count(*) FROM orders o LEFT JOIN customers c ON c.id=o.customer_id WHERE c.id IS NULL)<>0 THEN
 RAISE EXCEPTION 'restored business data mismatch';
 END IF;
END $$;
DO $$ BEGIN
 BEGIN
 INSERT INTO orders VALUES (98,999,100);
 RAISE EXCEPTION 'restored foreign key unexpectedly accepted an orphan';
 EXCEPTION WHEN foreign_key_violation THEN
 RAISE NOTICE 'restored foreign key rejected orphan';
 END;
END $$;
SET ROLE backup_reader;
SELECT id,amount_cents FROM orders ORDER BY id;
DO $$ BEGIN
 BEGIN
 INSERT INTO orders VALUES (99,1,100);
 RAISE EXCEPTION 'read-only role unexpectedly wrote data';
 EXCEPTION WHEN insufficient_privilege THEN
 RAISE NOTICE 'read-only role rejected write';
 END;
END $$;
SQL
printf 'lab_directory %s\n' "$lab"

源库包含一个客户、两笔订单、汇总视图、外键以及只读角色授权。自定义格式归档捕获这个状态，之后源库又增加第三笔订单。输出中源库订单数为三，证明选定备份点之外确实存在后续活动，避免测试把当前源库和已经保存的快照混为一谈。恢复目标是否应该包含第三笔，需要由选择的备份点决定。

摘要检查能够成功，首次恢复却必须由于目标缺少只读角色而失败。脚本核对具体错误，并确认订单表随事务回滚。这就是只检查归档文件无法发现的环境依赖。随后，在目标创建已经说明的实验角色，再使用同一份归档重复恢复，不通过跳过授权来掩盖缺失对象。

恢复目标必须包含原来的两笔订单及其正确标识、金额，视图必须给出客户 Ada 和六千零七十五分的汇总。第三笔订单此时缺席才是正确结果。插入不存在客户的订单，必须被已经恢复的外键拒绝。权限查询显示允许读取、拒绝插入；切换到只读角色后，实际查询应成功，真实写入尝试则必须失败。

这些断言分别覆盖数据内容、应用查询、关联约束以及实际权限。所有实验服务在退出时停止，打印目录保留归档和日志。演练没有测试外部认证、加密密钥恢复或应用进程启动；若这些属于真实系统的恢复依赖，就必须在完整恢复方案中补充，不能把角色授权验证直接当成整套登录链路已经正常。

留下能支持决策的恢复结果

生产演练应从准备承担恢复职责的来源取回材料，重建所需环境，恢复数据，再执行代表性的应用行为。安装兼容软件是正常恢复工作的一部分，应把所需时间和前提计入，而不是假定一台已经准备好的主机永远存在。生产系统不可用时，恢复所需访问能力也应该仍然能够取得。

把恢复总耗时与恢复时间目标比较，把恢复出来的终点与允许丢失的数据范围比较。计时应包括获取材料、验证以及应用真正可用，而不只是数据库命令本身运行了几秒。较大的恢复任务可以选择适合负载的事务与并行选项，但要明确发生部分失败之后如何判断和处理，不能一边要求原子性一边又采用不兼容的执行方式。

备份工具、模式、角色、保留策略或基础设施发生变化后，应重新演练。保存成功检查和已经修正的失败作为证据，让下一次恢复能够沿着确定输入重现。具有已知边界的可重复恢复流程，才能支持运行决策；备份调度器显示绿色，单独回答不了系统是否已经具备可用的恢复能力。

来源

PostgreSQL 18 pg_dump，单库导出范围及不包含的集群级对象，已核验 2026-09-12。
PostgreSQL 18 pg_restore，错误处理、单事务恢复、授权及并行限制，已核验 2026-09-12。
CISA 勒索软件防护指南，结合恢复依赖测试备份可用性与完整性，已核验 2026-09-12。

桶版本化与生命周期管理成本

Sat, 08 May 2027 00:00:00 +0000

S3 版本化在同一个键下保留多个版本，只要所需版本仍在，就能恢复许多误覆盖和普通删除。它并不防止所有删除，也不会独立构成备份。真正能否恢复应用，取决于保留策略、访问权限、加密密钥是否仍然可用，以及恢复程序是否经过验证。版本存在与业务恢复成功之间，还有需要明确检查的步骤。

分清版本化状态

在启用版本化的桶中，PUT 产生新版本 ID，同时保留之前的数据版本。每个版本存储完整对象，并非只记录变化的字节。因此，反复覆盖一个大对象，即使可见键数量保持不变，存储成本也可能持续增长。这与块级增量快照的空间模型不同，不能只用修改了多少字节估算对象版本的费用。

启用之前已存在的对象保留 null 版本 ID，新产生的版本化写入不会覆盖那个旧版本。一旦启用，桶就不能回到从未版本化的状态，但可以暂停版本化。暂停期间，后续写入使用 null 版本槽位，可能替换已有 null 版本。讨论覆盖是否安全时，必须明确桶当前处于哪一种状态，不能把暂停与启用混为一谈。

null 是真正的版本标识，不是永久保留保证。null 版本变成非当前版本后，可以受到非当前版本过期规则影响；在授权允许时，也能够按明确版本 ID 删除。因此，列表中出现 null 并不能证明那份旧数据不参与生命周期清理，更不能把它当成永远不会消失的恢复基线。

删除标记改变可见性

启用版本化时，不带版本 ID 的普通 DELETE 创建删除标记。标记处于当前位置后，不指定版本的 GET 通常返回 404；显式请求删除标记的版本 ID 则返回 405。较早数据仍可通过其数据版本 ID 获取，但还受到访问权限、存储类别及加密条件影响。看见 404 不能直接推断底下所有版本已经消失。

删除标记没有对象载荷，却不是免费零字节条目，S3 会按它保存的键名字节收费。删除那个明确的当前标记，可以暴露前一版本，但前一版本本身也可能仍是标记。另一种恢复方式是复制明确的历史数据版本，生成新的当前数据版本，同时保留历史。标记没有数据，不能把它当成普通对象复制来恢复。

按指定 ID 删除数据版本，是另一种永久操作，版本化本身不能把被永久删除的版本找回来。配置 MFA Delete 后，永久删除版本和改变版本化状态会增加相应认证要求，但开启版本化并不会自动开启这种保护。AWS 不支持将 MFA Delete 与生命周期配置一起使用，不能假设所有保护开关可以无条件同时启用。

生命周期表达的是保留取舍

当前版本 Expiration 与 NoncurrentVersionExpiration 各自处理不同对象。启用版本化时，当前数据过期通常创建标记，并把数据变为非当前版本；非当前版本过期则永久删除符合条件的旧数据。资格按成为非当前版本后的时间计算，可选的保留版本数量还会增加另一项条件，并不是简单比较最初上传时间。

生命周期操作异步执行。配置三十天规则，不能证明任何时刻都精确保留三十份版本。过滤范围、写入频率、保留数量、复制状态和 Object Lock 都可能影响资格。转入冷存储保留数据，但会改变存储、取回和最短保存期限等费用。应结合真实对象大小和恢复需求计算，不能只比较表面上的每字节存储单价。

坏掉的样子

普通列表保持稳定时，非当前版本字节仍可能增长并推高费用。应检查版本清单与生命周期实际覆盖范围，而不是期待一个固定的版本数量比率可以诊断所有情况。桶不必像本地磁盘那样物理写满，成本就可能已经失控；生命周期也不是硬性预算上限，更不是唯一可能的保留控制办法。

规则过于激进则会产生相反问题：真正需要恢复的旧版本已经被永久删除。保留窗口应覆盖合理的最迟发现时间和恢复要求。HEAD 能检查元数据，但不会下载并验证对象内容，成功的元数据请求不能当作完成恢复测试。应确认目标版本存在、可读，并且其字节及业务内容确实符合预期。

快速验证

用 Python 3 运行下面模型，保持断言开启。它完全在内存中表示启用版本化的版本栈，其中包含一份原有 null 数据版本。不需要 AWS 账户、凭据或远程对象。删除标记的计费、真实时间、权限、生命周期调度以及并发写入，都明确不在这个简化模型范围内。

versions = [("null", b"old"), ("v1", b"new")]
marker = ("d1", None)
versions.append(marker)
def get_current():
 payload = versions[-1][1]
 return (404, None) if payload is None else (200, payload)
assert get_current() == (404, None)
assert sum(len(data) for _, data in versions if data is not None) == 6
versions.remove(marker)
assert get_current() == (200, b"new")
print("remove current marker: previous data visible")
versions.append(("d2", None))
# Copy an explicit data version to create a new current version.
old = next(data for identifier, data in versions if identifier == "null")
versions.append(("v2", old))
assert get_current() == (200, b"old")
assert any(identifier == "d2" for identifier, _ in versions)
print("copy explicit data version: new current version; history retained")
# Noncurrent null versions are not inherently protected from deletion.
versions[:] = [entry for entry in versions if entry[0] != "null"]
assert get_current() == (200, b"old")
print("remove old null version: current copy remains")

三行输出分别表示暴露上一版本、复制指定历史数据，以及删除非当前 null 版本。创建标记时数据载荷字节仍保留，但这个计数没有包含标记需要收费的键名字节，不能当作真实账单预测。模型也不为生命周期保留数量给出数字保证，因为那需要时间、过滤和其他条件一起参与判断。

真实恢复时，应完整处理分页的数据版本和删除标记列表，并筛选准确键名，避免把同前缀其他对象混进去。选定明确的数据版本之后，取回并验证内容，再决定是否改变生产当前状态。读取历史、验证业务数据、重新发布当前版本是不同动作，需要分别记录结果，不能用一条列表命令代替整套恢复演练。

来源

AWS：S3 版本化，版本化与 null 版本如何工作，已核验 2026-09-16。
AWS：S3 删除标记，删除标记做什么、如何撤销，已核验 2026-09-16。
AWS：S3 生命周期管理，当前与非当前版本的过期和迁移规则，已核验 2026-09-16。
AWS 对象过期，资格条件、永久删除与异步执行，已核验 2026-10-15。
AWS MFA Delete，可选保护及生命周期约束，已核验 2026-10-15。
AWS 恢复旧版本，显式版本复制与恢复，已核验 2026-10-15。

WAL 归档保留可恢复的历史

Thu, 22 Apr 2027 00:00:00 +0000

连续 WAL 归档把已经完成的日志文件保存在 PostgreSQL 活跃日志目录之外。配合合适的基础备份和不中断的恢复链，这些文件允许恢复过程把有日志保护的数据库变更重放到覆盖范围内的目标。归档与普通提交确认是两条不同的路径：事务可能已经提交，但所在日志段还没有结束，或者归档目的地仍然不可用。

坏掉的样子

PostgreSQL 在执行过程中会修改缓冲区里的数据页；依赖某段日志的数据页持久化之前，相应 WAL 必须先持久化。这不表示数据库从不写数据文件，也不表示每次提交都要等待归档完成。临时表和不记录日志的表内容，也不会仅因开启归档就获得普通 WAL 所提供的恢复保证。把这些边界混在一起，会高估某份备份能恢复的内容。

归档命令的返回码是一条数据完整性契约。返回零意味着文件已经成功保存；其他保留条件也满足后，数据库就可以回收源文件。如果复制失败却返回成功，这条契约便被悄悄打断。非零返回会触发重试，持续失败会使尚未归档的日志留在主库，最终可能填满文件系统。执行检查点既不会修好目的地，也不会解除这份保留义务。

已有文件名必须仔细处理。内容完全相同且已经可靠落盘的重复归档应当成功；同名但字节不同则必须失败，并保留原文件。仅因为目标已经存在就返回成功，会掩盖损坏，或掩盖两个不同集群错误地共用同一个归档命名空间。这里不能用“文件存在”替代“这份内容已经安全保存”。

快速验证

使用非超级操作系统账户运行下面的脚本，并把 PostgreSQL 18 服务端和客户端程序放入 PATH。环境需要支持保留属性复制、临时文件、硬链接以及按文件同步的 Linux 工具。本次在 PostgreSQL 18.6 上执行。脚本创建自己的私有临时集群与 Unix 套接字，关闭网络监听，只写测试数据。本地归档用于展示命令契约，并不是独立故障域里的灾难恢复副本。

#!/bin/sh
set -eu
umask 077
lab=$(mktemp -d /tmp/xbcatm-archive.XXXXXX)
mkdir "$lab/socket" "$lab/archive"
primary=$lab/primary
cleanup() {
 if test -f "$primary/postmaster.pid"; then
 pg_ctl -D "$primary" -m fast -w stop >/dev/null
 fi
}
trap cleanup EXIT
initdb -D "$primary" --no-locale --encoding=UTF8 --auth-local=trust --auth-host=reject >/dev/null
cat > "$lab/archive-copy.sh" <<'ARCHIVE_HELPER'
#!/bin/sh
set -eu
wal_source=$1
wal_name=$2
archive_directory=$3
archive_target=$archive_directory/$wal_name
if test -e "$archive_target"; then
 cmp -s "$wal_source" "$archive_target"
 sync "$archive_target" "$archive_directory"
 exit 0
fi
archive_temporary=$(mktemp "$archive_directory/.incoming.XXXXXX")
trap 'rm -f "$archive_temporary"' EXIT HUP INT TERM
cp "$wal_source" "$archive_temporary"
sync "$archive_temporary"
ln "$archive_temporary" "$archive_target" || cmp -s "$wal_source" "$archive_target"
sync "$archive_target" "$archive_directory"
ARCHIVE_HELPER
chmod 700 "$lab/archive-copy.sh"
cat >> "$primary/postgresql.conf" <<CONF
listen_addresses = ''
unix_socket_directories = '$lab/socket'
port = 56432
wal_level = replica
archive_mode = on
archive_command = '$lab/archive-copy.sh "%p" "%f" "$lab/archive"'
CONF
pg_ctl -D "$primary" -l "$lab/primary.log" -w -t 15 start >/dev/null
export PGHOST=$lab/socket PGPORT=56432 PGDATABASE=postgres PGUSER=$(id -un)
export PGCONNECT_TIMEOUT=2
psql -X -v ON_ERROR_STOP=1 -qAt -c 'CREATE TABLE archive_marker (id integer PRIMARY KEY)'
pg_basebackup -D "$lab/base" -X stream -c fast -w
pg_verifybackup -q "$lab/base"
echo base_backup_verified
failures_before=$(psql -X -v ON_ERROR_STOP=1 -qAt -c 'SELECT failed_count FROM pg_stat_archiver')
psql -X -v ON_ERROR_STOP=1 -qAt <<'SQL'
ALTER SYSTEM SET archive_command='/bin/false';
SELECT pg_reload_conf();
SQL
attempt=0
while test "$(psql -X -v ON_ERROR_STOP=1 -qAt -c "SELECT current_setting('archive_command')='/bin/false'")" != t; do
 attempt=$((attempt+1))
 test "$attempt" -lt 100 || exit 1
 sleep 0.1
done
psql -X -v ON_ERROR_STOP=1 -qAt -c 'INSERT INTO archive_marker VALUES (1)' -c 'SELECT pg_switch_wal()' >/dev/null
attempt=0
while test "$(psql -X -v ON_ERROR_STOP=1 -qAt -c "SELECT failed_count>$failures_before FROM pg_stat_archiver")" != t; do
 attempt=$((attempt+1))
 test "$attempt" -lt 700 || { echo 'archive failure was not observed' >&2; exit 1; }
 sleep 0.1
done
failed_segment=$(psql -X -v ON_ERROR_STOP=1 -qAt -c 'SELECT last_failed_wal FROM pg_stat_archiver')
test ! -f "$lab/archive/$failed_segment"
echo archive_failure_observed
psql -X -v ON_ERROR_STOP=1 -qAt -c CHECKPOINT
test -f "$primary/pg_wal/$failed_segment"
echo unarchived_wal_retained_after_checkpoint
archived_before=$(psql -X -v ON_ERROR_STOP=1 -qAt -c 'SELECT archived_count FROM pg_stat_archiver')
psql -X -v ON_ERROR_STOP=1 -qAt <<'SQL'
ALTER SYSTEM RESET archive_command;
SELECT pg_reload_conf();
SQL
attempt=0
while ! test -f "$lab/archive/$failed_segment" || test "$(psql -X -v ON_ERROR_STOP=1 -qAt -c "SELECT archived_count>$archived_before FROM pg_stat_archiver")" != t; do
 attempt=$((attempt+1))
 test "$attempt" -lt 700 || { echo 'archive repair was not observed' >&2; exit 1; }
 sleep 0.1
done
cmp -s "$primary/pg_wal/$failed_segment" "$lab/archive/$failed_segment"
echo archive_repaired
"$lab/archive-copy.sh" "$primary/pg_wal/$failed_segment" "$failed_segment" "$lab/archive"
echo identical_repeat_accepted
printf 'different bytes\n' > "$lab/conflicting-input"
if "$lab/archive-copy.sh" "$lab/conflicting-input" "$failed_segment" "$lab/archive"; then
 echo 'conflicting archive input was accepted' >&2
 exit 1
fi
cmp -s "$primary/pg_wal/$failed_segment" "$lab/archive/$failed_segment"
echo conflicting_repeat_rejected
printf 'lab_directory %s\nfailed_segment %s\n' "$lab" "$failed_segment"

首先应出现基础备份已经验证的标记，然后脚本把归档命令临时改成一个确实返回失败的程序。它等待统计中真实出现失败，确认失败文件没有进入归档，再请求检查点，并核对主库仍然保留原始日志。恢复归档命令后，只有进度增加且指定目标文件出现，才打印归档修复标记；随后还比较双方字节，检查复制出来的实际内容。

最后两个标记分别表示接受内容一致的重复归档，以及拒绝同名但内容不同的输入。后一项故意构造不同字节，并再次检查真实归档没有变化。辅助程序先写临时文件、同步内容，再以不覆盖目标的硬链接方式建立最终名字。发现已有名字时，只有比较一致并完成同步才能成功。这样验证的是归档器实际履行的行为，不是把某次命令运行结束当成完整性证明。

所有实验服务都会在脚本退出时停止，打印出的目录保留日志和文件供复核。等待或比较失败会终止实验；归档器故意失败是预期观察，但其他步骤的错误不能因此被统一忽略。实验还保留了原始归档，便于核对拒绝冲突之后的状态，而不是只依赖终端上的成功文字。

保留一个真正可恢复的区间

观察归档进度时，还要一起看积压和剩余空间。归档统计中的失败次数能够记录这次普通命令失败，但部分 shell 错误或归档进程崩溃会触发进程重启，而不增加这个计数，所以也需要读取服务端日志。归档成功数量增长，只证明有文件成功，不足以证明某个基础备份到指定目标之间所需的每个文件都在。

日志段通常结束后才进入归档；低写入实例可以通过归档超时促成切段，代价是占用更多归档空间。流复制发送日志的时机不同，不能把其中一条链路的延迟当成另一条的保证。保留策略必须同时覆盖基础备份、全部必要日志和相关时间线历史，并与承诺的可恢复区间一致。配置文件以及数据库外部依赖需要单独保护。

清单验证可以检查备份完整性，但仍然代替不了恢复演练。实际恢复到隔离实例后，应记录业务数据的状态和已经覆盖的终点，再判断是否达到恢复目标。只有文件数量、备份任务退出码或一个最近成功时间，无法单独回答错误操作发生之前究竟能恢复到哪里，也无法回答恢复出来的数据是否符合业务预期。

来源

PostgreSQL 18 连续归档，归档返回码、重复内容、日志保留与恢复链，已核验 2026-09-10。
PostgreSQL 18 pg_verifybackup，备份清单验证及其边界，已核验 2026-09-10。
PostgreSQL 18 累计统计，归档进度与失败计数，已核验 2026-09-10。

全量与增量备份

Sun, 27 Dec 2026 00:00:00 +0000

全量备份提供一个不依赖同种方法更早备份的基线。增量备份保存相对于指定参考点的变化，恢复时仍然依赖补全省略内容所需的材料。这一区别描述的是恢复依赖，不是对执行速度或传输字节数的普遍保证。如果变化过的数据范围很大，增量备份本身也可能相当大，不能仅凭“增量”两个字就承诺备份很快。

坏掉的样子

全量备份损坏，可能使所有依赖它的增量都失去恢复能力。同样，删除必要的中间增量，即使最新目录与清单还完整，也可能破坏后续恢复。保留策略必须沿着依赖关系作决定，不能只按时间戳独立删除看起来较旧的目录。一个较新的文件，并不自动替代所有较旧的恢复材料。

参考对象同样重要。相对于上一次增量建立备份，会形成一条链；相对于某个全量基线建立备份，则具有另一种依赖形状，通常称为差异备份。合成全量通过已有备份材料重建一个新基线。这些名词在不同工具中不保证实现完全相同，因此，不能只依据名称设计轮换，必须核对实际产品的清单格式与恢复规则。

物理数据库备份还需要让捕获文件达到一致状态的必要日志。全量独立于更早备份，并不意味着它独立于全部恢复日志、软件、配置或外部依赖。本实验通过流式收集带上所需 WAL，并保持整个备份链中的数据库版本与页面校验配置一致。这样验证的是明确的一套恢复条件，而不是省略前提的“有全量就一定能启动”。

快速验证

在 Linux 环境中，以非超级操作系统账户运行下面脚本，准备 PostgreSQL 18 服务端和客户端程序，包括合成备份工具。本次实际执行版本是 PostgreSQL 18.6。脚本创建私有临时主库与恢复集群，不打开网络监听。取得备份之前先开启日志摘要，让数据库能够为增量请求识别发生变化的数据块。

#!/bin/sh
set -eu
umask 077
lab=$(mktemp -d /tmp/xbcatm-incremental.XXXXXX)
mkdir "$lab/socket"
primary=$lab/primary
restored=$lab/restored
cleanup() {
 for cluster in "$restored" "$primary"; do
 if test -f "$cluster/postmaster.pid"; then
 pg_ctl -D "$cluster" -m fast -w stop >/dev/null
 fi
 done
}
trap cleanup EXIT
initdb -D "$primary" --no-locale --encoding=UTF8 --auth-local=trust --auth-host=reject >/dev/null
cat >> "$primary/postgresql.conf" <<CONF
listen_addresses = ''
unix_socket_directories = '$lab/socket'
port = 56432
summarize_wal = on
CONF
pg_ctl -D "$primary" -l "$lab/primary.log" -w -t 15 start >/dev/null
export PGHOST=$lab/socket PGPORT=56432 PGDATABASE=postgres PGUSER=$(id -un)
export PGCONNECT_TIMEOUT=2
psql -X -v ON_ERROR_STOP=1 -qAt <<'SQL'
CREATE TABLE marker (id integer PRIMARY KEY,value text);
INSERT INTO marker VALUES (1,'full');
SQL
pg_basebackup -D "$lab/base" -X stream -c fast -w
psql -X -v ON_ERROR_STOP=1 -qAt -c "INSERT INTO marker VALUES (2,'first_increment')"
pg_basebackup -D "$lab/inc1" --incremental="$lab/base/backup_manifest" -X stream -c fast -w
psql -X -v ON_ERROR_STOP=1 -qAt <<'SQL'
UPDATE marker SET value='final' WHERE id=1;
DELETE FROM marker WHERE id=2;
INSERT INTO marker VALUES (3,'second_increment');
SQL
pg_basebackup -D "$lab/inc2" --incremental="$lab/inc1/backup_manifest" -X stream -c fast -w
for backup in "$lab/base" "$lab/inc1" "$lab/inc2"; do
 pg_verifybackup -q "$backup"
done
echo input_backups_verified
if pg_combinebackup -o "$lab/missing-middle" "$lab/base" "$lab/inc2" >"$lab/missing-middle.log" 2>&1; then
 echo 'incomplete chain unexpectedly combined' >&2
 exit 1
fi
grep -E 'starts at LSN .*but expected' "$lab/missing-middle.log"
echo missing_middle_rejected
pg_combinebackup -o "$lab/combined" "$lab/base" "$lab/inc1" "$lab/inc2"
pg_verifybackup -q "$lab/combined"
echo combined_backup_verified
mkdir "$restored"
cp -a "$lab/combined/." "$restored/"
cat >> "$restored/postgresql.conf" <<CONF
port = 56433
summarize_wal = off
CONF
pg_ctl -D "$restored" -l "$lab/restored.log" -w -t 15 start >/dev/null
PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt <<'SQL'
SELECT pg_is_in_recovery();
SELECT id,value FROM marker ORDER BY id;
DO $$ BEGIN
 IF (SELECT string_agg(id||':'||value,',' ORDER BY id) FROM marker)
 IS DISTINCT FROM '1:final,3:second_increment' THEN
 RAISE EXCEPTION 'incremental restore result mismatch';
 END IF;
END $$;
SQL
printf 'lab_directory %s\n' "$lab"

全量备份包含第一行，值为 full。第一次增量参考这份全量的清单，并增加第二行。第二次增量参考第一次增量的清单，把第一行改为 final，删除第二行，再增加第三行。这不仅测试新行出现，也测试已有行的更新和删除，避免把简单追加成功误当成整个增量恢复语义正确。

重建之前，脚本逐份验证所有输入备份。第一次合成故意只提供全量和第二次增量，它必须由于起始日志位置不匹配而失败；脚本检查这个具体原因后，才打印缺少中间备份被拒绝的标记。负向对照没有删除任何原始备份。这样的失败揭示了单纯统计目录数量无法识别的依赖关系。

完整合成命令按顺序提供全量、第一次增量与第二次增量。输出的合成全量再次接受清单验证，然后复制到独立恢复目录并实际启动。预期只有第一行 final 和第三行 second_increment，SQL 断言检查这两行组合后的精确结果。实例已经结束恢复，先前删除的第二行不能重新出现，否则说明恢复结果不符合第二次增量所代表的状态。

合成工具验证的是输入之间的关系，并不替代每一份输入的完整性检查。因此，输入验证、输出验证与真实启动分别建立不同事实。脚本使用普通复制，让恢复实例运行时保留原始备份不变。退出时停止全部实验服务，打印目录保留日志和材料供复核，不把运行中的恢复目录当成唯一剩余备份。

核算恢复成本，不只看备份速度

增量可以减少重复复制未变数据块，但恢复可能先要取得、验证和组合多份材料，之后才能启动数据库。应测量包括恢复与应用核验在内的完整路径。每天备份变快，不足以证明事故发生时能够达到恢复时限；存储传输、重建所需额外空间和后续重放，都可能成为真正的限制。

保留策略旁边应维护依赖清单。PostgreSQL 允许合成全量成为后续合成的输入，这会改变操作人员需要取回的链路。按照既定策略退役旧材料之前，应先验证新基线。改变校验状态或引擎要求，也可能需要重新取得全量。每次轮换后，既要演练近期终点，也要演练承诺保留的较旧终点，防止节省存储时悄悄缩短了真正可恢复的区间。

来源

PostgreSQL 18 pg_basebackup，增量参考点、日志摘要与必要日志收集，已核验 2026-09-10。
PostgreSQL 18 pg_combinebackup，依赖顺序、合成全量与完整性验证边界，已核验 2026-09-12。
PostgreSQL 18 pg_verifybackup，真实恢复测试之前的清单校验，已核验 2026-09-10。

备份遵循 3-2-1 原则

Sun, 30 Aug 2026 00:00:00 +0000

经典的三二一备份规则要求三份数据，分布在两类存储介质上，其中一份位于异地。正在使用的数据本身算一份，因此还需要两份备份。规则的作用是开始拆分共同故障影响，并不保证任意三个文件名都能抵抗硬件故障、误删、管理凭据被盗，或者被同步传播到所有副本的错误。

坏掉的样子

副本之间共享的可能不仅是内容。两个目录可能在同一块盘上，两个虚拟卷可能依赖同一个存储阵列，若干远端备份也可能都能被已经失陷的生产管理员删除。因此，设备、地理位置和访问权限边界需要分别检查。异地降低了本地灾害的共同影响，却不会自动使数据变成离线或不可修改状态。

硬链接是“只数名字”的直接反例。它给同一个底层文件增加目录入口，原地修改文件时，两个名字所看到的内容都会变化。单独复制出来的文件可以抵抗这一种修改，保留较早字节，但仍然可能与原文件共享设备和管理权限风险。因此，“不是同一个文件”和“具备独立灾难恢复能力”之间还有很大距离。

同步也可能造成误判。一个迅速传播删除的镜像，会把恢复所需的旧版本一起移除。保留时间与版本选择，和目标数量一样重要。校验和可以发现内容与可信预期值不符，但若攻击者可以同时替换文件和校验值，同一权限范围内保存的校验和本身并不能证明没有发生恶意替换。

快速验证

把以下内容保存为 copies_lab.py，在支持硬链接的文件系统上用普通 Python 运行，并保持断言开启。脚本只使用标准库和临时文件。两个目录名模拟位置，实际上仍在同一个本地文件系统中。这是一次修改隔离与恢复演练，不是这台机器已经拥有真正异地备份介质的证明。

import hashlib
import json
import os
import shutil
import tempfile
from pathlib import Path

def digest(path):
 return hashlib.sha256(path.read_bytes()).hexdigest()

with tempfile.TemporaryDirectory(prefix="xbcatm-copies-") as directory:
 root = Path(directory)
 primary_site = root / "site-a"
 other_site = root / "site-b-simulation"
 primary_site.mkdir()
 other_site.mkdir()
 primary = primary_site / "account.json"
 primary.write_text('{"account":"example","balance_cents":2500}\n')
 expected = digest(primary)
 alias = primary_site / "hardlink.json"
 os.link(primary, alias)
 independent = other_site / "snapshot.json"
 shutil.copy2(primary, independent)
 assert os.path.samefile(primary, alias)
 assert not os.path.samefile(primary, independent)
 primary.write_text('{"account":"example","balance_cents":0}\n')
 assert digest(alias) != expected
 assert digest(independent) == expected
 print("hardlink_changed_with_primary")
 print("independent_copy_kept_original_bytes")
 primary_site.rename(root / "site-a-unavailable")
 assert not primary.exists()
 restored = root / "restored.json"
 shutil.copy2(independent, restored)
 assert digest(restored) == expected
 assert json.loads(restored.read_text()) == {"account": "example", "balance_cents": 2500}
 print("restored_without_original_path", 2500)
 assert independent.stat().st_dev == restored.stat().st_dev
 print("same_filesystem_lab_not_real_offsite_protection")

夹具最初保存一个余额为两千五百分的账户。随后创建硬链接名字和单独复制的快照，并在修改源文件之前记录预期摘要。文件身份检查明确哪一个路径仍指向同一文件。一次原地写入把源文件改为零，硬链接看到的值也随之变化；独立复制的文件则继续保持预期字节。

前两个输出标记确认了这种差别，证明增加第二个文件名没有提供抵抗本次修改的另一份可恢复版本。这不表示文件系统快照等同于硬链接；快照实现有自己的写时复制与保留语义，不能因为都表现成一个可访问路径，就把它们当作同一种存储机制。这里验证的是代码明确创建的硬链接与普通副本。

接着，脚本重命名模拟主站点目录，使原始路径不可用。恢复过程只读取独立快照，写入新文件，检查摘要，并解析业务数值。恢复金额必须仍为两千五百分。最后一个标记再次确认实验仍在同一文件系统中。完成后临时文件会清理，不修改真实备份保留策略，也不把路径改名当成物理机房真的发生故障。

把规则落实为恢复设计

盘点工作副本和两份备份时，应记录设备或服务、实际位置、谁有删除权限、保留哪些版本，以及恢复依赖什么。传统的两类介质用于降低共同设备和格式故障；现代部署仍然需要有意义的独立性，单纯给云资源或文件夹起不同名字并不能建立这种独立性。应说明每一条分隔究竟准备抵抗哪一种单点故障。

根据实际威胁模型，保留合适的离线副本或受到修改保护的副本。通过加密保护机密性，同时安排故障时仍能取得必要密钥的恢复路径，避免全部依赖已经损坏的生产环境。还要验证值班人员在真正的事件条件下，能够使用当时可获得的权限和工具取回正确版本，而不是仅在平时管理员全部在线时才恢复得出来。

从每个准备承担恢复职责的来源实际演练，记录业务状态、数据年龄以及恢复到可用状态所需的时间。较新的本地副本可以提供快速恢复，较旧的远端副本可能覆盖更大的故障，但两者承诺的数据恢复位置不同。三二一最终应形成一组具备已知边界、可以独立使用的恢复路径，并由演练支持，而不是只形成一张文件数量已经达标的表格。

来源

Backblaze 三二一备份策略，经典副本、介质、位置规则及现代设备解释，已核验 2026-09-12。
CISA 勒索软件防护指南，离线加密备份、恢复依赖和定期恢复演练，已核验 2026-09-12。

备份 · XB 现场笔记

pg_dump 拍一张一致的快照

理解快照覆盖什么

计算负载和依赖

坏掉的样子

快速验证

来源

Postgres WAL 归档实现时间点恢复

坏掉的样子

快速验证

接受恢复结果之前先核对

延伸阅读

来源

没验证的备份只是空想

坏掉的样子

快速验证

留下能支持决策的恢复结果

延伸阅读

来源

桶版本化与生命周期管理成本

分清版本化状态

删除标记改变可见性

生命周期表达的是保留取舍

坏掉的样子

快速验证

来源

WAL 归档保留可恢复的历史

坏掉的样子

快速验证

保留一个真正可恢复的区间

延伸阅读

来源

全量与增量备份

坏掉的样子

快速验证

核算恢复成本，不只看备份速度

延伸阅读

来源

备份遵循 3-2-1 原则

坏掉的样子

快速验证

把规则落实为恢复设计

延伸阅读

来源