每次从现场回来我都忍不住想骂一句为什么备份一个华三交换机配置这么简单的事非得一台台登录、复制、保存直到后来我写了一个批量备份华三交换机的脚本才真正从这种重复劳动里解脱出来。这个脚本很适合经常跑现场、或者在自驾出差途中需要处理多台华三网络设备的运维朋友。我把它从最初的一百行不到折腾到现在带校验、带日志、带失败重试整个过程里踩了不少坑借着这个机会把完整思路和代码都摊开来讲。1. 自驾出差场景下我为什么被批量备份逼到写脚本先说一个让我下定决心写脚本的真实场景。去年有一次凌晨出发自驾到三百多公里外的一个园区处理故障。现场三台华三接入交换机楼层对应关系完全靠记忆配置没人备份过。我登录上去一台台看VLAN、看trunk口、看STP优先级光摸清结构就用了一个多小时。事后我就在想如果出发前有个脚本能把这些设备的配置全部拉到本地我在路上就能先看一遍到现场直接动手改能省多少时间。手动备份的痛点干过运维的都懂。一台设备用SecureCRT或者Xshell登录输密码进系统视图保存配置然后执行备份命令再把文件拉回来重命名。十台设备一个多小时中间注意力一分散文件名写错、目录放错的情况时有发生。而且往往是到了现场才发现上个月改过配置但没备份能找回来的只有上次的完整备份中间全丢了。更现实的问题是自驾场景下网络环境很不稳定。你不可能指望现场随时有一个固定的FTP服务器或者网管平台等你去对接。设备经常是临时搭起来的管理地址也是现场规划的这时候靠一个能在笔记本上随时跑起来的脚本比什么都踏实。这就是我最初的动力在车上打开笔记本插上管理网线一条命令跑完所有设备配置落到本地目录文件名自动带IP和时间不用盯着屏幕。再说白一点备份这个东西本身不产生业务价值但它缺失的时候代价可能是整个网络的可用性。脚本的意义就是把这种高频率、低技术含量的操作从人肉变成自动化让人把精力放在真正需要判断的事情上。这篇博文讲的就是这件事从选型到实现从踩坑到完善给出一套可以直接拿去用的方案。2. 备份链路到底怎么选TFTP、FTP、还是SFTP华三交换机Comware平台备份配置常见的传输方式有三种TFTP、FTP、SFTPSCP同理。选择哪种直接决定脚本的复杂度和稳定性。我一开始图省事想直接租用现场的设备做FTP服务器结果发现很多老旧型号默认不启用FTP服务而TFTP反而是通用性最好的。2.1 三种方式的优缺点对比传输方式默认端口是否需要服务端加密华三设备支持程度适用场景TFTPUDP 69需要轻量TFTP服务端无几乎所有Comware版本都支持tftp命令和backup startup-configuration to tftp://语法临时拉取配置脚本自动化首选FTPTCP 21需要FTP服务端无明文大部分支持但部分设备默认关闭FTP服务有现成FTP服务器的固定环境SFTPTCP 22设备端需开启SSH并支持SFTP子系统有新版本设备支持但部分老型号需要额外配置对安全要求较高的长期备份场景实测下来TFTP是兼容性最好的。Comware V5和V7的老旧设备backup startup-configuration to tftp://这个命令基本都能用不需要在设备上额外开服务。缺点是不加密而且服务端要自己搭但这个在脚本里完全能解决。2.2 设备端需要做的准备如果你确实想用SFTP华三设备上一般要这样操作H3C system-view [H3C] ssh server enable [H3C] sftp server enable [H3C] local-user admin [H3C-luser-manage-admin] password simple YourPassword [H3C-luser-manage-admin] service-type ssh [H3C-luser-manage-admin] authorization-attribute user-role network-admin注意不同版本命令可能略有差异V7和V8版本中local-user下可能有user-role而非authorization-attribute user-role最好登录设备后用local-user ?看一下。2.3 TFTP服务器怎么搭脚本机器上要有一个TFTP服务端来接收设备推送过来的配置。Linux上我常用atftpd也可以用Python的tftpy库临时起一个。macOS上可以用brew install tftp-server这类方式。Windows下也可以用OpenTFTP。以Ubuntu为例起一个固定目录的TFTP服务sudo apt install atftpd # 编辑 /etc/default/atftpd确保目录存在并设置好权限 sudo mkdir -p /var/tftpboot sudo chmod 777 /var/tftpboot sudo systemctl restart atftpd脚本里则直接把设备备份命令指向这台机器的IP和共享目录。这样设备执行完backup命令后配置就会自动出现在本机目录下。实测下来TFTP传输小配置文件非常快基本秒级完成不担心性能问题。不过TFTP的坑在于文件是否完整落地、是否覆盖成功脚本必须主动去检查。否则设备那边喊成功这边文件是0字节照样白折腾。这个在后面实战踩坑部分会重点讲。3. 批量备份脚本的构成设备清单、SSH交互与文件回收整个脚本可以拆成三个核心模块设备清单、SSH自动登录交互、文件回收与校验。理解了这三个模块后面看代码就轻松了。3.1 设备清单设计最简单的方式就是一个纯文本文件每行记录一台设备的IP和管理名192.168.1.11 SW-F1-01 192.168.1.12 SW-F1-02 192.168.1.21 SW-F2-01IP后面跟的名称用于生成文件名比如SW-F1-01_192.168.1.11_20250614.cfg。这里有个小技巧设备名千万不要带空格否则脚本解析会出问题。如果现场没有设备命名规范也可以用默认的switch01这种。3.2 SSH自动登录交互expect的作用批量备份最大的门槛是SSH登录时的密码输入。bash自带的ssh命令无法自动输密码需要配合expect或者sshpass。expect的好处是可以精确控制交互过程包括首次登录时的指纹确认、密码提示、save命令确认等。华三设备的SSH登录提示一般是Password:登录成功后的用户视图提示符是设备名。我们需要在脚本里精确匹配这些提示符并做出响应。示例如下expect { password: { send $PASSWORD\r } yes/no { send yes\r; exp_continue } * { send \r } }exp_continue非常重要它会保持在当前expect块内继续匹配后续的提示符尤其适合处理首次指纹确认后再出现密码提示的情况。3.3 文件回收与校验当设备执行备份命令后文件会落地到TFTP目录。但写脚本不能只看设备端返回了什么还要在本地做二次确认。我的做法是检查文件是否存在。检查文件大小是否大于0。可选计算MD5或SHA256用于对比上次备份是否变化。这些校验逻辑看着不起眼但实际运维里假成功比真失败更可怕。等你要用备份配置恢复设备时才发现文件是坏的那才是真正的灾难。4. 可直接使用的完整脚本及逐段拆解下面给出一个我实际在用的版本。它依赖expect和atftpd或其他TFTP服务端核心逻辑是遍历设备清单逐台SSH登录执行华三设备的配置备份命令然后回收文件并校验。4.1 完整脚本#!/bin/bash ############################################################# # 批量备份华三交换机配置脚本 # 适用环境Linux / macOS (需装有 expect、TFTP 服务端) # 用法先启动 TFTP 服务再运行本脚本 ############################################################# # 配置区 DEV_LIST./devices.txt # 设备清单每行 IP 设备名 BACKUP_DIR./backup_$(date %Y%m%d) # 备份目录按天归档 TFTP_IP192.168.1.100 # 本机IP需与设备能互通 TFTP_DIR/var/tftpboot # TFTP共享目录 SSH_USERadmin # SSH用户名 SSH_PASSh3cpassw0rd # SSH密码建议通过环境变量传入 LOG_FILE./backup_$(date %Y%m%d).log # mkdir -p $BACKUP_DIR touch $LOG_FILE # 记录日志 log() { echo $(date %Y-%m-%d %H:%M:%S) $* | tee -a $LOG_FILE } # 处理单台设备 backup_device() { local ip$1 local name$2 local ts$(date %Y%m%d%H%M) local local_file${name}_${ip}_${ts}.cfg local remote_file${name}_${ip}_${ts}.cfg log 开始备份: $name ($ip) expect EOF set timeout 30 spawn ssh -o StrictHostKeyCheckingno $SSH_USER$ip expect { *password: { send $SSH_PASS\r; exp_continue } *Password: { send $SSH_PASS\r; exp_continue } * { } } # 先保存当前配置保证备份的是生效配置 send save force\r expect { *yes*no* { send y\r; exp_continue } * { } } expect * # 通过TFTP上传备份文件到本机 send backup startup-configuration to tftp://${TFTP_IP}/${remote_file}\r expect { *successfully* { send quit\r; exp_continue } *fail* { send quit\r; exp_continue } * { send quit\r } } expect eof EOF # 回收文件并校验 if [ -f $TFTP_DIR/$remote_file ]; then local fsize$(stat -c%s $TFTP_DIR/$remote_file 2/dev/null || stat -f%z $TFTP_DIR/$remote_file) if [ $fsize -gt 0 ]; then cp $TFTP_DIR/$remote_file $BACKUP_DIR/$local_file rm -f $TFTP_DIR/$remote_file log 备份成功: $local_file (${fsize} 字节) else log 文件为空备份失败: $remote_file fi else log 未收到TFTP文件备份失败: $remote_file fi } # 主循环 while read -r ip name; do [ -z $ip ] continue backup_device $ip $name done $DEV_LIST log 全部备份任务执行完毕。保存目录: $BACKUP_DIR4.2 关键代码段解释先看save force这一段。华三设备上直接执行backup startup-configuration备份的是启动配置但如果运行配置还没有保存备份出来的就是旧内容。所以脚本先执行save force强制保存当前配置然后再执行备份命令。这里的expect块处理了保存过程中的yes/no确认因为华三老版本可能会问是否覆盖现有配置文件。再看TFTP命令部分。华三交换机的标准命令是backup startup-configuration to tftp://服务器IP/文件名执行成功后设备会返回类似Backup the startup configuration file successfully.的提示。脚本的expect块同时匹配successfully和fail无论成功失败都正常退出SSH避免脚本卡死在设备终端上。这里不匹配*是因为设备返回可能带了回车直接匹配不通用successfully更准确。文件回收部分脚本默认TFTP目录和备份目录都设在本地所以在TFTP服务端文件落地后把它复制到按日期归档的备份目录同时删除TFTP目录里的临时文件避免下次备份时文件被覆盖。stat命令同时兼容了Linux和macOS的语法这是我在两类系统上都实测过的。4.3 运行效果设备清单准备好后直接运行chmod x backup_h3c.sh ./backup_h3c.sh输出大致长这样2025-06-14 21:05:01 开始备份: SW-F1-01 (192.168.1.11) 2025-06-14 21:05:07 Back up the startup configuration file successfully. 2025-06-14 21:05:08 备份成功: SW-F1-01_192.168.1.11_202506142105.cfg (12453 字节)4.4 没有TFTP服务端时的兜底方案有一次在车上临时处理笔记本没装TFTP服务端我就改用了一个更粗暴的方案用expect直接把display current-configuration的输出记录到本地文件。核心思路是登录后先执行screen-length disable取消分页然后log_file捕获后续所有输出最后用sed把交互提示符等噪声清理掉。这段代码适合应急但配置长时容易因为滚屏丢内容所以只是作为兜底。expect EOF set timeout 60 spawn ssh -o StrictHostKeyCheckingno $SSH_USER$ip expect *password: { send $SSH_PASS\r; exp_continue } expect * send screen-length disable\r expect * log_file /tmp/${remote_file} send display current-configuration\r expect { *---- More ----* { send ; exp_continue } * } log_file send quit\r expect eof EOF sed -i /^spawn/,$!d /tmp/${remote_file}这条命令的关键是用screen-length disable禁掉分页否则配置长一点就会卡在---- More ----上。清理阶段需要把登录时的提示符和回显命令删掉最简单的办法是用sed删除前几行或者直接保留文件从display current-configuration之后的部分。这个方案虽然糙但关键时刻真能救命。5. 实测中踩过的三个坑与完整排查记录写脚本最大的收获不是代码本身而是排错过程中对华三设备交互机制的理解。下面这三个坑每一个都让我调试了不短时间。5.1 坑一首次SSH连接指纹确认导致脚本卡死现象是脚本跑到第一台设备就直接卡住没有任何报错也不超时。手动SSH登录一切正常但expect脚本就是不动。排查过程我先打印了expect的调试信息把expect里的spawn改成exp_internal 1看交互过程结果发现设备返回的是Are you sure you want to continue connecting (yes/no)?而脚本里只匹配了password:没匹配yes/no所以等待密码提示的地方永远等不到直接挂起。解决方法是expect块里加上yes/no分支并且一定要用exp_continue继续匹配后续的密码提示expect { *yes/no* { send yes\r; exp_continue } *password:* { send $SSH_PASS\r; exp_continue } *Password:* { send $SSH_PASS\r; exp_continue } * { } }后来我还加了个更省事的方案SSH连接时直接加-o StrictHostKeyCheckingno参数跳过指纹确认。不过要注意这样会降低安全性只适合临时批量备份场景平时手动登录还是保留指纹校验好一些。5.2 坑二Comware V5和V7的备份命令语法差异第二台设备是Comware V5的老机子执行backup startup-configuration to tftp://...后设备直接提示% Unrecognized command。排查后发现V5老版本对这个命令的支持并不统一。部分版本要求写成backup startup-configuration to tftp://TFTP_IP/backup/xxx.cfg有些版本则直接不认backup命令需要改用最原始的tftp上传方式tftp 192.168.1.100 put flash:/startup.cfg SW-F1-01_xxx.cfg这个tftp put命令就是把设备flash里的startup.cfg文件上传到TFTP服务器的指定文件名下兼容性反而更好。我的解决办法是在backup_device函数里增加了一个参数区分设备使用的命令类型。设备清单里加一列类似192.168.1.11 SW-F1-01 v7 192.168.1.12 SW-F1-02 v5然后脚本根据这个字段执行不同的备份命令if [ $ver v5 ]; then send tftp ${TFTP_IP} put flash:/startup.cfg ${remote_file}\r else send backup startup-configuration to tftp://${TFTP_IP}/${remote_file}\r fi5.3 坑三TFTP文件落地不完整脚本却显示成功这个问题最隐蔽。现象是脚本每次都提示备份成功文件也生成了但打开备份文件发现里面只有十几行内容明显不是完整的交换机配置。排查后发现是设备端TFTP上传还没完成脚本这边expect匹配到了successfully就开始执行后续操作。华三设备的successfully提示实际上是在本地操作成功后立即打印的但TFTP上传到服务器完成还有一小段时间差。文件还在传输过程中脚本已经检查文件大小、复制文件自然拿到的是不完整文件。解决办法是在设备端完全退出SSH之后再等待1~2秒然后再去检查TFTP目录里的文件大小。更稳妥的做法是把期望大小和设备实际配置文件大小做对比但一般设备不直接暴露这个数值所以退而求其次用延时加非空校验expect eof sleep 2 # 再继续检查文件大小这个2秒在批量几十台设备时会累加不少时间但为了配置完整性是完全值得的。后来我改成先检查文件大小是否大于某个阈值比如1KB小于阈值就告警这个方案更实用。6. 让脚本从能跑到好用的增强细节脚本能备份之后事情远没结束。真正在自驾场景里反复使用逐渐沉淀出几个增强细节每一个都让脚本更贴近实战。6.1 增加日志与备份差异对比最初脚本的输出只有终端跑完就没了。后来我改成每次备份都写日志文件同时把备份文件的MD5记录到一个清单里。这样下次备份时能快速发现哪些设备配置变了优先关注变化大的设备。md5sum $BACKUP_DIR/$local_file | tee -a $BACKUP_DIR/checksums.md5如果之前有checksums.md5就可以用diff把新旧MD5清单对比一下配置变更的设备一目了然。这招在巡检场景特别有用算是白嫖了一个极简版配置变更检测能力。6.2 多网段设备通过跳板批量备份自驾去一些现场交换机的管理网段可能不止一个笔记本直连所有设备不现实。我的做法是在脚本里支持通过跳板机SSH连接或者通过Python的pexpect配合ProxyCommand实现。但这样会增加脚本复杂度和调试成本我的建议是如果能物理直连就直接直连非要跳板先用ssh -o ProxyCommand手动验证通了再把它固化到脚本里。6.3 安全建议别把密码硬编码在脚本里脚本里的SSH_PASS我从一开始就硬编码了但后来想了想这种脚本有可能从一个项目流传到另一个项目密码泄露风险是实打实的。改进方案是在脚本外设置环境变量export H3C_SSH_PASSyour_password ./backup_h3c.sh脚本内这样取值SSH_PASS${H3C_SSH_PASS:?请先设置 H3C_SSH_PASS 环境变量}另外设备清单文件建议用chmod 600限制权限不要顺手扔到Git仓库里。备份出来的配置文件同样属于敏感信息归档目录要定期清理别让设备配置在车上的旧笔记本里躺一年。6.4 定时任务与断点续备自驾出差场景经常是路上开车、晚上到酒店才有时间处理设备这时候可以配合cron设置定时备份。比如每天晚上十点跑一次第二天早上起来直接看目录里有没有新增文件就能确认设备状态。0 22 * * * /home/user/scripts/backup_h3c.sh断点续备我目前没做太复杂只支持失败重试。脚本里加上一个简单的重试机制某台设备备份失败时把它的IP重新追加到一个retry.txt脚本跑完后再次读取retry.txt重试一次。6.5 关于自驾场景下的小提醒最后说一个亲身教训在车上用笔记本连接交换机一定要先确认现场供电稳定避免设备在备份过程中掉电。TFTP传输中断导致的半截文件比没备份还坑人。另外USB转网口的转接器在Linux下的驱动不一定稳定我因为驱动问题卡了半小时差点以为脚本坏了。所以出发前先在家把转接器和虚拟机网络都测试一遍这个细节能省很多现场时间。这个项目看起来只是一个小脚本但它解决的是所有跑现场运维人员共同的痛点。做完了这套批量备份工具后我最大的体会是备份不是目的能够在需要的时候快速拿到准确的历史配置才是真正的价值。如果你的现场也有一堆华三交换机等着备份不妨直接拿这份脚本去改一改很快就会感受到自动化的甜头。