运维配置管理后端【免费下载链接】saltSoftware to automate the management and configuration of infrastructure and applications at scale.项目地址https://gitcode.com/gh_mirrors/sa/salt点击查看免费下载本指南聚焦 Salt 的 File State Backups文件状态备份功能即通过backup_mode与backup参数为被file.managed、file.recurse等状态替换的文件自动保留历史版本并提供列出、恢复与删除备份的完整操作方案。读者阅读后可掌握在 minion 配置或单个 state 中启用备份、理解备份文件的存储命名规则以及使用file.list_backups、file.restore_backup、file.delete_backup三个执行模块进行备份生命周期管理的全部实战技能。一、功能背景为什么需要 backup_mode在 Salt 0.10.2 版本中为file.managed与file.recurse状态引入了一项新特性当这些状态用新内容替换目标文件时可以自动对即将被覆盖的旧文件做一份备份。该特性被命名为backup mode备份模式。它的典型价值在于托管/etc/ssh/sshd_config、Nginx 配置、应用配置文件这类关键文件时若新下发的 SLS 模板有误运维人员可以快速回退到备份前的内容而无需依赖外部版本管理或手工cp。这正是 Salt 将文件管理与灾备/回滚结合的经典能力之一。二、备份模式的启用位置与取值backup mode 的配置非常简单但它可以设置在多个层级满足全局默认与单文件覆盖两类需求。2.1 在 minion 配置文件中全局设置在 minion 的配置文件默认路径为/etc/salt/minion中加入backup_mode: minion从 salt/config/init.py 可以看到minion 配置中backup_mode的默认值为空字符串其类型约束为str见 salt/config/init.py。也就是说若未显式配置所有由 state 管理的文件默认不会产生备份一旦配置为minion全局的file.managed、file.recurse替换动作都会触发备份。2.2 在单个 state 中按文件设置每个文件也可以单独指定备份行为覆盖全局设置。例如/etc/ssh/sshd_config: file.managed: - source: salt://ssh/sshd_config - backup: minion此处file.managed状态的backup参数默认值为见 salt/states/file.py含义与全局backup_mode一致即不传时不做备份。传入minion后即使 minion 配置中未设置backup_mode该文件也会被备份。2.3 backup_mode 的三种取值取值行为说明minion备份到 minion 本地唯一已完整实现的模式备份文件存放在 minion 的 cachedir 中master备份到 master规划中的模式尚未实现当前实际上什么都不做both同时备份到 master 和 minion是 master 与 minion 的组合受限于 master 模式未实现实际仅产生 minion 侧备份从源码中可以清晰印证这一行为。在 salt/utils/files.py 的copyfile函数中备份逻辑如下bkroot if cachedir: bkroot os.path.join(cachedir, file_backup) if backup_mode minion or backup_mode both and bkroot: if os.path.exists(dest): backup_minion(dest, bkroot) if backup_mode master or backup_mode both and bkroot: # TODO, backup to master pass可以看到minion分支会调用backup_minion()真正落盘备份而master分支只有一行# TODO, backup to master注释属于尚未实现的功能占位。因此在实际生产环境中both与master的期望行为master 侧备份目前不会发生读者应默认使用minion。三、备份文件的存储位置与命名规则启用备份后被替换的旧文件会保存到minion 的 cachedir下名为file_backup的目录中。常见路径为/var/cache/salt/minion/file_backupcachedir 因发行版与安装方式而异可通过salt-call config.get cachedir确认。目录结构与文件命名遵循两条规则保留原始路径的相对位置备份文件存放于file_backup下与原文件路径对应的相对目录中。例如原文件为/etc/ssh/sshd_config则备份位于file_backup/etc/ssh/下原文件为/tmp/foo.txt则备份位于file_backup/tmp/下。这使备份目录可以直接按原路径浏览非常直观。文件名追加时间戳备份文件名形如foo.txt_Sat_Jul_27_17:48:41_738027_2013由原文件名、星期、月份、日期、时分秒、微秒级时间与年份拼接而成天然按时间可排序。backup_minion()的实现细节见 salt/utils/files.py它先剥离原文件的父目录Windows 上还将盘符冒号替换为下划线以规避非法路径字符再拼接时间戳生成备份路径并保留原文件的属主与权限位。这意味着恢复备份后文件的所有者与权限模式与备份时刻保持一致。四、与备份交互列出、恢复与删除自 Salt 0.17.0 起可通过三个执行模块函数对既有备份进行管理。它们的源码均位于 salt/modules/file.py且都声明了versionadded:: 0.17.0。4.1 列出备份file.list_backups使用file.list_backups查看某个文件的全部历史备份用法为salt foo.bar.com file.list_backups /tmp/foo.txt输出示例foo.bar.com: ---------- 0: ---------- Backup Time: Sat Jul 27 2013 17:48:41.738027 Location: /var/cache/salt/minion/file_backup/tmp/foo.txt_Sat_Jul_27_17:48:41_738027_2013 Size: 13 1: ---------- Backup Time: Sat Jul 27 2013 17:48:28.369804 Location: /var/cache/salt/minion/file_backup/tmp/foo.txt_Sat_Jul_27_17:48:28_369804_2013 Size: 35返回的字典以数字索引为键0代表最新的备份每条记录包含Backup Time备份时间、Location备份文件绝对路径与Size字节数。源码 salt/modules/file.py 还支持可选的limit参数用于只显示最近 N 份备份例如salt * file.list_backups /foo/bar/baz.txt limit5list_backups还提供了别名file.list_backup见 salt/modules/file.py两者等价。4.2 恢复备份file.restore_backup恢复时只需传入文件路径与file.list_backups返回的数字 idsalt foo.bar.com file.restore_backup /tmp/foo.txt 1输出示例foo.bar.com: ---------- comment: Successfully restored /var/cache/salt/minion/file_backup/tmp/foo.txt_Sat_Jul_27_17:48:28_369804_2013 to /tmp/foo.txt result: Truerestore_backup的实现salt/modules/file.py会先调用list_backups校验backup_id是否存在然后执行两个动作调用salt.utils.files.backup_minion()把当前存活的文件再次备份一份以防万一用shutil.copyfile()将选中的备份内容复制回原路径并尝试恢复属主信息。因此恢复操作是幂等且安全的——恢复前当前的版本也会被留存。例如恢复后再次执行file.list_backups会看到最新的备份原文件内容被排到索引00: Backup Time: Sat Jul 27 2013 18:00:19.822550 Location: /var/cache/salt/minion/file_backup/tmp/foo.txt_Sat_Jul_27_18:00:19_822550_2013 Size: 53 1: Backup Time: Sat Jul 27 2013 17:48:41.738027 ... 2: Backup Time: Sat Jul 27 2013 17:48:28.369804 ...注意恢复不会触发 watch 联动。由于恢复动作不经过 state 系统因此文件恢复不会触发针对该文件的任何watch/require关联。如果你恢复的是某个服务的配置文件恢复后通常仍需要手动执行service.restart或运行对应的 service 状态让服务重新加载新配置。这是 restore 与常规file.managed状态最大的行为差异务必在自动化脚本中补齐重启步骤。4.3 删除备份file.delete_backup删除某一份备份同样按 id 操作salt foo.bar.com file.delete_backup /tmp/foo.txt 0输出示例foo.bar.com: ---------- comment: Successfully removed /var/cache/salt/minion/file_backup/tmp/foo.txt_Sat_Jul_27_18:00:19_822550_2013 result: Truedelete_backupsalt/modules/file.py通过list_backups拿到 id 对应的Location后删除该备份文件。注意 id 与备份的对应关系因为新备份总是插到最前索引号会随新增备份发生偏移所以在删除/恢复前建议先执行一次file.list_backups确认当前索引。五、实践建议与常见问题默认使用minion模式master 与 both 模式中 master 侧备份尚未实现源码中为TODO占位不要把回滚依赖建立在这两种模式上。合理规划缓存盘空间每次file.managed触发内容变更都会在file_backup下新增一份完整拷贝长期运行可能占用可观磁盘可定期用file.delete_backup清理过期版本或结合定时任务如 cron / Salt 的 schedule统一维护。恢复后记得重启服务restore 不触发 watch配置类文件恢复后需显式执行service.restart。配合源路径浏览备份目录与根文件系统同构如file_backup/etc/nginx/、file_backup/opt/app/排查问题时可直接按原始路径层级查找。六、相关参考状态定义file.managed的backup参数与file.recurse见 salt/states/file.py备份核心实现salt.utils.files.copyfile与backup_minion见 salt/utils/files.py、salt/utils/files.py管理命令实现file.list_backups/file.restore_backup/file.delete_backup见 salt/modules/file.pyminion 默认配置项backup_mode默认空值见 salt/config/init.py赞分享运维配置管理后端【免费下载链接】saltSoftware to automate the management and configuration of infrastructure and applications at scale.项目地址https://gitcode.com/gh_mirrors/sa/salt点击查看免费下载相关推荐DeepEval LLM评估框架5分钟跑通第一次模型质量测试DeepEval LLM评估框架5分钟跑通第一次模型质量测试 DeepEval 是一个开源的 LLM 评估框架 把大模型输出当成可测试对象写测试用例、用人工智能大模型模型评测AI 评测测试红蓝对抗提示工程Matter设备状态恢复出厂重置与配置备份在智能家居系统中Matter设备原Project CHIP的状态管理是确保设备稳定运行的关键环节。当设备出现连接故障、配置错误或需要转移所有权时 出厂重物联网智能家居嵌入式通信Orchestrator备份与恢复确保配置和状态数据安全的完整指南Orchestrator备份与恢复确保配置和状态数据安全的完整指南 Orchestrator作为MySQL复制拓扑管理和高可用性解决方案其配置数据和状态信息后端数据库上一篇GitBucket数据备份云存储集成与异地容灾方案下一篇QuickRecorder7 种录制模式的免费 macOS 屏幕录制工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考