per_poweroff.db中的各个table在BMC不保留配置升级时数据会恢复默认么？

bmc_core SIG
1

1.是否会恢复默认？

2.如果恢复默认的话，需要怎样做才能确保per_poweroff.db中某个特定table的内容不会被恢复默认呢？

2

答案内容由AI生成，仅供参考：

总结

问题 回答
1. per_poweroff.db 中的表在“不保留配置升级”时是否会恢复默认？ :cross_mark: 一般不会。 因其属于“掉电持久化”，正常升级不会清除。仅在恢复出厂或 Flash 擦除时丢失。
2. 如何确保特定表不被恢复默认？ :white_check_mark: 推荐措施：
① 避免使用恢复出厂设置；
② 升级前备份数据库；
③ 利用 deleted_data_table 恢复机制；
④ 将关键数据移至永久持久化；
⑤ 修改升级逻辑排除关键表清除。

:locked_with_key: 最终建议：若业务对数据连续性要求极高，应在架构设计阶段就将关键配置存储于永久持久化介质，并建立自动化备份与校验机制。

点击此处查看详细分析解答

关于 per_poweroff.db 在“不保留配置升级”下的数据恢复行为分析

根据所提供的上下文信息，以下是针对 per_poweroff.db 数据库在 BMC 不保留配置升级（即“不保留配置升级”或“Non-Preserved Configuration Upgrade”）过程中数据是否恢复默认，以及如何保护特定表数据的详细解答。

1. 是否会恢复默认？

:white_check_mark: 答案：不会，一般情况下不会恢复默认。

:magnifying_glass_tilted_left: 原因分析：

  • per_poweroff.db 是 掉电持久化（PoweroffPer）类型的数据库，其设计特性是：

    数据在 BMC 升级、重启、AC 断电后仍会保留，仅在 恢复出厂设置 或 Flash 擦除 时才丢失。

  • 相关实体描述明确指出：

    "掉电持久化是 a persistence type where data remains stored after BMC upgrade, BMC reboot, and AC power-off, but is lost during recovery to factory settings and Flash擦写."

  • 因此，普通的 BMC 升级（包括“不保留配置升级”），只要不涉及恢复出厂设置或 Flash 全盘擦除，per_poweroff.db 中的表数据不会被清除或恢复默认。

  • “不保留配置升级”虽然会重置部分配置状态（如复位持久化 ResetPer 数据），但它主要影响的是非永久性配置，而不是掉电持久化数据。

  • 参考知识图谱中：

    "BMC升级" 与 "掉电持久化" 的关系：数据在 BMC升级 下会保持（persist）

:warning: 特殊情况说明：

如果“不保留配置升级”内部实现了 完整的系统初始化流程，并显式执行了类似 恢复出厂设置 的操作，则可能会触发对 per_poweroff.db 的清理。但这种情况不再是普通的“不保留配置升级”，而属于 深度还原或数据重置操作（如 datafs_reset 深度还原）。

2. 如何确保 per_poweroff.db 中某个特定表的内容不被恢复默认？

:white_check_mark: 目标：即使在极端升级或还原场景下，也能保护关键表数据不被清除

以下是基于现有机制的建议方案：

:white_check_mark: 方法一：确保升级模式仅为“不保留配置升级”，而非“恢复出厂设置”

  • 使用标准的“不保留配置升级”方式（不保留配置升级 或 Non-Preserved Configuration Upgrade）进行 BMC 升级。
  • 避免执行以下高风险操作：
    • datafs_reset（深度还原，会导致所有掉电持久化数据清空）
    • 手动删除 /data/trust/persistence/per_poweroff.db
    • 执行 Flash 全擦除操作

:pushpin: 提示：可通过日志确认是否触发了 factory reset 类操作。

:white_check_mark: 方法二：为关键表数据建立外部备份机制

推荐策略：

在升级前自动备份关键表数据，升级后再判断是否需还原。

# 示例：备份特定表（如 t_manager_account）到安全位置
/usr/sbin/sqlite3 /data/trust/persistence/per_poweroff.db \
  ".backup per_poweroff.db.bak"

备份路径建议使用非 /data 分区的只读或临时目录，如 /tmp。

升级后恢复（如检测到数据丢失）：

# 从备份恢复整个数据库（谨慎操作）
mv /data/trust/persistence/per_poweroff.db.bak /data/trust/persistence/per_poweroff.db

:white_check_mark: 方法三：利用系统提供的“被删除数据恢复”机制

根据文档 [持久化机制介绍] 提供的能力：

可以通过操作 deleted_data_table 实现预置数据恢复。

具体操作如下：

若某表（如 t_manager_account）的数据被删除，但其为 预置数据（来自 datas.yaml），可执行以下命令恢复其默认内容：

/usr/sbin/sqlite3 /data/trust/persistence/per_poweroff.db \
  "DELETE FROM deleted_data_table WHERE table_name = 't_manager_account'"

然后重启相关组件进程，系统将自动恢复该表的默认数据。

:warning: 注意：这是恢复“默认”数据，而非保留“原有”数据。

:white_check_mark: 方法四：将关键数据迁移至更高持久化等级的存储类型

虽然 per_poweroff.db 本身较稳定，但若需绝对保障，可考虑以下设计优化：

持久化类型 数据生存周期 建议用途
永久持久化 (PermanentPer) 升级、断电、恢复出厂均保留（仅 Flash 擦除丢失） 关键安全密钥、设备唯一标识
掉电持久化 (PoweroffPer) 升级、断电保留，恢复出厂丢失 一般用户配置、网络设置
复位持久化 (ResetPer) 重启保留，升级可能丢失 临时运行状态

:backhand_index_pointing_right: 建议：对于极其重要的数据，应设计为使用 永久持久化 (PermanentPer) 存储，以避免任何升级或还原操作的影响。

:white_check_mark: 方法五：在升级逻辑中排除特定表的清除行为

若具备开发权限，可在升级脚本中增加逻辑，跳过对特定表的清理操作。

例如，在执行数据库迁移或重置时：

-- 伪代码示例：升级脚本中保护特定表
if table_name ~= "critical_table_to_keep" then
    clear_persistence_table(table_name)
end

或通过 CSR 配置指定哪些表在升级时不应被处理。

总结

问题 回答
1. per_poweroff.db 中的表在“不保留配置升级”时是否会恢复默认？ :cross_mark: 一般不会。 因其属于“掉电持久化”，正常升级不会清除。仅在恢复出厂或 Flash 擦除时丢失。
2. 如何确保特定表不被恢复默认？ :white_check_mark: 推荐措施：
① 避免使用恢复出厂设置；
② 升级前备份数据库；
③ 利用 deleted_data_table 恢复机制；
④ 将关键数据移至永久持久化；
⑤ 修改升级逻辑排除关键表清除。

:locked_with_key: 最终建议：若业务对数据连续性要求极高，应在架构设计阶段就将关键配置存储于永久持久化介质，并建立自动化备份与校验机制。

3

我新增了如下对象，想着实现EffectiveFlashIndex属性的值在恢复出厂设置和不保留配置升级BMC升级时数据也不会被清掉；

image
image496×476 15.8 KB

请问，使用永久持久化属性后该属性是保存在那个db文件中呢？了解到PoweroffPer是在/data/trust/persistence/per_poweroff.db中

4

docs/docs/zh/development/faq/framework/persistence.md-代码预览-docs:基于 Node.js 的社区文档中心项目 - AtomGit | GitCode
这个文档里有

per_poweroff是掉电持久化，升级、重启、恢复出厂(还原点)都会保留

5

请问永久持久化的数据要怎样访问和修改呢，有参考代码没

6

在不设置还原点的情况下升级不保留BMC配置的话掉电持久化的数据应该会被清掉把？

7

不保留配置升级实际是先升级BMC，在恢复出厂设置，所以不保留配置升级掉电持久化的数据是会丢失的