RHEL 8.10 FreeIPA（IdM）双节点高可用、离线备份与灾难恢复方案（审校版）

文档状态：可执行参考稿，需在测试环境完成演练并通过变更审批后用于生产
审校日期：2026-08-22 适用范围：RHEL 8.10，使用 Red Hat 官方 IdM/FreeIPA RPM，集成 DNS 与集成 CA，两个 IdM 节点
不直接覆盖：外部 CA、HSM、KRA、AD Trust、多站点复杂拓扑、FIPS 差异、容器化 FreeIPA、IdM DNSSEC zone signing 的 key master 迁移/恢复
术语说明：在 RHEL 文档中产品名称为 Identity Management（IdM）；其上游项目为 FreeIPA。本文两者按上下文等价使用。

1. 审校结论

原方案的总体方向——“部署两个可写 Replica，并为身份系统建立离线备份”——是正确的，但原文不能直接用于生产执行。其中有多处 P0 级错误会导致命令失败、备份不可识别、恢复路径错误，或使第二台服务器不具备 CA 高可用能力。

必须纠正的核心结论如下：

双节点不是传统主从，也不是 VIP 集群。 两个 IdM 服务器都可读写，客户端主要通过 DNS SRV 记录和 SSSD 服务发现进行故障转移；只有已安装到该节点的服务角色才能由该节点提供。
第二台 Replica 必须显式使用 --setup-ca。 仅使用 --setup-dns 不会在第二台安装 CA；没有第二个 CA 时，证书签发、CA 数据保护及 CA 故障恢复均不完整。
完整备份命令是 ipa-backup，不是 ipa-backup create。 默认输出是 /var/lib/ipa/backup/ipa-full-.../ 目录，而不是 .ipabackup 文件。
恢复命令是 ipa-restore <备份目录>，不是 ipa-backup restore --archive=...。
单节点损坏时优先从健康 Replica 重建故障节点，通常不执行 ipa-restore。 ipa-restore 适用于全域数据丢失、必须回退到历史时点，或无法通过复制重建的灾难场景。
完整恢复必须回到备份对应的服务器身份，并匹配相同 IdM 软件版本。 不能按“相同或更新版本”处理，更不能把 RHEL 8 备份直接恢复到 RHEL 9。
完整恢复后，恢复节点成为唯一数据源；其他 Replica 必须按复制拓扑重新初始化或重建。 不能让旧 Replica 直接上线继续复制。
服务状态使用 ipactl status，整体启停使用 systemctl start|stop|restart ipa。 ipa-healthcheck 没有 run 子命令。
现代 RHEL 8 / Domain Level 1 拓扑移除服务器使用 ipa server-del。 ipa-server-install -U 不是卸载命令；卸载应使用 ipa-server-install --uninstall。
RHEL 8 安装集成 DNS 的推荐方式是 IdM 模块的 idm:DL1/dns profile。 不建议仅凭 dnf install ipa-server 推定所需组件完整。

依据：RHEL8-HA、RHEL8-REPLICA、RHEL8-BACKUP、RHEL8-DR、MAN-IPA-BACKUP、MAN-IPA-RESTORE

2. 原方案关键问题清单

级别	原方案内容	审校结论	可能后果
P0	`ipa-backup create`	应为 `ipa-backup`	命令失败
P0	`ipa-backup create --destination=...`	官方命令未提供该工作流；默认写入 `/var/lib/ipa/backup/`	命令失败或误判备份位置
P0	备份为单个 `*.ipabackup`	实际为 `ipa-full-` 或 `ipa-data-` 目录，内含 `header` 和归档文件	校验、复制与恢复均错误
P0	`ipa-backup restore --archive=...`	应为 `ipa-restore <备份目录>`	恢复命令失败
P0	新 RHEL 安装 RPM 后直接恢复，无需先同构安装	完整恢复前必须安装/重装为相同服务器配置	恢复前置条件不满足
P0	备份可恢复到相同或更高版本	必须匹配备份对应的 IdM 版本；不支持降级，也不能任意跨版本	恢复拒绝或系统不一致
P0	第二台 Replica 未使用 `--setup-ca`	必须显式 `--setup-ca` 才能复制 CA 配置	第二台没有 CA，证书服务不高可用
P0	单节点丢失后从备份恢复	健康 Replica 存在时，应删除故障节点并重建 Replica	不必要的全域回滚和复制重初始化
P0	恢复后只需重装第二台 Replica	现存其他 Replica 均须从恢复节点重新初始化，离线节点通常应重建	旧数据覆盖恢复数据、产生分叉
P0	`ipa-server-install -U` 表示卸载	应为 `ipa-server-install --uninstall`	非预期安装/命令失败
P1	`ipa-healthcheck run -v`	应直接运行 `ipa-healthcheck`；复制专项使用 `--source=...`	健康检查无法执行
P1	`ipa-server-install --status`	使用 `ipactl status`	状态检查失败
P1	`ipaconfigdir-show`	非标准 IdM 拓扑命令；使用 `ipa topologysuffix-find`、`ipa topologysegment-find` 等	排障命令失败
P1	`ipa-server-find`	正确 CLI 形式为 `ipa server-find`	命令失败
P1	`ipa-backup list`	官方标准工作流无该子命令；列出默认目录或由备份系统建索引	命令失败
P1	`ipa-replica-manage remove` 作为常规移除	RHEL 8 Domain Level 1 使用 `ipa server-del`	可能遗留 CA/域复制关系
P1	安装器自动开放全部防火墙端口	应显式配置 `freeipa-4` 和 `dns` firewalld service，并检查上游 ACL	节点间或客户端访问失败
P1	`_ldaps._tcp` 代替 `_ldap._tcp`	IdM 发现需要 `_ldap._tcp` 等 LDAP/Kerberos 记录	客户端发现失败
P1	`_ldap._tcp.dc._msdcs... TXT ipa-version=...`	不是标准 IdM 记录，带有 AD `_msdcs` 语义，应删除	DNS 污染、误导排障
P1	手写固定优先级/权重的完整 SRV 表	外部 DNS 应使用安装器生成文件或 `ipa dns-update-system-records` 导出	漏记录或记录不匹配
P1	`--forward-zone=example.com` 用于创建 IdM 主域	IdM 主 DNS zone 由 `--setup-dns` 创建；forward zone 是另一类 DNS 功能	DNS 设计错误
P1	`--ca-cert-dir=/root/ipa-certs` 用于普通集成 CA	普通集成 CA 安装不需要该参数；应以本机 `man ipa-server-install` 为准	安装参数无效
P1	`-U` 但没有提供所有必需口令参数	真正无人值守需要完整参数；长期口令不应直接出现在命令行	安装失败或泄露秘密
P1	精确列出备份一定包含的文件路径和 BDB 数据库	文件清单随版本变化，389-DS 后端也不应按固定实现推定	错误的手工恢复设计
P1	`ipa server-cert` 用于修复证书	没有该通用修复命令；不能据此处理冲突或证书故障	执行失败、扩大故障
P1	直接依赖 `pki-ca`、固定 `certutil` DB 路径	服务单元和 NSS DB 路径随版本/部署而变；优先 `ipactl`、Healthcheck、Dogtag 日志	错误诊断
P2	“任一节点故障，另一台自动承载全部服务”	仅当该角色已安装、DNS/SSSD 发现正确、客户端未固定服务器时成立	对高可用边界理解过度
P2	两台时间差必须 `<1 s` 才可工作	`<1 s` 是良好运维目标；Kerberos 常见默认最大时钟偏差为 5 分钟	把工程目标误写成协议硬限制
P2	RHEL 9 对应 FreeIPA 5.0	不应这样硬编码；以目标系统官方 RPM 为准，RHEL 8→9 应走 Replica 迁移	错误升级/恢复规划

3. 架构与高可用边界

3.1 推荐双节点角色

flowchart LR
    C[IdM 客户端 / 应用] --> D[DNS SRV / A / AAAA / PTR]
    D --> I1[ipa1.example.com]
    D --> I2[ipa2.example.com]

    I1 <-->|domain suffix 多写复制| I2
    I1 <-->|ca suffix 复制| I2

    subgraph IPA1[ipa1]
      L1[389-DS / LDAP]
      K1[KDC / kadmin]
      H1[HTTP / IPA API]
      N1[Integrated DNS]
      A1[Integrated CA]
    end

    subgraph IPA2[ipa2]
      L2[389-DS / LDAP]
      K2[KDC / kadmin]
      H2[HTTP / IPA API]
      N2[Integrated DNS]
      A2[Integrated CA]
    end

两台节点均安装：

Directory Server / LDAP；
Kerberos KDC 与管理服务；
IPA API / Web UI；
Integrated DNS；
Integrated CA。

3.2 复制对象的准确理解

用户、组、主机、服务、Kerberos principal 与密钥等核心目录数据通过 389-DS 的 domain suffix 多写复制。
KDC 读取本机已复制的目录数据；不应把它描述成独立的“KDC 数据库主从复制”。
CA 数据使用单独的 ca suffix 复制；因此仅有 LDAP Replica 不等于 CA Replica。
IdM DNS 记录存储在目录中并随相应数据复制，不应把它理解成传统静态 zone 文件主从复制。

3.3 高可用不是 VIP 集群

IdM 的默认高可用依赖：

DNS 中正确存在两个节点的服务记录；
客户端使用 SSSD _srv_ 服务发现；
Kerberos 配置允许通过 DNS 发现 KDC；
客户端 DNS 配置可以访问至少两个 IdM DNS 服务器；
两台节点都安装了客户端所依赖的角色；
应用没有把 LDAP、KDC、IPA API 或 Web URL 固定到单一主机。

以下情况不会“透明切换”：

用户浏览器固定访问 https://ipa1.example.com/ipa/，而 ipa1 故障；
应用只配置一个 LDAP URI；
/etc/sssd/sssd.conf 将 ipa_server 固定为单节点；
客户端只配置一个 DNS 服务器；
ipa2 未安装 CA，而客户端执行证书操作；
上游防火墙仅放行到 ipa1。

Red Hat 不建议在 IdM 前面随意加入第三方通用负载均衡器或 VIP 来替代原生发现机制，尤其是 Kerberos 场景。确需代理或负载均衡时，应单独完成协议级设计与厂商支持确认。

依据：RHEL8-HA、RHEL8-TOPOLOGY

3.4 两个需要单独管理的 CA 角色

即使两台都安装 CA，以下角色仍具有单值语义：

CA renewal server：负责 IdM CA 子系统证书续订协调；
CRL publisher：负责生成并发布证书吊销列表。

日常必须记录它们当前所在节点：

kinit admin
ipa config-show

# 在每个 CA 节点本地执行
ipa-crlgen-manage status

计划下线原节点时，应先迁移角色；CRL 生成同一时间只能在一个 CA 节点启用。

依据：RHEL8-CRL、RHEL8-DECOMMISSION

3.5 DNSSEC validation 与 DNSSEC zone signing 不是一回事

本文第 6.4.1 节检查的是递归解析链路上的 DNSSEC validation。它不等于由 IdM 对权威 zone 执行 DNSSEC zone signing。

若环境曾启用 IdM DNSSEC zone signing，应额外检查：

kinit admin
ipa dnsconfig-show | grep -i 'DNSSec key master' || true

出现 IPA DNSSec key master 时，表示拓扑中存在单值的 DNSSEC key master 角色。计划隐藏、下线或删除该节点前必须先迁移此角色；若该角色所在节点突然丢失，也不能直接套用本文的普通 DNS 节点删除步骤，应按匹配当前 RHEL 8.10 build 的官方 DNSSEC 恢复流程执行，并建议由 Red Hat 支持复核。本文其余步骤按“未启用 IdM DNSSEC zone signing”设计。

依据：RHEL8-DNSSEC-ROLE

4. 示例变量与部署假设

以下仅为示例。生产环境推荐使用独立、可委派的子域，例如 idm.corp.example.com，不要未经评审直接接管已有企业 DNS 根域。

export DOMAIN="example.com"
export DNS_ZONE="${DOMAIN}."
export REALM="EXAMPLE.COM"

export IPA1_FQDN="ipa1.example.com"
export IPA1_SHORT="ipa1"
export IPA1_IP="192.168.100.11"

export IPA2_FQDN="ipa2.example.com"
export IPA2_SHORT="ipa2"
export IPA2_IP="192.168.100.12"

export REVERSE_ZONE="100.168.192.in-addr.arpa."
export IPA1_PTR_LABEL="11"
export IPA2_PTR_LABEL="12"

# 使用企业内部递归 DNS，不要机械照抄公共 DNS
export DNS_FORWARDER_1="192.0.2.53"
export DNS_FORWARDER_2="192.0.2.54"

# 通过 firewall-cmd --get-active-zones 确认
export FIREWALL_ZONE="public"

本文主流程假设：

IdM 管理 example.com. 正向 zone；
IdM 管理 100.168.192.in-addr.arpa. 反向 zone；
企业上级 DNS 对 IdM zone 做标准 NS delegation；
两台服务器均为静态 IP；
两台均安装 CA 和 DNS；
不部署 KRA 与 AD Trust。

如果反向 zone 由外部 DNS 管理，则安装时改用 --no-reverse，并在外部 DNS 中维护 PTR。

5. 变更前 Go/No-Go 检查

在生产部署前，以下任何一项不满足都应暂停：

6. 两台主机的系统准备

6.1 使用干净 RHEL 8.10

优先使用新安装、未配置过 LDAP、Kerberos、Dogtag PKI 或 BIND 的 RHEL 8.10。

cat /etc/redhat-release
cat /etc/os-release
uname -r

free -h
swapon --show
df -hT
df -i

Red Hat 给出的典型内存参考是：约 10,000 用户、100 个组时至少 4 GB RAM 与 4 GB swap；约 100,000 用户、50,000 个组时至少 16 GB RAM 与 4 GB swap。该数值不是所有业务的通用容量结论，还要按主机/服务条目、证书、DNS、查询并发、日志和本地备份空间评估。虚拟机应避免内存 ballooning，或为 IdM guest 完整预留内存。

不要在灾备恢复主机上无条件执行 dnf update -y。完整恢复要求匹配备份对应的 IdM 版本，应使用保留的仓库快照、Satellite Content View 或内部镜像。

新部署可按企业补丁基线更新，但应先预览、审批并安排必要的重启：

dnf check-update || rc=$?
# dnf check-update 返回 100 表示存在更新，并非命令故障

6.2 主机名

在 ipa1：

hostnamectl set-hostname "$IPA1_FQDN"
hostname -f

在 ipa2：

hostnamectl set-hostname "$IPA2_FQDN"
hostname -f

要求：

永久 FQDN；
建议全部小写；
不能解析到 loopback；
安装后不要修改 IdM 服务器主机名。

6.3 `/etc/hosts`

/etc/hosts 可作为安装引导补充，但不能替代生产 DNS。保留标准 loopback 条目，并确保 IdM FQDN 不映射到 127.0.0.1 或 ::1。

示例：

0.0.1   localhost localhost.localdomain
::1         localhost localhost.localdomain

168.100.11  ipa1.example.com ipa1
168.100.12  ipa2.example.com ipa2

6.4 DNS 正反向验证

在部署前从两台服务器和至少一台客户端网段主机检查：

dig +short A "$IPA1_FQDN"
dig +short -x "$IPA1_IP"

dig +short A "$IPA2_FQDN"
dig +short -x "$IPA2_IP"

getent hosts "$IPA1_FQDN"
getent hosts "$IPA2_FQDN"

预期：

ipa1.example.com -> 192.168.100.11；
192.168.100.11 -> ipa1.example.com；
ipa2.example.com -> 192.168.100.12；
192.168.100.12 -> ipa2.example.com；
不存在错误 CNAME 链、loopback 地址或多个互相矛盾的 PTR。

6.4.1 DNS forwarder 能力验证

Integrated DNS 安装前，对每个企业 forwarder 验证 EDNS0、递归和 DNSSEC 能力：

for forwarder in "$DNS_FORWARDER_1" "$DNS_FORWARDER_2"; do
  echo "=== $forwarder: EDNS/recursion ==="
  dig @"$forwarder" . SOA

  echo "=== $forwarder: DNSSEC ==="
  dig +dnssec @"$forwarder" . SOA
done

至少确认普通查询为 NOERROR、包含递归可用标志，并能处理 EDNS。默认保留 IdM DNSSEC validation 时，还应看到 DNSSEC do 语义及有效的 RRSIG 响应。若企业 forwarder 确实不支持 DNSSEC，应先完成安全评审，再在 ipa1 和所有 DNS Replica 的安装参数中一致加入 --no-dnssec-validation；不要把该参数当作通用排障开关。

6.5 时间同步

dnf install -y chrony
systemctl enable --now chronyd

chronyc tracking
chronyc sources -v
timedatectl status

建议把偏差控制在 1 秒以内。Kerberos 常见默认最大时钟偏差为 5 分钟，但不能把 5 分钟当作正常运行目标。

本文假设两台主机的 chronyd 已由企业配置管理并验证同步，因此后续 ipa-server-install、ipa-client-install 和 ipa-replica-install 示例显式加入 --no-ntp，避免安装器改写现有时间源。只有在 chronyc tracking 已显示同步正常时才可这样做。若决定由 IdM 安装器配置时间同步，应删除 --no-ntp，并使用重复的 --ntp-server=<FQDN> 或 --ntp-pool=<FQDN> 明确指定批准的时间源；不要依赖未经验证的自动发现。

依据：RHEL8-PREPARE

6.6 IPv6 loopback 与 SELinux

IdM 依赖 IPv6 协议栈和 ::1 loopback，即使业务网络只使用 IPv4，也不要全局禁用 IPv6。

sysctl net.ipv6.conf.all.disable_ipv6
ping -6 -c 1 ::1

getenforce

预期：

net.ipv6.conf.all.disable_ipv6 = 0；
::1 可达；
SELinux 为 Enforcing。

不要以关闭 SELinux 作为安装或排障步骤。发生拒绝时应检查 AVC 日志并修正根因。

6.7 root umask

安装前确认 root 的 umask 为 0022：

umask
umask 0022

6.8 安装 RHEL 8 IdM 模块

集成 DNS 使用 idm:DL1/dns profile。以下流程适用于新安装、尚未启用其他 IdM module stream 的 RHEL 8.10：

dnf module list idm
dnf module enable -y idm:DL1
dnf distro-sync -y
dnf module install -y idm:DL1/dns

dnf install -y ipa-healthcheck bind-utils openldap-clients nmap-ncat firewalld

dnf distro-sync 应只对已经过变更审批的 RHEL 8.10 BaseOS/AppStream 仓库或 Satellite Content View 执行。若主机此前已启用其他 IdM stream，或已经安装了来自其他 stream 的 IdM 包，不要直接强制切换；Red Hat 要求先按 module stream 切换流程清理相关内容并禁用原 stream。生产上优先使用干净系统，避免混装 RPM。

若系统启用了 fapolicyd，安装前先确认其策略不会拦截 IdM 软件包与运行文件：

systemctl is-active fapolicyd || true

不要为绕过安装问题长期关闭 fapolicyd；应按与本机 RHEL 8.10 文档和企业白名单策略相符的方式修正规则，并在安装后复测。

安装后记录实际版本：

ipa --version || true
rpm -q ipa-server ipa-server-dns 389-ds-base pki-ca ipa-healthcheck
dnf module list idm --enabled

本文不硬编码具体 4.9.x patch level。RHEL 8.10 的实际 IdM build 受启用仓库和 errata 影响，恢复时必须以备份 header、RPM 清单和本机 man 页为准。

6.9 firewalld

先识别活动 zone：

systemctl enable --now firewalld
firewall-cmd --get-active-zones

在实际接口所属 zone 上开放 IdM 与 DNS 服务：

firewall-cmd --permanent --zone="$FIREWALL_ZONE" --add-service=freeipa-4
firewall-cmd --permanent --zone="$FIREWALL_ZONE" --add-service=dns
firewall-cmd --reload

firewall-cmd --zone="$FIREWALL_ZONE" --list-services

对应主要端口：

TCP：80、443、389、636、88、464；
UDP：88、464；
DNS：53/TCP、53/UDP。

还必须检查交换网络、防火墙、安全组和跨网段 ACL。仅开放本机 firewalld 不代表端到端可达。

从客户端网段验证：

nc -vz "$IPA1_FQDN" 443
nc -vz "$IPA1_FQDN" 389
nc -vz "$IPA1_FQDN" 88

UDP 端口不能仅靠 nc -u 的返回码证明服务可用，应通过实际 kinit 和 dig 验证 Kerberos/DNS UDP 业务。

官方 Replica 安装连接表列出了对源 IdM 服务器的 TCP 22 连通性检查，并说明安装服务器或 Replica 时可能发生 TCP 8443 的 CA 管理访问；但 RHEL 系统准备文档同时要求将 8080/8443 作为 pki-tomcat 内部端口保持阻断。标准方案只开放 freeipa-4 和 dns 服务，不预先向客户端网段或 IdM 节点网段开放 8080/8443。若安装日志明确显示 8443 的远端连接被网络设备阻断，应先核对目标环境实际 RPM 对应的本机 man page 与当前官方文档；确需例外时，建议经 Red Hat 支持确认后，仅对指定源/目的 IdM 节点做限时最小放行，安装完成立即撤销并复测。

还要确认出站路径：

两台 IdM DNS 到企业 DNS forwarder 的 53/TCP、53/UDP；
两台服务器到批准的 chrony/NTP 源；
Replica 安装节点到源 IdM 服务器的 DNS、Kerberos、HTTPS、LDAP，以及上述安装期连接。

依据：RHEL8-PREPARE、RHEL8-FIREWALL、RHEL8-MODULE、RHEL8-REPLICA

7. DNS 设计与记录

7.1 推荐使用标准 delegation

若企业 DNS 管理 corp.example.com，推荐把 idm.corp.example.com 委派给：

ipa1.idm.corp.example.com
ipa2.idm.corp.example.com

父域中应存在对应 NS 记录及必要 glue A/AAAA 记录。不要用 forward zone 代替可正常实现的标准 DNS delegation。

实施顺序必须避免形成 lame delegation：安装前先准备服务器 A/AAAA、PTR、glue 和父域变更单，但通常应在 ipa1 的 DNS 服务安装成功、能够直接权威回答该 zone 后，再把父域 delegation 正式指向 ipa1；ipa2 安装并验收后，再把 ipa2 加入同一 NS RRset。不要在两台 DNS 都未运行时提前切走生产解析。

若反向 zone 也由 IdM 管理，例如 100.168.192.in-addr.arpa.，其父反向 zone 同样必须按上述顺序委派给两台 IdM DNS。若企业反向 DNS 无法实施 delegation，则安装时使用 --no-reverse，PTR 记录由外部 DNS 维护，不要形成两个权威源。

由 DNS 管理员替换下面的父 DNS 地址后进行验证：

# 正向父域应返回 ipa1/ipa2 两个权威 NS
# dig @<PARENT_FORWARD_DNS_IP> "$DNS_ZONE" NS

# 反向父域应返回 ipa1/ipa2 两个权威 NS
# dig @<PARENT_REVERSE_DNS_IP> "$REVERSE_ZONE" NS

以上命令中的 <...> 是占位符，不能原样复制执行。

7.2 外部 DNS 场景不要手工猜 SRV 表

外部 DNS 模式下，安装器会生成类似：

/tmp/ipa.system.records.<random>.db

也可在安装后导出：

kinit admin
ipa dns-update-system-records \
  --dry-run \
  --out /root/ipa-system-records.nsupdate

按导出文件同步外部 DNS。典型记录族包括：

_ldap._tcp;
_kerberos._tcp;
_kerberos._udp;
_kerberos-master._tcp;
_kerberos-master._udp;
_kpasswd._tcp;
_kpasswd._udp;
Kerberos Realm TXT 记录。

不要使用原方案中的 _ldap._tcp.dc._msdcs... 记录；_msdcs 属于 Active Directory DNS 命名语义。也不要用 _ldaps._tcp 替代必需的 _ldap._tcp。

7.3 Integrated DNS 场景

安装器会创建并维护 IdM 服务记录，但父域 delegation 仍需由企业 DNS 管理员完成。推荐顺序为：

ipa1 安装完成后，先用 dig @"$IPA1_IP" ... 直接验证正向/反向 zone；
将父域正向及反向 delegation 指向 ipa1；
ipa2 安装完成并直接查询通过后，把 ipa2 加入父域 NS/glue；
从客户端网段分别查询父 DNS、ipa1、ipa2，确认委派链和权威答案一致。

第二台 DNS Replica 安装后，父域 NS 记录应同时列出两个节点。

依据：RHEL8-DNS-RECORDS、RHEL8-DNS-FORWARDING

8. 安装第一台 IdM 服务器 ipa1

8.1 推荐交互式安装

普通集成 CA 不需要 --ca-cert-dir；IdM 主 zone 也不需要 --forward-zone。

如果正向和反向 zone 均由 IdM 管理：

ipa-server-install \
  --hostname="$IPA1_FQDN" \
  --ip-address="$IPA1_IP" \
  --domain="$DOMAIN" \
  --realm="$REALM" \
  --setup-dns \
  --forwarder="$DNS_FORWARDER_1" \
  --forwarder="$DNS_FORWARDER_2" \
  --reverse-zone="$REVERSE_ZONE" \
  --no-ntp

如果反向 zone 由外部 DNS 管理：

ipa-server-install \
  --hostname="$IPA1_FQDN" \
  --ip-address="$IPA1_IP" \
  --domain="$DOMAIN" \
  --realm="$REALM" \
  --setup-dns \
  --forwarder="$DNS_FORWARDER_1" \
  --forwarder="$DNS_FORWARDER_2" \
  --no-reverse \
  --no-ntp

交互过程中分别设置并安全保存：

Directory Manager 密码；
IdM admin 密码。

两者用途不同。灾难恢复会用到 Directory Manager 密码，不能只保留 admin 密码。

8.2 不推荐直接把长期密码写入命令行

-U / --unattended 不是“自动回答所有口令”的魔法参数。无人值守安装必须提供完整参数，但将长期密码放在 shell history、进程参数或流水线日志中存在泄露风险。

自动化场景应使用：

Ansible Vault；
企业秘密管理系统；
受控的 ansible-freeipa；
临时凭据或受限执行环境。

在采用自动化前，先以本机版本验证：

man ipa-server-install
ipa-server-install --help

8.3 ipa1 安装后验证

ipactl status
systemctl status ipa --no-pager

kinit admin
klist
ipa ping
ipa server-show "$IPA1_FQDN"
ipa config-show

ipa-healthcheck --failures-only
ipa-healthcheck \
  --source=ipahealthcheck.ds.replication \
  --source=ipahealthcheck.ipa.topology

不要只依赖 ipa-healthcheck 进程退出码；应检查输出中的 WARNING、ERROR 和 CRITICAL。

DNS 验证：

dig @"$IPA1_IP" "$DNS_ZONE" SOA +short
dig @"$IPA1_IP" "$DNS_ZONE" NS +short
dig @"$IPA1_IP" "_ldap._tcp.${DNS_ZONE}" SRV +short
dig @"$IPA1_IP" "_kerberos._udp.${DNS_ZONE}" SRV +short

服务控制原则：

# 整体状态
ipactl status

# 整体启停
systemctl start ipa
systemctl stop ipa
systemctl restart ipa

不要使用 ipactl start|stop|restart 替代 systemctl ... ipa 作为标准运维方式。

依据：RHEL8-SERVICE、RHEL8-HEALTHCHECK

9. 安装第二台 Replica ipa2

9.1 先确保 ipa2 的 DNS 记录存在

如果 IdM 管理正反向 zone，可在 ipa1 上创建记录：

kinit admin

ipa dnsrecord-add "$DNS_ZONE" "$IPA2_SHORT" \
  --a-rec="$IPA2_IP"

ipa dnsrecord-add "$REVERSE_ZONE" "$IPA2_PTR_LABEL" \
  --ptr-rec="${IPA2_FQDN}."

验证：

dig @"$IPA1_IP" +short A "$IPA2_FQDN"
dig @"$IPA1_IP" +short -x "$IPA2_IP"

如果 zone 由外部 DNS 管理，应由外部 DNS 管理员创建同等 A/AAAA/PTR 记录。

9.2 ipa2 的 resolver 必须能发现 ipa1

通过 NetworkManager、DHCP 或企业网络配置流程，让 ipa2 使用可解析 IdM 域的 DNS。不要长期直接覆盖由 NetworkManager 管理的 /etc/resolv.conf。

验证：

cat /etc/resolv.conf
dig +short A "$IPA1_FQDN"
dig +short -t SRV "_ldap._tcp.${DNS_ZONE}"
dig +short -t SRV "_kerberos._udp.${DNS_ZONE}"

9.3 推荐先加入为 IdM client，再提升为 Replica

这样可以在 ipa2 上获取 Kerberos TGT，避免把长期管理员密码写入 Replica 安装命令参数。

在 ipa2：

ipa-client-install \
  --server="$IPA1_FQDN" \
  --domain="$DOMAIN" \
  --realm="$REALM" \
  --no-ntp

按提示提供有权限的 IdM 管理员凭据。此处显式指定 --server="$IPA1_FQDN"，仅用于让待提升为 Replica 的 ipa2 确定性地向 ipa1 完成 enrollment；普通 IdM 客户端应优先使用 DNS SRV 服务发现，不应照抄为单节点固定配置。然后：

kinit admin
klist

9.4 安装 DNS + CA Replica

在 ipa2：

ipa-replica-install \
  --server="$IPA1_FQDN" \
  --ip-address="$IPA2_IP" \
  --setup-dns \
  --setup-ca \
  --forwarder="$DNS_FORWARDER_1" \
  --forwarder="$DNS_FORWARDER_2" \
  --no-reverse \
  --no-ntp

说明：

--setup-ca 是双 CA 的关键参数；
--setup-dns 安装本地 DNS 服务；
--ip-address 将安装绑定到前置检查过的静态地址，尤其适用于多网卡主机；
--no-ntp 表示保留第 6.5 节已验证的企业 chrony 配置；
已有反向 zone 会通过目录复制同步，--no-reverse 用于避免再次创建新反向 zone；
一次只安装一个 Replica，不要并行启动多个 Replica 安装；
第一台使用集成 CA 时，第二台 CA 配置必须与其一致。

安装完成后，如使用父域 delegation，向父 DNS 增加 ipa2 对应的 NS/glue 记录。

依据：RHEL8-REPLICA

9.5 Replica 安装失败的清理

先检查：

tail -n 200 /var/log/ipareplica-install.log
tail -n 200 /var/log/ipareplica-ca-install.log 2>/dev/null || true
journalctl -u ipa --since "-30 min"

对部分安装节点执行：

ipa-server-install --uninstall

在健康服务器上检查是否已创建拓扑对象：

kinit admin
ipa server-show "$IPA2_FQDN"

如果确已加入且需要移除：

ipa server-del "$IPA2_FQDN"

修复根因后再重新安装。不要在脏状态上反复执行 ipa-replica-install。

依据：RHEL8-REPLICA-TROUBLESHOOT

10. 双节点验收

10.1 组件状态

两台分别执行：

ipactl status
systemctl is-active ipa
ipa-healthcheck --failures-only

预期所有已安装组件运行，Healthcheck 无未处理的严重项。

10.2 服务器与角色

任一节点：

kinit admin

ipa server-find
ipa server-show "$IPA1_FQDN"
ipa server-show "$IPA2_FQDN"

ipa server-role-find --role="CA server"
ipa server-role-find --role="DNS server"

ipa config-show

验收要点：

两台均为 DNS server；
两台均为 CA server；
ipa config-show 中能看到 CA server 列表；
明确记录 CA renewal server；
两台都能正常响应 IPA API。

10.3 复制拓扑

ipa topologysuffix-find
ipa topologysegment-find domain
ipa topologysegment-find ca

ipa-healthcheck \
  --source=ipahealthcheck.ds.replication \
  --source=ipahealthcheck.ipa.topology

双节点应同时存在：

domain suffix 连接；
ca suffix 连接。

10.4 直接访问每个 IPA API

--force-server 用于直接测试指定服务器，不执行客户端故障转移：

ipa --force-server "$IPA1_FQDN" ping
ipa --force-server "$IPA2_FQDN" ping

10.5 双向写入、删除复制与 DNA 范围测试

只从 ipa1 创建对象不能证明 ipa2 具备本地分配 UID/GID 的能力。Replica 通常在第一次本地创建用户或组时才申请 DNA ID 范围，因此两台都应执行一次本地写入。

以下测试放在临时 Bash 子 shell 中执行；任何一步超时都会返回非零状态：

(
  set -euo pipefail

  PROBE_USER_1="ha1-$(date +%Y%m%d%H%M%S)"
  sleep 1
  PROBE_USER_2="ha2-$(date +%Y%m%d%H%M%S)"

  wait_user_present() {
    local server="$1"
    local user="$2"

    for _ in $(seq 1 30); do
      if ipa --force-server "$server" user-show "$user" >/dev/null 2>&1; then
        return 0
      fi
      sleep 2
    done

    echo "ERROR: user $user was not replicated to $server within 60 seconds" >&2
    return 1
  }

  wait_user_absent() {
    local server="$1"
    local user="$2"

    for _ in $(seq 1 30); do
      if ! ipa --force-server "$server" user-show "$user" >/dev/null 2>&1; then
        return 0
      fi
      sleep 2
    done

    echo "ERROR: deletion of $user was not replicated to $server within 60 seconds" >&2
    return 1
  }

  # 在 ipa1 本地分配 UID/GID，并确认复制到 ipa2
  ipa --force-server "$IPA1_FQDN" user-add "$PROBE_USER_1" \
    --first="HA1" \
    --last="Probe"
  wait_user_present "$IPA2_FQDN" "$PROBE_USER_1"

  # 在 ipa2 本地分配 UID/GID，并确认复制到 ipa1
  ipa --force-server "$IPA2_FQDN" user-add "$PROBE_USER_2" \
    --first="HA2" \
    --last="Probe"
  wait_user_present "$IPA1_FQDN" "$PROBE_USER_2"

  echo "=== Current DNA ranges ==="
  ipa-replica-manage dnarange-show
  ipa-replica-manage dnanextrange-show

  # 从对端删除，并确认删除复制回源端
  ipa --force-server "$IPA2_FQDN" user-del "$PROBE_USER_1"
  wait_user_absent "$IPA1_FQDN" "$PROBE_USER_1"

  ipa --force-server "$IPA1_FQDN" user-del "$PROBE_USER_2"
  wait_user_absent "$IPA2_FQDN" "$PROBE_USER_2"

  echo "Bidirectional domain replication and deletion tests succeeded"
)

验收时，ipa-replica-manage dnarange-show 应显示两台均有当前范围。若任一节点为 No range set，不要把双节点灾备判定为通过；先解决 DNA 范围分配问题。

依据：RHEL8-DNA、RHEL8-UNINSTALL

10.6 两台 DNS 的直接查询

for dns_ip in "$IPA1_IP" "$IPA2_IP"; do
  echo "=== DNS $dns_ip ==="
  dig @"$dns_ip" "$DNS_ZONE" SOA +short
  dig @"$dns_ip" "_ldap._tcp.${DNS_ZONE}" SRV +short
  dig @"$dns_ip" "_kerberos._udp.${DNS_ZONE}" SRV +short
done

SRV 记录应包含两个节点。

10.7 CA 与 CRL

ipa server-role-find --role="CA server"
ipa config-show

# 查询内置 CA 证书条目，确认 CA 数据可由 IPA API 读取
ipa cert-show 1

在两台本地分别执行：

ipa-crlgen-manage status
getcert list

预期：

两台均有 CA；
同一时间仅一个节点启用 CRL generation；
CA renewal server 明确且可用。

10.8 客户端发现配置

在测试客户端先确认排障工具存在：

dnf install -y sssd-tools bind-utils

然后检查：

sssctl config-check
grep -E '^[[:space:]]*ipa_server[[:space:]]*=' /etc/sssd/sssd.conf
dig +short -t SRV "_ldap._tcp.${DNS_ZONE}"
dig +short -t SRV "_kerberos._udp.${DNS_ZONE}"

推荐 ipa_server = _srv_，或不显式固定服务器、由安装器生成服务发现配置。

10.9 故障切换演练

先确认客户端 DNS 中存在两个可用 resolver，并清除旧 Kerberos ticket。为避免 id admin 命中 SSSD 缓存，预先在 ipa2 创建一个该客户端从未查询过的临时用户，并记录其名称：

FAILOVER_USER="fo-$(date +%Y%m%d%H%M%S)"

ipa --force-server "$IPA2_FQDN" user-add "$FAILOVER_USER" \
  --first="Failover" \
  --last="Probe"

echo "$FAILOVER_USER"

在测试客户端输入上一步输出的用户名并清除 Kerberos ticket：

read -r -p "请输入上一步输出的故障切换临时用户名: " FAILOVER_USER
export FAILOVER_USER
test -n "$FAILOVER_USER"
kdestroy -A

在 ipa1：

systemctl stop ipa

在客户端验证 Kerberos 与 SSSD 故障转移：

KRB5_TRACE=/dev/stderr kinit admin
klist

getent passwd "$FAILOVER_USER"
sssctl domain-list
sssctl domain-status "$DOMAIN" --active-server

dig +short -t SRV "_ldap._tcp.${DNS_ZONE}"
dig +short -t SRV "_kerberos._udp.${DNS_ZONE}"

kinit 必须现场向可用 KDC 取票；未在客户端查询过的临时用户用于降低 SSSD 正缓存造成的误判。

直接验证两个 IPA API 端点：

ipa --force-server "$IPA1_FQDN" ping   # 预期失败
ipa --force-server "$IPA2_FQDN" ping   # 预期成功

不要仅用未指定服务器的 ipa ping 证明自动故障转移，因为 IPA CLI 的服务器选择还受 /etc/ipa/default.conf 与命令行配置影响；本节把 SSSD/Kerberos 故障转移和 IPA API 端点可用性分开验收。

恢复 ipa1：

systemctl start ipa
ipactl status

ipa-healthcheck \
  --source=ipahealthcheck.ds.replication \
  --source=ipahealthcheck.ipa.topology

确认复制恢复后删除临时用户：

ipa --force-server "$IPA2_FQDN" user-del "$FAILOVER_USER"

注意：

首次失败转移可能受到 DNS 缓存、SSSD 超时和应用重试策略影响，不应宣称“零延迟”；
固定到 ipa1 的 Web URL 不会自动重定向到 ipa2；
验收应记录实际切换耗时。

11. 日常运维标准命令

11.1 状态与健康

ipactl status
systemctl status ipa --no-pager

ipa-healthcheck --failures-only
ipa-healthcheck \
  --source=ipahealthcheck.ds.replication \
  --source=ipahealthcheck.ipa.topology

ipa server-find
ipa topologysuffix-find
ipa topologysegment-find domain
ipa topologysegment-find ca
ipa-replica-manage dnarange-show
ipa-replica-manage dnanextrange-show

11.2 服务启停

systemctl start ipa
systemctl stop ipa
systemctl restart ipa

11.3 DNS 与发现

ipa dnsconfig-show
ipa dns-update-system-records --dry-run \
  --out /root/ipa-system-records.nsupdate

dig +short -t SRV "_ldap._tcp.${DNS_ZONE}"
dig +short -t SRV "_kerberos._udp.${DNS_ZONE}"

11.4 CA 角色

ipa config-show
ipa server-role-find --role="CA server"

# 每个 CA 节点本地
ipa-crlgen-manage status

11.5 升级原则

先完成全角色节点的可恢复备份；
保存当前 RPM、模块、角色和拓扑清单；
一次升级一个节点；
升级后验证服务、证书、复制与客户端认证；
确认复制稳定后再升级下一节点；
不要把 ipa-server-upgrade 当作每次更新后的常规手工命令。

正常软件包更新会触发相应 IdM 配置升级。只有自动升级失败、已修复根因且日志明确要求时，才在 Red Hat 文档或支持指导下手工运行 ipa-server-upgrade。

RHEL 8 到 RHEL 9 不应通过原地升级或跨版本 ipa-restore 完成；应按官方流程加入 RHEL 9 Replica，迁移角色和拓扑，再退役 RHEL 8 节点。

依据：RHEL8-SERVICE、RHEL8-TOPOLOGY、RHEL9-MIGRATION

12. 备份设计

12.1 备份不能替代复制

Replica 用于节点级高可用和快速重建；
ipa-backup 用于灾难恢复和历史时点回退；
Red Hat 文档指出，因 ipa-restore 对 RPM 版本匹配要求严格，受控 VM 快照可作为重要恢复手段；但快照回退仍必须 fencing 其他 Replica，并按复制拓扑重新初始化，不能把任意 crash-consistent 存储快照当作已验证的 IdM 备份；
两节点是最低可用结构。成熟生产环境建议增加一个安装所有角色的 hidden Replica，专门用于备份和灾备。

12.2 选择备份节点

备份节点必须包含部署中使用的全部关键角色，至少包括：

CA；
DNS；
如启用 KRA，则必须包含 KRA；
如有其他特殊角色，也应纳入恢复设计。

运行：

kinit admin
ipa server-show "$IPA1_FQDN"
ipa server-role-find --role="CA server"
ipa server-role-find --role="DNS server"
ipa config-show

不要用 ipa-backup --disable-role-check 绕过角色不完整警告来制作“全域灾备备份”。

12.3 GPG2 前置准备

ipa-backup --gpg 要求 root 的 GPG2 keyring 中存在可用于加密的指定密钥；灾难恢复还必须保留对应私钥。首次使用前至少完成：

dnf install -y gnupg2 pinentry

# 推荐使用仅供 IdM 备份的独立 root keyring
export GNUPGHOME="/root/ipa-backup-gnupg"
install -d -m 0700 "$GNUPGHOME"

printf '%s\n' 'pinentry-program /usr/bin/pinentry-curses' \
  > "$GNUPGHOME/gpg-agent.conf"
chmod 0600 "$GNUPGHOME/gpg-agent.conf"
gpgconf --kill gpg-agent

# 交互式创建，算法、长度、有效期和 passphrase 按企业密码策略选择
gpg2 --full-generate-key

# 确认专用 keyring 中存在私钥
gpg2 --list-secret-keys --keyid-format LONG

若企业标准要求使用默认 root keyring，可改为 /root/.gnupg，但备份、验证和恢复三处必须始终使用同一个 GNUPGHOME。

要求：

把 GNUPGHOME、私钥恢复材料和 passphrase 纳入企业密钥托管；
私钥恢复材料与 IdM 备份至少保留一个隔离副本，避免单介质同时丢失；
在隔离恢复主机上测试导入/恢复 keyring 后能够解密；
使用自定义 GNUPGHOME 时，执行 ipa-backup、手工解密验证和 ipa-restore 前必须设置相同环境变量；
生产上建议使用专用 GNUPGHOME，只保留明确指定的备份密钥，避免依赖多密钥 keyring 中未经验证的 recipient 选择行为；
ipa-backup 不提供对称 passphrase 或把私钥 passphrase 写入命令行的标准选项；创建加密备份通常使用公钥，不需要私钥 passphrase，但恢复/解密会通过 GPG agent/pinentry 请求私钥 passphrase，不能把它明文写入脚本。

依据：RHEL8-BACKUP、MAN-IPA-BACKUP

12.4 备份类型

目标	命令	服务影响	能否作为完整服务器灾备
完整服务器离线备份	`ipa-backup`	停止并自动恢复本节点 IdM 服务	是
GPG 加密完整备份	`ipa-backup --gpg`	同上	是
离线数据备份	`ipa-backup --data`	停止并自动恢复本节点服务	仅数据恢复
在线数据备份	`ipa-backup --data --online`	不停止全部服务	仅数据恢复
带日志备份	加 `--logs`	体积和敏感信息增加	视基础备份类型

对于双节点生产环境，推荐在确认另一节点健康后，对选定全角色节点执行。使用本文建议的专用 keyring 时，命令必须显式继承同一个 GNUPGHOME：

export GNUPGHOME="/root/ipa-backup-gnupg"
test -d "$GNUPGHOME"
gpg2 --list-keys --keyid-format LONG

ipa-backup --gpg
ipactl status

只有 ipa-backup 返回成功且服务重新启动正常，才进入后续校验与离线复制步骤；失败时先检查 /var/log/ipabackup.log，禁止把不完整目录标记为有效备份。

典型输出目录：

/var/lib/ipa/backup/ipa-full-YYYY-MM-DD-HH-MM-SS/
├── header
└── ipa-full.tar.gpg

未加密时通常为：

header
ipa-full.tar

不存在官方定义的单个 .ipabackup 文件。

12.5 备份前检查

在备份节点：

ipactl status

ipa-healthcheck --failures-only
ipa-healthcheck \
  --source=ipahealthcheck.ds.replication \
  --source=ipahealthcheck.ipa.topology

df -h /var/lib/ipa/backup /tmp
df -i /var/lib/ipa/backup /tmp

ipa-backup 会使用临时空间。若 /tmp 空间不足，可为本次命令指定另一个受控临时目录：

export GNUPGHOME="/root/ipa-backup-gnupg"
install -d -m 0700 /srv/ipa-backup-tmp
TMPDIR=/srv/ipa-backup-tmp ipa-backup --gpg
ipactl status

不要把 TMPDIR 指向容量不足、可被非 root 访问或位于不可靠网络文件系统的目录。

直接确认另一节点可服务：

ipa --force-server "$IPA2_FQDN" ping
dig @"$IPA2_IP" "$DNS_ZONE" SOA +short

如果备份节点是 ipa2，则把上面测试对象改为 ipa1。

12.6 保存版本与配置清单

每次完整备份同时保存以下信息，且与备份目录绑定：

MANIFEST_DIR="/root/ipa-backup-manifest-$(date +%Y%m%d%H%M%S)"
install -d -m 0700 "$MANIFEST_DIR"

cat /etc/redhat-release > "$MANIFEST_DIR/redhat-release.txt"
cat /etc/os-release > "$MANIFEST_DIR/os-release.txt"

hostnamectl > "$MANIFEST_DIR/hostnamectl.txt"
ip -br address > "$MANIFEST_DIR/ip-address.txt"
ip route > "$MANIFEST_DIR/ip-route.txt"

ipa --version > "$MANIFEST_DIR/ipa-version.txt"
rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' \
  | sort > "$MANIFEST_DIR/rpm-full.txt"

rpm -q ipa-server ipa-server-dns 389-ds-base pki-ca ipa-healthcheck \
  > "$MANIFEST_DIR/rpm-idm-core.txt"

dnf module list idm --enabled > "$MANIFEST_DIR/idm-module.txt"
dnf repolist --enabled > "$MANIFEST_DIR/enabled-repositories.txt"

ipactl status > "$MANIFEST_DIR/ipactl-status.txt"
ipa server-find --all > "$MANIFEST_DIR/servers.txt"
ipa server-role-find --status=enabled > "$MANIFEST_DIR/server-roles-enabled.txt"
ipa config-show > "$MANIFEST_DIR/ipa-config.txt"
ipa dnsconfig-show > "$MANIFEST_DIR/dns-config.txt"
ipa dnsserver-find > "$MANIFEST_DIR/dns-servers.txt"
ipa topologysuffix-find > "$MANIFEST_DIR/topology-suffixes.txt"
ipa topologysegment-find domain > "$MANIFEST_DIR/topology-domain.txt"
ipa topologysegment-find ca > "$MANIFEST_DIR/topology-ca.txt"

另在每个 CA 节点本地保存：

ipa-crlgen-manage status

Directory Manager 和 admin 密码应存入企业密码库，不能只放在备份介质旁。

12.7 识别最新备份目录

备份目录名称中的时间戳按 GMT/UTC 生成，不要直接按本地时区解释。不要假定扩展名。执行：

find /var/lib/ipa/backup \
  -mindepth 1 -maxdepth 1 -type d \
  \( -name 'ipa-full-*' -o -name 'ipa-data-*' \) \
  -printf '%TY-%Tm-%Td %TH:%TM:%TS %p\n' \
  | sort

人工确认本次输出目录，例如：

export BACKUP_DIR="/var/lib/ipa/backup/ipa-full-2026-08-21-09-30-00"

12.8 完整性验证

检查结构：

test -f "$BACKUP_DIR/header"
ls -lah "$BACKUP_DIR"
sed -n '1,120p' "$BACKUP_DIR/header"

生成校验和：

(
  cd "$BACKUP_DIR"
  sha256sum header ipa-full.tar.gpg > SHA256SUMS
  sha256sum -c SHA256SUMS
)

若未加密：

(
  cd "$BACKUP_DIR"
  sha256sum header ipa-full.tar > SHA256SUMS
  sha256sum -c SHA256SUMS
  tar -tf ipa-full.tar >/dev/null
)

若已加密，应使用实际灾备所需 GPG key material 做一次解密读取测试：

export GNUPGHOME="/root/ipa-backup-gnupg"
test -d "$GNUPGHOME"

(
  set -o pipefail
  gpg2 --decrypt "$BACKUP_DIR/ipa-full.tar.gpg" \
    | tar -tf - >/dev/null
)

重要要求：

不仅要测试“文件存在”，还要测试灾备环境能够解密；
GPG key material 的保管和恢复必须单独纳入密码/密钥托管；
header 未必加密，因此整个目录都应作为敏感数据保护；
不要把解密后的明文归档长期写到普通磁盘。

12.9 备份安全与访问控制

完整备份包含足以重建源节点所承载 IdM 角色的数据与配置，应视为身份域的根信任材料，而不是普通运维归档。即使归档使用 GPG 加密，header、manifest、校验和或文件名仍可能暴露主机、版本和角色等元数据，因此整个备份目录都必须按敏感数据保护。

最低控制要求：

chown -R root:root "$BACKUP_DIR" "$MANIFEST_DIR"
find "$BACKUP_DIR" "$MANIFEST_DIR" -type d -exec chmod 0700 {} +
find "$BACKUP_DIR" "$MANIFEST_DIR" -type f -exec chmod 0600 {} +

同时落实：

静态加密和离线/不可变副本；
root 最小访问、审批、审计和定期权限复核；
备份介质与 GPG 私钥恢复材料至少有一个隔离副本，避免单点同失；
禁止把备份、header、manifest 或私钥上传到工单附件、即时通信或普通共享盘；
介质报废按企业密钥材料销毁标准执行。

12.10 复制到离线介质

推荐使用 LUKS 加密的 XFS/ext4 介质。FAT/exFAT 不能可靠保留 Unix 权限和属性，不适合作为首选灾备介质。

先安装复制工具：

dnf install -y rsync

示例：

export OFFLINE_ROOT="/mnt/ipa-offline"
export OFFLINE_COPY="$OFFLINE_ROOT/$(basename "$BACKUP_DIR")"

mountpoint -q "$OFFLINE_ROOT"
install -d -m 0700 "$OFFLINE_COPY"

rsync -aHAX --numeric-ids \
  "$BACKUP_DIR/" \
  "$OFFLINE_COPY/"

sync

(
  cd "$OFFLINE_COPY"
  sha256sum -c SHA256SUMS
)

同时复制 manifest：

rsync -aHAX --numeric-ids \
  "$MANIFEST_DIR/" \
  "$OFFLINE_ROOT/$(basename "$MANIFEST_DIR")/"
sync

完成后：

umount "$OFFLINE_ROOT"

真正的“离线备份”应在复制后断开挂载或进入不可变存储，不能长期以可写 NAS 目录冒充离线副本。

12.11 关于自定义目的目录

官方标准备份位置是 /var/lib/ipa/backup/。原方案中的 --destination 不应使用。

如果该分区容量不足，优先：

把独立文件系统挂载到 /var/lib/ipa/backup；
或先在默认位置生成，再复制完整备份目录到受控介质；
变更挂载前测试 SELinux、权限、空间和回滚。

12.12 备份频率与保留

按业务 RPO 制定，而不是机械采用“每天一次保留 14 天”。至少保留：

多个日备份；
多个周/月备份；
变更前备份；
异地/离线副本；
已验证可解密、可列目录的副本。

不要在同一条 cron 命令中“备份成功后立即按 find -delete 删除旧备份”，除非已实现：

严格的成功判定；
校验和验证；
离线复制完成确认；
最小保留数量保护；
审计日志；
删除失败与误删告警。

依据：RHEL8-BACKUP、RHEL8-PREPARE-DR、MAN-IPA-BACKUP

13. 恢复决策树

场景	正确动作	是否使用 `ipa-restore`
一台节点损坏，另一台健康	删除故障服务器对象，重装并建立新 Replica	否
一台节点软件损坏，但复制数据仍可从另一台获得	重建该节点	否
两台节点全失，只有完整备份	恢复备份对应服务器身份，再建立新 Replica	是
目录数据被批量误删，必须回退到历史时点	全域维护窗口、隔离其余 Replica、恢复并重初始化	是
升级后单节点失败，另一节点健康	从健康节点重建失败节点	通常否
必须仅回退 LDAP 数据	高风险数据恢复，仍需控制复制与重新初始化	`ipa-restore --data`
RHEL 8 迁移到 RHEL 9	新增 RHEL 9 Replica 并迁移角色	否

14. 场景 A：单节点故障，另一台仍健康

这是双节点架构最常见的恢复路径。

14.1 立即隔离故障节点

必须防止故障节点修复后带着旧数据自动回到生产网络：

关闭电源或断开业务网卡；
在虚拟化平台隔离网络；
禁止未完成清理的旧磁盘镜像重新启动；
记录故障发生时间和最后一次成功复制时间。

14.2 检查健康节点

假设 ipa1 故障，ipa2 健康：

export FAILED_SERVER="$IPA1_FQDN"
export SURVIVOR="$IPA2_FQDN"

kinit admin
ipactl status

ipa-healthcheck --failures-only
ipa-healthcheck \
  --source=ipahealthcheck.ds.replication \
  --source=ipahealthcheck.ipa.topology

ipa server-show "$FAILED_SERVER"
ipa server-show "$SURVIVOR"
ipa config-show
ipa dnsconfig-show | grep -i 'DNSSec key master' || true

若输出表明故障节点是 DNSSEC key master，停止本文后续普通删除流程，转入与当前版本匹配的 DNSSEC key master 恢复/迁移流程；不要先执行 ipa server-del。未启用 IdM DNSSEC zone signing 时通常不会显示该角色。

14.3 处理 CA renewal server

如果故障节点是 CA renewal server，而健康节点安装了 CA：

ipa config-mod \
  --ca-renewal-master-server="$SURVIVOR"

再次确认：

ipa config-show

如果两台都未安装 CA，或唯一 CA 节点已丢失且没有带 CA 的可恢复备份，集成 CA 可能不可恢复。

14.4 处理 CRL publisher

在健康 CA 节点本地检查：

ipa-crlgen-manage status

如果 CRL 原由已隔离的故障节点生成：

先确保故障节点已经被 fencing，绝不会重新上线；
在健康 CA 节点启用：

ipa-crlgen-manage enable
ipa-crlgen-manage status

计划迁移时应先在旧节点 disable，再在新节点 enable：

# 旧节点本地
ipa-crlgen-manage disable

# 新节点本地
ipa-crlgen-manage enable

任何时刻只能有一个 CRL publisher。

14.5 删除前检查 Domain Level 与 DNA ID 范围

先确认 Domain Level 和现有 DNA 范围：

ipa domainlevel-get
ipa-replica-manage dnarange-show
ipa-replica-manage dnanextrange-show

RHEL 8 的现代拓扑应为 Domain Level 1。尤其要确认健康节点不是 No range set，否则该节点可能无法继续创建用户或组。

若健康节点没有当前 DNA 范围，可先尝试在健康节点创建并删除一个探针用户：

DNA_PROBE="dna-$(date +%Y%m%d%H%M%S)"

ipa --force-server "$SURVIVOR" user-add "$DNA_PROBE" \
  --first="DNA" \
  --last="Probe"

ipa-replica-manage dnarange-show
ipa --force-server "$SURVIVOR" user-del "$DNA_PROBE"

若故障节点已经不可达且探针创建失败，说明健康节点可能无法从原节点申请范围。此时应暂停删除操作，依据 Red Hat 的 DNA 范围手工调整流程分配不重叠的可用范围。不得在未核对现有 UID/GID 使用情况时直接复用故障节点的范围，否则可能产生重复 UID/GID。生产环境建议由 Red Hat 支持复核具体范围值。

14.6 从拓扑删除故障节点

ipa server-del "$FAILED_SERVER"

随后确认：

ipa server-find
ipa topologysegment-find domain
ipa topologysegment-find ca

该操作会移除 Domain Level 1 拓扑中与该服务器相关的 domain 和 ca 复制数据/协议。删除是不可逆的，重新加入只能安装新 Replica。

若故障节点承担 DNS：

同 FQDN/IP 快速重建时，可保留其 A/PTR，但应在重建期间临时从父域 NS delegation 和客户端 resolver 列表移除，避免查询超时；
永久退役时，应删除父域 NS/glue、IdM zone 中的 NS 记录，以及不再使用的 A/AAAA/PTR；
Replica 安装和 DNS 验收成功后，再把重建节点加入 delegation/resolver。

14.7 重建节点

使用干净 RHEL 8.10，安装 Red Hat 对当前域支持且与健康节点兼容的 IdM build。生产重建优先复用与健康节点相同的 RPM/Content View；若计划借重建实施版本升级，应按已验证的滚动升级顺序执行，不要仅凭“版本更高”自行判断兼容。

然后按本文第 6、9 节执行：

主机名和 IP；
DNS A/PTR；
时间、IPv6、SELinux；
idm:DL1/dns profile；
加入为 client；
ipa-replica-install --setup-dns --setup-ca ...；
父域 delegation；
全套验收。

14.8 回滚

如果重建失败：

ipa-server-install --uninstall

在健康节点检查并删除残留服务器对象：

ipa server-show "$FAILED_SERVER"
ipa server-del "$FAILED_SERVER"

保留健康节点不变，修复根因后再次从干净状态重建。不要通过恢复旧 VM 快照直接把已删除节点放回生产。

依据：RHEL8-SINGLE-RECOVERY、RHEL8-DECOMMISSION、RHEL8-UNINSTALL

15. 场景 B：全域数据回滚或完整服务器恢复

高风险操作：会把目录数据回退到备份时间点，并使恢复节点成为新的唯一数据源。生产环境应在隔离演练成功后执行；复杂场景建议同时打开 Red Hat 支持工单。

15.1 适用条件

仅在以下情形考虑：

所有可用 Replica 都丢失；
大规模误删除/逻辑损坏已复制到所有节点；
所有 CA 数据丢失，但存在带 CA 的完整备份；
无法通过健康 Replica 重建；
明确接受备份之后的数据丢失。

15.2 前置条件

完整恢复要求：

恢复到备份对应的服务器身份；
相同 FQDN；
相同 IP；
相同 IdM 软件版本/RPM；
同样的关键角色和安装配置；
备份目录不位于 /tmp 或 /var/tmp；
Directory Manager 密码可用；
已冻结所有客户端与管理员写入；
可达的其他 Replica 能在受控恢复网络中继续被恢复节点访问，以便 ipa-restore 自动禁用复制协议，但不能继续承载客户端流量；
在恢复时离线或不可达的 Replica 已明确标记为后续删除并重建；
已保存当前状态的额外备份/快照，且不会让两个时间线同时对外服务。

完整服务器恢复会还原 IdM 曾管理或修改的系统文件，可能包括 /etc/passwd、/etc/group、/etc/resolv.conf 等。恢复后必须重新核对本地账号、resolver、网络和主机配置，不能只验证 LDAP 数据。

查看备份头：

sed -n '1,200p' /srv/ipa-recovery/ipa-full-*/header

对照保存的：

RHEL 版本；
ipa --version；
RPM 清单；
主机名/IP；
服务器角色；
DNS/CA/KRA 配置；
CA renewal server 与 CRL publisher。

15.3 冻结写入并控制其他 Replica 的可达性

ipa-restore 会尝试在所有可达的 Replica 上禁用复制协议。因此，不应机械地在命令执行前把全部健康 Replica 关机，否则恢复工具无法在这些节点上自动禁用复制。

推荐控制方式：

冻结管理写入、密码修改、主机加入、证书签发和 DNS 动态更新；
从客户端 DNS、负载入口和网络 ACL 中隔离非恢复节点，禁止其继续承载客户端流量；
保持恢复节点到其他可达 Replica 的必要管理/复制网络连通，让 ipa-restore 能禁用复制协议；
记录 ipa-restore 输出中每个 domain/ca agreement 的禁用结果；
命令完成后，所有非恢复节点继续保持不对客户端服务，直到完成重新初始化；
对恢复期间离线、不可达或未被成功禁用复制的 Replica，最安全做法是删除并重建，禁止直接重新联网。

若安全事件要求物理断网，可先隔离全部节点，再在专用恢复 VLAN 中只开放恢复节点与待处理 Replica 的必要互通；不要让任何旧时间线同时接触生产客户端。

15.4 准备恢复节点

如果原节点仍安装 IdM，先卸载：

ipa-server-install --uninstall

如果系统已重装，则：

使用原 FQDN 和 IP；
从保留的仓库/Content View 安装与备份完全匹配的 IdM RPM；
按备份 header 和 manifest 重新建立相同服务器配置；
不要先更新到最新 errata；
完整服务器恢复前，按官方要求先把 IdM 安装/重装为同构配置。

示意命令仍应以本机 man ipa-server-install 和原始 manifest 为准：

ipa-server-install \
  --hostname="$IPA1_FQDN" \
  --ip-address="$IPA1_IP" \
  --domain="$DOMAIN" \
  --realm="$REALM" \
  --setup-dns \
  --forwarder="$DNS_FORWARDER_1" \
  --forwarder="$DNS_FORWARDER_2" \
  --reverse-zone="$REVERSE_ZONE" \
  --no-ntp

如果原配置有 KRA、外部 CA、Trust 等角色，不能照抄上面的简化命令；必须完整复刻原角色。

15.5 执行恢复

/srv/ipa-recovery/ipa-full-2026-08-21-09-30-00/

若备份使用 --gpg 且采用自定义 keyring，先恢复 GPG 私钥环境并验证：

export GNUPGHOME="/srv/ipa-recovery/gnupg"
test -d "$GNUPGHOME"
chmod 0700 "$GNUPGHOME"
gpg2 --list-secret-keys --keyid-format LONG

ipa-restore 会自动识别加密归档，并使用 root 可访问的 GPG2 keyring；恢复时仍需提供 GPG 私钥 passphrase。

执行：

ipa-restore \
  /srv/ipa-recovery/ipa-full-2026-08-21-09-30-00

按提示：

输入 Directory Manager 密码；
明确确认覆盖当前数据；
记录完整终端输出与日志。

正确对象是备份目录，不是 .ipabackup 文件，也不是 --archive= 参数。

15.6 验证恢复节点

ipactl status
systemctl status ipa --no-pager

kinit admin
ipa ping
ipa user-find --sizelimit=5
ipa server-find
ipa config-show
ipa cert-show 1

ipa-healthcheck --failures-only
ipa-healthcheck \
  --source=ipahealthcheck.ds.replication \
  --source=ipahealthcheck.ipa.topology

dig @localhost "$DNS_ZONE" SOA +short
dig @localhost "_ldap._tcp.${DNS_ZONE}" SRV +short
dig @localhost "_kerberos._udp.${DNS_ZONE}" SRV +short

另检查：

getcert list
ipa-crlgen-manage status

15.7 重新初始化其他 Replica

ipa-restore 会把恢复节点设为新的数据源。其他 Replica 不能继续保留原数据时间线。

对双节点拓扑，假设 ipa1 已恢复，在 ipa2 上执行 domain 重新初始化：

ipa-replica-manage re-initialize \
  --from="$IPA1_FQDN"

如果 ipa2 安装了 CA，再执行 CA suffix 重新初始化：

ipa-csreplica-manage re-initialize \
  --from="$IPA1_FQDN"

CA suffix 重新初始化通常会提示输入 Directory Manager 密码。两条命令都必须确认输出为成功，不能只依赖进程已返回。

然后在 ipa2：

ipactl status

ipa-healthcheck --failures-only
ipa-healthcheck \
  --source=ipahealthcheck.ds.replication \
  --source=ipahealthcheck.ipa.topology

注意：

多节点链式拓扑必须从恢复节点向外逐层初始化；
如果某 Replica 在执行 ipa-restore 时离线，最安全做法通常是删除并重建；
如果备份时间早于某 Replica/复制协议的创建时间，该 Replica 通常应重装；
未完成重新初始化前，禁止旧 Replica 对客户端提供服务。

按照 RHEL 8 官方恢复流程，在每台已恢复/重新初始化的 IdM 服务器上清理 SSSD 缓存并重启：

systemctl stop sssd
sss_cache -E
systemctl start sssd
reboot

重启后再次执行 ipactl status、Healthcheck、Kerberos 和 DNS 验证。

15.8 全域验收

重复本文第 10 节全部测试，并额外验证：

备份时应存在的关键用户、组、HBAC、sudo rule、host、service；
Kerberos 登录；
证书查询/签发链路；
DNS 记录；
CA renewal server；
CRL publisher；
业务应用 LDAP/Kerberos 集成；
备份时点之后的数据丢失清单。

15.9 恢复失败的回滚

继续保持所有旧 Replica 隔离；
不要尝试把“恢复后的时间线”和“旧 Replica 时间线”合并；
回滚恢复主机到操作前快照，或从另一份已验证备份重新开始；
保留所有日志、header、RPM manifest 和校验和；
生产环境进入 Red Hat 支持流程。

依据：RHEL8-DR、MAN-IPA-RESTORE

16. 场景 C：两台服务器全部丢失

选择一份来自全角色 CA 节点的完整备份；
找到与其匹配的 RPM/模块仓库快照；
在隔离网络中重建备份对应主机的 FQDN、IP 和服务器配置；
执行 ipa-restore <完整备份目录>；
验证 LDAP/Kerberos/DNS/CA；
再用干净 RHEL 安装第二台 Replica，并使用 --setup-dns --setup-ca；
重新做父域 delegation 与客户端 resolver 验证；
完成全套故障切换和备份恢复验收后再开放生产流量。

如果满足以下三项：

CA renewal server 已丢失；
没有其他 CA Replica；
没有带 CA 角色的可恢复备份；

则集成 CA 信任体系可能无法恢复。这也是两台都安装 CA、并从全角色节点备份的根本原因。

依据：RHEL8-SINGLE-RECOVERY、RHEL8-PREPARE-DR

17. 场景 D：仅数据恢复

支持的命令形式：

ipa-restore --data \
  /srv/ipa-recovery/ipa-full-2026-08-21-09-30-00

或从 data-only 备份恢复：

ipa-restore \
  /srv/ipa-recovery/ipa-data-2026-08-21-09-30-00

这仍然是全域数据回滚，不是普通的“导入几条 LDAP 记录”。需要：

维护窗口；
冻结写入并隔离客户端流量；
让可达 Replica 由 ipa-restore 禁用复制，离线 Replica 后续重建；
接受备份时点后的数据丢失；
重新初始化其他 Replica；
完整业务验收。

如果只误删少量对象，优先评估通过审计记录、变更记录或受控重建对象恢复，而不是执行全域 ipa-restore --data。

18. 计划迁移 CA renewal 与 CRL 角色

18.1 迁移 CA renewal server

kinit admin

ipa config-mod \
  --ca-renewal-master-server="$IPA2_FQDN"

ipa config-show

18.2 迁移 CRL publisher

在旧节点本地：

ipa-crlgen-manage status
ipa-crlgen-manage disable
ipa-crlgen-manage status

在新节点本地：

ipa-crlgen-manage enable
ipa-crlgen-manage status

确认只有新节点显示 enabled 后，才继续退役旧节点。

18.3 删除前角色、拓扑与 DNA 检查

ipa domainlevel-get

ipa server-role-find --role="CA server"
ipa server-role-find --role="DNS server"
ipa dnsconfig-show | grep -i 'DNSSec key master' || true

ipa topologysegment-find domain
ipa topologysegment-find ca

ipa-replica-manage dnarange-show
ipa-replica-manage dnanextrange-show

若待保留节点尚无 DNA 当前范围，应在旧节点仍在线、复制正常时，从待保留节点创建一次探针用户，使其申请范围：

DNA_PROBE="dna-$(date +%Y%m%d%H%M%S)"

ipa --force-server "$IPA2_FQDN" user-add "$DNA_PROBE" \
  --first="DNA" \
  --last="Probe"

ipa-replica-manage dnarange-show
ipa --force-server "$IPA2_FQDN" user-del "$DNA_PROBE"

确认待删除节点不是任何关键服务的唯一提供者，且删除后拓扑仍连通。若它是 DNSSEC key master，必须先完成该角色迁移；本文不提供该特殊角色的迁移命令。

18.4 删除服务器并清理 DNS

ipa server-del "$IPA1_FQDN"

在旧服务器本地清理：

ipa-server-install --uninstall

永久退役 DNS 节点时，还应从父域 delegation 和 IdM/外部 DNS 中删除其 NS/glue 及不再使用的 A/AAAA/PTR 记录，并从客户端 resolver、监控和防火墙策略中移除。

不要在仍承担唯一 CA/DNS/KRA/Trust 角色时直接删除节点，也不要在 DNA 范围未核实的情况下删除唯一持有范围的节点。

依据：RHEL8-CRL、RHEL8-DECOMMISSION、RHEL8-UNINSTALL、RHEL8-DNA

19. 排障命令

19.1 IdM 整体

ipactl status
systemctl status ipa --no-pager
journalctl -u ipa --since "-1 hour"

19.2 安装日志

less /var/log/ipaserver-install.log
less /var/log/ipareplica-install.log
less /var/log/ipareplica-ca-install.log
less /var/log/ipaupgrade.log
less /var/log/ipabackup.log
less /var/log/iparestore.log

19.3 Directory Server

ls -ld /var/log/dirsrv/slapd-*
tail -n 200 /var/log/dirsrv/slapd-*/errors

复制专项：

ipa-healthcheck \
  --source=ipahealthcheck.ds.replication \
  --source=ipahealthcheck.ipa.topology

不要使用原方案中错误的 ld:// URI 或手工猜测 cn=replica,... DN 作为首选检查方法。

19.4 Kerberos

kdestroy -A
KRB5_TRACE=/dev/stderr kinit admin
klist -ef
journalctl -u krb5kdc --since "-1 hour"

19.5 DNS

dig "$DNS_ZONE" NS
dig +short -t SRV "_ldap._tcp.${DNS_ZONE}"
dig +short -t SRV "_kerberos._udp.${DNS_ZONE}"

# 对企业父 DNS 直接查询 delegation；下列 TEST-NET 地址必须替换
export PARENT_DNS_IP="192.0.2.10"
dig @"$PARENT_DNS_IP" "$DNS_ZONE" NS

dig @"$IPA1_IP" "$DNS_ZONE" SOA
dig @"$IPA2_IP" "$DNS_ZONE" SOA

仅在 DNS 委派链对当前主机可见且允许递归追踪时使用 dig +trace；内部 split-DNS 环境通常应直接查询父 DNS 和两个 IdM DNS。

19.6 CA / Dogtag / certmonger

ipa server-role-find --role="CA server"
ipa config-show
ipa-crlgen-manage status
getcert list

ls -ld /var/log/pki/pki-tomcat
find /var/log/pki/pki-tomcat -maxdepth 3 -type f -mtime -2 -ls

不要假定固定的 certutil -d sql:/var/lib/pki/ca/instance 数据库路径，也不要使用不存在的 ipa server-cert 作为修复动作。

19.7 SELinux

getenforce
ausearch -m AVC -ts recent
journalctl -t setroubleshoot --since "-1 hour"
restorecon -Rv /etc/ipa /var/lib/ipa

restorecon 应针对明确受影响路径执行；不要无差别修改策略或关闭 SELinux。

19.8 网络

ss -lntup
firewall-cmd --get-active-zones
firewall-cmd --zone="$FIREWALL_ZONE" --list-all

nc -vz "$IPA1_FQDN" 443
nc -vz "$IPA1_FQDN" 389
nc -vz "$IPA1_FQDN" 88

20. 风险与回滚矩阵

操作	主要风险	变更前保护	回滚方式
安装 ipa1	DNS 域冲突、残留半安装	干净 OS、DNS 评审、控制台	`ipa-server-install --uninstall`，修复后重装
安装 ipa2	A/PTR、端口、CA 安装失败	ipa1 健康、完整日志、一次装一台	卸载 ipa2，必要时 `ipa server-del`
停止 ipa1 做 HA 测试	客户端未正确发现 ipa2	先验证 ipa2、双 DNS、维护窗口	立即 `systemctl start ipa`
完整备份	备份节点短时不可用、空间不足	另一节点健康、磁盘空间检查	启动 ipa，检查日志和健康
删除 Replica	不可逆，可能切断拓扑或删除最后角色	角色/拓扑检查、fencing	只能重新安装新 Replica
迁移 CA renewal	错误节点无 CA	两台 CA 角色确认	改回原健康 CA
迁移 CRL	两节点同时生成或无人生成	先查 status，按 disable→enable	在唯一健康 CA 上恢复 enable
`ipa-restore`	全域数据回退、旧 Replica 覆盖恢复数据	冻结写入、隔离客户端流量、保持受控管理可达、额外快照/备份	保持旧时间线不对外，回退恢复主机或换备份重做
跨版本恢复	不兼容、命令拒绝	RPM/模块仓库快照	回到完全匹配版本
RHEL 8→9	原地升级或跨版恢复失败	官方迁移方案、先加 Replica	保留 RHEL 8 健康节点，撤回新 Replica

21. 生产验收清单

21.1 部署

21.2 备份

21.3 灾备

单节点故障明确采用 Replica 重建，不误用 ipa-restore；
全域恢复已冻结写入并隔离客户端流量，同时保留受控的 Replica 管理可达性；
离线或未被成功禁用复制的 Replica 已定义删除重建流程；
能获得相同 RPM/模块版本；
能恢复原 FQDN/IP；
已演练 ipa-restore <目录>；
已演练 domain 和 ca suffix 重新初始化；
已定义旧 Replica 禁止直接上线的控制措施；
已定义恢复后的业务验收与数据丢失沟通流程。

22. 正确命令速查

操作	正确命令
查看全部 IdM 组件状态	`ipactl status`
启动全部 IdM 服务	`systemctl start ipa`
停止全部 IdM 服务	`systemctl stop ipa`
重启全部 IdM 服务	`systemctl restart ipa`
全量 Healthcheck	`ipa-healthcheck --failures-only`
复制/拓扑 Healthcheck	`ipa-healthcheck --source=ipahealthcheck.ds.replication --source=ipahealthcheck.ipa.topology`
查服务器	`ipa server-find`
查服务器角色	`ipa server-role-find --role="CA server"`
查拓扑 suffix	`ipa topologysuffix-find`
查 domain segment	`ipa topologysegment-find domain`
查 ca segment	`ipa topologysegment-find ca`
直接测试指定服务器	`ipa --force-server "$SERVER_FQDN" ping`
安装第二 CA	`ipa-replica-install ... --setup-ca`
完整离线备份	`ipa-backup`
加密完整离线备份	`ipa-backup --gpg`
数据离线备份	`ipa-backup --data`
数据在线备份	`ipa-backup --data --online`
完整恢复	`ipa-restore /path/to/ipa-full-*`
从完整备份仅恢复数据	`ipa-restore --data /path/to/ipa-full-*`
重初始化 domain	`ipa-replica-manage re-initialize --from="$SOURCE_SERVER"`
重初始化 CA	`ipa-csreplica-manage re-initialize --from="$SOURCE_SERVER"`
查看当前 DNA 范围	`ipa-replica-manage dnarange-show`
查看下一 DNA 范围	`ipa-replica-manage dnanextrange-show`
删除服务器	`ipa server-del "$SERVER_FQDN"`
本机卸载 IdM	`ipa-server-install --uninstall`
查看 CA renewal server	`ipa config-show`
迁移 CA renewal server	`ipa config-mod --ca-renewal-master-server="$SERVER_FQDN"`
查看本机 CRL 角色	`ipa-crlgen-manage status`
启用本机 CRL	`ipa-crlgen-manage enable`
禁用本机 CRL	`ipa-crlgen-manage disable`
导出外部 DNS 系统记录	`ipa dns-update-system-records --dry-run --out /root/ipa-system-records.nsupdate`

23. 本机版本最终校验

任何生产命令执行前，必须以目标 RHEL 8.10 节点上的 man page 为最后校验：

man ipa-server-install
man ipa-replica-install
man ipa-backup
man ipa-restore
man ipa-healthcheck
man ipa-replica-manage
man ipa-csreplica-manage
man ipa-crlgen-manage

ipa-server-install --help
ipa-replica-install --help
ipa-backup --help
ipa-restore --help

同时记录：

ipa --version
rpm -q ipa-server ipa-server-dns 389-ds-base pki-ca ipa-healthcheck
dnf module list idm --enabled

如果本机命令帮助、Red Hat 当前文档与本文存在差异，以与该 RHEL 订阅和 RPM build 对应的 Red Hat 文档、man page 和厂商支持结论为准。

24. 参考资料

以下资料按优先级采用 Red Hat RHEL 8 官方文档；FreeIPA 上游与 man page 用于补充命令语义。

RHEL8-PREPARE Red Hat Enterprise Linux 8 — Preparing the system for IdM server installation
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/installing_identity_management/preparing-the-system-for-ipa-server-installation_installing-identity-management
RHEL8-MODULE Red Hat Enterprise Linux 8 — IdM DL1 module profiles
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/considerations_in_adopting_rhel_8/identity-management_considerations-in-adopting-rhel-8
RHEL8-FIREWALL Red Hat Enterprise Linux 8 — IdM network port and firewalld preparation
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/installing_identity_management/preparing-the-system-for-ipa-server-installation_installing-identity-management
RHEL8-REPLICA Red Hat Enterprise Linux 8 — Installing an IdM replica
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/installing_identity_management/installing-an-ipa-replica_installing-identity-management
RHEL8-REPLICA-TROUBLESHOOT Red Hat Enterprise Linux 8 — Troubleshooting IdM replica installation
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/installing_identity_management/troubleshooting-idm-replica-installation_installing-identity-management
RHEL8-DNS-RECORDS Red Hat Enterprise Linux 8 — IdM DNS records for external DNS systems
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/installing_identity_management/installing-an-ipa-server-without-integrated-dns_installing-identity-management
RHEL8-DNS-FORWARDING Red Hat Enterprise Linux 8 — Managing DNS forwarding in IdM
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/configuring_and_managing_identity_management/managing-dns-forwarding-in-idm_configuring-and-managing-idm
RHEL8-DNSSEC-ROLE Red Hat Enterprise Linux 8 — Managing replication topology / DNSSEC key master checks
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/configuring_and_managing_identity_management/assembly_managing-replication-topology_configuring-and-managing-idm
RHEL8-HA Red Hat Enterprise Linux 8 — Failover, load-balancing, and high availability in IdM
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/planning_identity_management/failover-load-balancing-high-availability_planning-identity-management
RHEL8-TOPOLOGY Red Hat Enterprise Linux 8 — Managing replication topology
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/configuring_and_managing_identity_management/assembly_managing-replication-topology_configuring-and-managing-idm
RHEL8-SERVICE Red Hat Enterprise Linux 8 — Viewing, starting and stopping the IdM server
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/configuring_and_managing_identity_management/viewing-starting-and-stopping-the-ipa-server_configuring-and-managing-idm
RHEL8-HEALTHCHECK Red Hat Enterprise Linux 8 — Checking IdM replication using Healthcheck
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/using_idm_healthcheck_to_monitor_your_idm_environment/checking-idm-replication-using-healthcheck_using-idm-healthcheck-to-monitor-your-idm-environment
RHEL8-BACKUP Red Hat Enterprise Linux 8 — Backing up and restoring IdM
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/planning_identity_management/backing-up-and-restoring-idm_planning-identity-management
RHEL8-PREPARE-DR Red Hat Enterprise Linux 8 — Preparing for data loss with IdM backups
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/preparing_for_disaster_recovery_with_identity_management/preparing-for-data-loss-with-idm-backups_preparing-for-disaster-recovery
RHEL8-DR Red Hat Enterprise Linux 8 — Performing disaster recovery with Identity Management
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/performing_disaster_recovery_with_identity_management/
RHEL8-SINGLE-RECOVERY Red Hat Enterprise Linux 8 — Recovering a single server with replication
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/performing_disaster_recovery_with_identity_management/recovering-a-single-server-with-replication_performing-disaster-recovery
RHEL8-CRL Red Hat Enterprise Linux 8 — Generating CRL on the IdM CA server
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/configuring_and_managing_identity_management/generating-crl-on-the-idm-ca-server_configuring-and-managing-idm
RHEL8-DECOMMISSION Red Hat Enterprise Linux 8 — Decommissioning a server performing CA renewal and CRL roles
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/configuring_and_managing_identity_management/proc_decommissioning-a-server-that-performs-the-ca-renewal-server-and-crl-publisher-roles_configuring-and-managing-idm
RHEL8-UNINSTALL Red Hat Enterprise Linux 8 — Uninstalling an IdM server
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/installing_identity_management/uninstalling-an-ipa-server_installing-identity-management
RHEL8-DNA Red Hat Enterprise Linux 8 — Adjusting ID ranges manually
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/configuring_and_managing_identity_management/adjusting-id-ranges-manually_configuring-and-managing-idm
RHEL9-MIGRATION Red Hat Enterprise Linux 9 — Migrating IdM from RHEL 8 to RHEL 9
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/migrating_to_identity_management_on_rhel_9/assembly_migrating-your-idm-environment-from-rhel-8-servers-to-rhel-9-servers_migrating-to-idm-on-rhel-9
MAN-IPA-BACKUP ipa-backup(1) man page mirror
https://www.mankier.com/1/ipa-backup
MAN-IPA-RESTORE ipa-restore(1) man page mirror
https://www.mankier.com/1/ipa-restore
FreeIPA upstream backup/restore notes（次级参考，部分页面较旧）
https://www.freeipa.org/page/V3/Backup_and_Restore

25. 最终建议

对于本方案的两节点规模，生产落地建议至少完成以下增强：

两台均安装 DNS 与 CA；
客户端采用双 DNS 和 SSSD _srv_ 服务发现；
明确 CA renewal server、CRL publisher，以及启用 zone signing 时的 DNSSEC key master 运维流程；
完整备份只在全角色节点执行；
保存与备份匹配的 RPM 仓库快照和配置 manifest；
离线副本必须通过解密、tar 列目录和 checksum 三重验证；
每季度至少做一次隔离恢复演练；
业务规模扩大后增加一个全角色 hidden Replica 作为备份节点；
双向创建测试用户，确保两台均获得 DNA ID 范围；
单节点故障一律优先重建 Replica；
只有在全域数据回滚/全节点丢失时才使用 ipa-restore。

本稿已经移除了原方案中的无效命令、未经验证的参数、固定内部路径和不准确的恢复假设。生产执行时仍需把示例域名、IP、DNS forwarding、反向 zone、firewalld zone、仓库版本和角色清单替换为真实环境值。

RHEL 8.10 FreeIPA（IdM）双节点高可用、离线备份与灾难恢复方案（审校版）

1. 审校结论

2. 原方案关键问题清单

3. 架构与高可用边界

3.1 推荐双节点角色

3.2 复制对象的准确理解

3.3 高可用不是 VIP 集群

3.4 两个需要单独管理的 CA 角色

3.5 DNSSEC validation 与 DNSSEC zone signing 不是一回事

4. 示例变量与部署假设

5. 变更前 Go/No-Go 检查

6. 两台主机的系统准备

6.1 使用干净 RHEL 8.10

6.2 主机名

6.3 /etc/hosts

6.4 DNS 正反向验证

6.4.1 DNS forwarder 能力验证

6.5 时间同步

6.6 IPv6 loopback 与 SELinux

6.7 root umask

6.8 安装 RHEL 8 IdM 模块

6.9 firewalld

7. DNS 设计与记录

7.1 推荐使用标准 delegation

7.2 外部 DNS 场景不要手工猜 SRV 表

7.3 Integrated DNS 场景

8. 安装第一台 IdM 服务器 ipa1

8.1 推荐交互式安装

8.2 不推荐直接把长期密码写入命令行

8.3 ipa1 安装后验证

9. 安装第二台 Replica ipa2

9.1 先确保 ipa2 的 DNS 记录存在

9.2 ipa2 的 resolver 必须能发现 ipa1

9.3 推荐先加入为 IdM client，再提升为 Replica

9.4 安装 DNS + CA Replica

9.5 Replica 安装失败的清理

10. 双节点验收

10.1 组件状态

10.2 服务器与角色

10.3 复制拓扑

10.4 直接访问每个 IPA API

10.5 双向写入、删除复制与 DNA 范围测试

10.6 两台 DNS 的直接查询

10.7 CA 与 CRL

10.8 客户端发现配置

10.9 故障切换演练

11. 日常运维标准命令

11.1 状态与健康

11.2 服务启停

11.3 DNS 与发现

11.4 CA 角色

11.5 升级原则

12. 备份设计

12.1 备份不能替代复制

12.2 选择备份节点

12.3 GPG2 前置准备

12.4 备份类型

12.5 备份前检查

12.6 保存版本与配置清单

12.7 识别最新备份目录

12.8 完整性验证

12.9 备份安全与访问控制

12.10 复制到离线介质

12.11 关于自定义目的目录

12.12 备份频率与保留

13. 恢复决策树

14. 场景 A：单节点故障，另一台仍健康

14.1 立即隔离故障节点

14.2 检查健康节点

14.3 处理 CA renewal server

14.4 处理 CRL publisher

14.5 删除前检查 Domain Level 与 DNA ID 范围

14.6 从拓扑删除故障节点

14.7 重建节点

14.8 回滚

15. 场景 B：全域数据回滚或完整服务器恢复

15.1 适用条件

15.2 前置条件

15.3 冻结写入并控制其他 Replica 的可达性

15.4 准备恢复节点

6.3 `/etc/hosts`