ENSP学习记录（6）

这四个实验里，文件管理这两个看起来最没意思------又不涉及网络，纯敲命令。

但它们是唯一两个让我"惊了一下"的实验：一个是删掉的文件居然能救回来，另一个是明明保存了、重启后配置却没变。

这两个"惊"背后，其实是同一件事：运行配置、配置文件、启动文件，是三样不同的东西。

实验三：删文件、恢复、真删

命令很简单，一共六条

复制代码

<R1>dir
<R1>save
<R1>copy vrpcfg.zip backup.zip
<R1>delete backup.zip
<R1>undelete backup.zip
<R1>reset recycle-bin

拓扑里只有一台 AR1，全部操作都在设备自己的 Flash 上完成，不涉及网络。

第 1 步：先看看当前有什么

dir 之后我看到：一个 dhcp 目录，三个系统自带文件（portalpage.zip、statemach.efs、sslvpn.zip），总容量 1,090,732 KB，剩余 784,464 KB。

没有 vrpcfg.zip。

这个"没有"很关键------说明这台设备还没保存过配置。刚启动的设备，配置只在内存里，Flash 上什么都没有。

第 2 步：save 之后再看

多了两个文件：private-data.txt（249 字节）、vrpcfg.zip（520 字节）。

剩余空间从 784,464 KB 变成 784,448 KB。

这一步就把 save 干的事说明白了 ：把内存里的运行配置打包成 vrpcfg.zip，写进 Flash。

配置才 520 字节，因为那时几乎没配东西。真实设备上一般几十 KB。

第 3 步：复制一份，当备份

复制代码

<R1>copy vrpcfg.zip backup.zip

backup.zip 出现，520 字节。

这一步在真实运维里很常用：改配置前先备份一份，改坏了拿它回滚。

第 4 步：删掉它 ------ 然后我发现不对劲

复制代码

<R1>delete backup.zip

提示删除成功，dir 里确实看不到 backup.zip 了。

但我看了一眼剩余空间：还是 784,448 KB，一点没变。

我当时的第一反应是命令没执行成功，又删了一次。其实这里藏着 VRP 的一个设计：delete 不是真删，只是把文件扔进回收站。

文件还在 Flash 里，只是目录列表里看不见了。所以空间一点没释放。

判断是不是真删，有个土办法：看 dir 后面的剩余空间。 删完空间没变，说明文件还在；空间变了，才是真没了。

第 5 步：救回来

复制代码

<R1>undelete backup.zip

backup.zip 原样回来了，还是 520 字节。

看到它回来的时候我是真有点惊讶。只要没执行过彻底删除，误删的配置都还有救。 这在真实运维里是能救命的------改坏一台设备，配置删了，还有一次机会。

第 6 步：真的删掉

复制代码

<R1>reset recycle-bin

这次空间才真正变化：784,448 → 784,452 KB，回收了 4 KB。

只有 4 KB，因为文件太小。但逻辑验证了：reset recycle-bin 才是真正释放空间的动作。

一句话总结实验三

delete 是"扔进回收站"，reset recycle-bin 才是"倒垃圾"。

命令	相当于 Windows 的
`delete`	Delete 键
`delete /unreserved`	Shift + Delete（不进回收站）
`undelete`	右键"还原"
`reset recycle-bin`	清空回收站

实验四：存了配置，重启后为什么没变

这个实验是我卡得最久的一个。

我干了什么

先改设备名制造一点"痕迹"：

复制代码

<R1>system-view
[R1]sysname AR1

然后用自定义文件名保存：

复制代码

<R1>save my_config.zip

再重启：

复制代码

<R1>reboot

结果重启完，配置没变。

我当时的第一反应是"save 没成功"。但 dir 里明明有 my_config.zip。文件在，配置却没生效------这就很奇怪了。

问题出在哪

关键在 display startup 这条命令上。它显示两行：

复制代码

Startup saved-configuration file:      flash:/vrpcfg.zip
Next startup saved-configuration file: flash:/vrpcfg.zip

系统只认这两行里写的那个文件。

我 save my_config.zip 只是往 Flash 里多放了一份文件，并没有告诉系统"下次启动读它" 。系统照旧读 vrpcfg.zip，所以重启后一切如常。

原来 save 和"下次启动用哪份"是两件独立的事。

补上缺的那一步

复制代码

<R1>startup saved-configuration my_config.zip
  Info: Succeeded in setting the file for booting system

再查一次：

复制代码

Startup saved-configuration file:      flash:/vrpcfg.zip
Next startup saved-configuration file: flash:/my_config.zip

两行不一致了：本次还是 vrpcfg.zip，下次是 my_config.zip。 这个差异就是这条命令的全部作用。

这时候再 reboot，重启后读的就是新文件了。

三个动作，各管一段

命令	作用	改的是
`save [文件名]`	把运行配置写进 Flash 文件	"文件里有什么"
`startup saved-configuration 文件`	指定下次启动读哪个文件	"下次读哪份"
`reboot`	重启设备	让"下次"变成"本次"

我的记法：save 决定"文件里有什么"，startup 决定"下次读哪份"，reboot 才让"下次"到来。

三道工序，漏一步，重启后看到的都不是你以为的那份配置。

一个必须提醒的风险

startup saved-configuration 指向的文件必须真实存在、内容完整。

如果你指定之后又把它删了或改坏了，设备下次启动会找不到配置，可能直接以缺省配置启动------管理地址、密码全没了，只能去 Console 口救。

所以：指定前先 dir 确认文件在。 这一步花不了几秒，但能省掉一次现场救援。

我在这两个实验里踩的坑

删完文件空间没变，以为命令没生效，重复删了好几次。其实那才是正常的。
save 用了自定义文件名，重启后配置没变 ------少了一步 startup saved-configuration。
别拿系统自带文件做实验。 portalpage.zip、sslvpn.zip 是设备自带资源，删了可能影响功能。要造文件，自己 save 一个出来再玩。
reboot 前会问你要不要保存当前配置，别顺手按 y。想清楚你要的是哪一份。

一点学习心得

这两个实验的收获，跟网络技术本身关系不大，但可能是这一章里最"工程"的部分。

第一，删除是有层级的。 我们平时用电脑也有回收站，但很少去想"删除"和"释放空间"是两件事。设备上这点更明显，因为它会把剩余空间直接摆在你面前。

第二，"保存"这个词是模糊的。 save 保存到文件，startup 保存到"下次启动"，reboot 才是真正生效。中文都叫"保存"，但干的是三件事。遇到一个模糊的词，就把它拆到不能再拆为止------这个习惯我后来越用越顺手。

第三，风险意识是从"如果错了会怎样"长出来的。 我一开始觉得"指定启动文件"只是个普通配置，直到想明白"如果这个文件没了会怎样"，才意识到这条命令的分量。

后面做路由实验也一样：每次改配置前，先想一句"改错了怎么退回去"。