OCR备份不可手动添加，只能通过ocrconfig -restore物理还原；backup00.ocr被覆盖是设计使然，并非异常丢失，因自动备份采用滚动覆盖机制，仅保留有限副本且文件名固定。
backup00.ocr 不是“自动丢失”，而是被覆盖或删除——OCR 自动备份本身不保留历史，只滚动写入固定文件名；RMAN 的 DELETE OBSOLETE 也可能误删 OCR 备份路径下的文件（如果脚本没隔离目录）。
OCR 自动备份只保留最新一份，且文件名固定
oracle rac 11g 默认每 4 小时在 master node 的 $grid_home/crs/cdata/ 下生成一次自动备份，但始终只写入 backup00.ocr、backup01.ocr、week.ocr 这几个固定文件名。其中 backup00.ocr 是最近一次的快照，每次新备份会直接覆盖它。
-
backup00.ocr被覆盖后，上一版内容即不可恢复——这不是“丢失”，是设计如此 -
backup01.ocr和week.ocr同样会被后续备份轮替覆盖，不是归档式保存 - 若 Master Node 切换过，旧节点上的备份不会自动同步到新 Master，导致
ocrconfig -showbackup查不到历史备份
RMAN 脚本误删 OCR 备份目录的风险
很多 DBA 把 RMAN 备份脚本和 OCR 备份放在同一级目录（比如都放在 /data/backup/），并在脚本中执行 DELETE OBSOLETE 或 DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-7'。一旦路径未严格限定，RMAN 可能递归清理整个父目录，连带删掉 backup*.ocr 文件。
- 典型错误：脚本里用
find /data/backup -name "*.bak" -mtime +1 -delete，但 OCR 备份也在该路径下 - RMAN 不识别
.ocr文件类型，DELETE OBSOLETE依据的是控制文件中记录的备份元数据——如果 OCR 备份被手动拷进 RMAN 目录且未注册，RMAN 不管；但如果用CATALOG命令注册过，就可能被当作“废弃”清理 - 检查方法：
ls -lt $GRID_HOME/crs/cdata/看修改时间是否断层（比如跳过 4 小时间隔）/backup*.ocr
ocrconfig -showbackup 返回空 ≠ 备份物理不存在
这个命令依赖 OCR 设备可读、CSS 进程正常、当前节点是 Master 或能访问 Master 的备份目录。常见假性“丢失”场景：
- 集群未启动或仅部分节点启动，
ocrconfig命令报PROT-1: Failed to initialize ocrconfig——此时不是备份没了，是 OCR 根本不可访问 - Master Node 已切换，但你登录的是非 Master 节点，
ocrconfig -showbackup默认查本地路径，而备份实际在原 Master 上 - 备份目录被管理员改过，但
ocrconfig -backuploc没同步更新，命令仍去旧路径找
真正危险的是：当 backup00.ocr 被覆盖、backup01.ocr 也被轮替掉、又没做过 ocrconfig -manualbackup 或 ocrconfig -export，那就只剩一条路——无备份重建。这个过程要停集群、清磁盘头、重跑 root.sh，比恢复难得多。
