单台物理主机被攻击时的业务切换设计，关键不是尽快把业务搬到另一台机器，而是先阻断攻击，再确认接管环境可信、数据状态可接受。若只切换服务、不隔离原主机，攻击者可能继续操作；若盲目同步，损坏或加密的数据也可能被复制到备用端。
先判断攻击范围，再决定切换方式
发现异常登录、文件被加密或关键数据遭删除时，先由授权人员记录告警时间、受影响服务和已观察到的现象。不要急着重启、清理日志或把原主机直接接回业务网络，这些操作可能破坏调查线索，也无法证明主机已经安全。
接着从交换机端口、虚拟化管理平台或其他可用的网络控制面隔离受影响主机；保留必要的管理与取证通道，并按既定流程通知安全、运维和业务负责人。若攻击可能涉及管理账号、备份凭据或同一管理网络，相关凭据也应暂停使用并通过可信设备更换。
按数据状态选接管路径
备用主机有持续复制
以 PostgreSQL 为例，流复制可以让备用数据库接收主库变更，但异步复制可能尚未送达最近提交的事务；同步复制通常更强调确认写入的一致性，代价可能是写入延迟增加。复制也会传递误删或恶意修改，因此它不是独立备份。应查看最后接收、重放位置及业务确认记录，再决定可接受的数据缺口。
没有可信的热备
从攻击前的离线或不可变备份，在隔离环境恢复到干净主机，再安装可信的软件包、应用配置和数据。恢复点越早，可能丢失的正常业务变更越多；越晚，也越需要确认备份未被攻击者污染。选择时应依据备份时间、校验结果和业务方确认，而不是只看备份任务显示“成功”。
切换与回切按顺序执行
- 冻结写入：暂停会产生关键变更的入口或将业务置为维护状态，记录最后一笔已确认交易，避免旧主机和备用端同时接受写入。
- 确认隔离：确保原主机不能继续向业务数据源写入；怀疑账号泄露时，先撤销或轮换相关凭据。
- 检查接管数据：核对复制位置、备份校验记录和关键业务账目。对无法确认的数据，标明缺口并由业务负责人决定是否接受。
- 启用备用端：只启动必要服务，先做小范围连通和读写验证，再逐步恢复业务流量。变更解析记录时要考虑缓存，旧地址的缓存不会因修改立即全部消失。
- 稳定后规划回切：先在隔离环境重建原主机，更新系统与凭据并确认无残留风险；从当前权威数据源向重建主机单向同步，校验完成后暂停写入、完成最终同步，再按计划切回。
最容易造成二次事故的错误
- 双主或双写：两端都可接受写入时，记录可能冲突或重复。切换期间明确唯一写入端，回切也必须保持同一原则。
- 把复制当备份：实时同步可能迅速传播加密、误删和错误更新。独立保留多时间点、与生产凭据隔离的备份，并定期验证恢复。
- 从旧主机反向覆盖新数据：回切前先认定哪一端是权威数据源。不能因为旧主机恢复可用，就直接用其数据覆盖接管期间产生的新记录。
- 未验证就重新接网：补丁和杀毒扫描本身不能证明主机可信。无法确认清除范围时，优先重建并恢复经过验证的数据。
可在平时预先写好切换清单，明确负责人、数据核对项、允许的数据丢失范围和业务恢复目标。单台物理主机被攻击时的业务切换设计，最终要保证隔离边界清楚、数据只有一个权威来源，并且回切经过验证，而不是只追求恢复速度。
常见问题
切换时能否保留原主机在线取证？
可以按安全流程保留受控取证通道，但应阻断其业务写入和不必要的网络访问，避免继续影响生产。
复制延迟很小，是否可以直接提升备用端？
不一定。还要确认攻击发生时间、最后成功重放位置，以及异常变更是否已进入复制流。
回切时如何避免数据丢失？
先指定唯一权威端，单向同步并核对差异；最终同步期间暂停写入，确认完成后再开放回切后的业务写入。
恢复备份后就能认定系统安全了吗？
不能。还需确认恢复点可信、软件与配置来源可靠、凭据已处理，并检查业务运行状态和访问权限。