Hello fellow networkers.
I had an issue where I accidentally blew out the file-system on a switch. My config.text, vlan.dat, etc. I had some help along the way during this time but I didn’t keep notes, it was late at night and we just wanted to get the files back onto the switch. Needless to say, it got done but I wanted to know if there are any best practices or techniques for this type of issue. Any info would be helpful in case i do this again…
Hello Wesley,
Backing up your configurations on any network equipment is a best practice. You can do this automatically on a Cisco router or switch. I will leave a link below. A lot of customers I work with don’t change their network configurations constantly, so what I do is backup the config before I install any new equipment, I keep a copy of this config on a NAS I own and onsite on a customers server. Also, something else I do is BEFORE I MAKE ANY CHANGES ON PRODUCTION EQUIPMENT I backup the config files, this way if I make a mistake I can easily go back to the way things were. After I am done making changes and things are running smoothly, you guessed it I make a backup. You can never have too many backups.
I hope this helps,
Scott Weller
Hello Wesley
Scott has it nailed down. His procedure is very air-tight and is sufficient for all contingencies. Using the same commands and mechanisms described in the link he shared, you can also backup all the rest of your files, like the files you lost in your scenario. You can use the same commands and the same protocols (ftp, tftp) to do that.
Now for files such as the IOS .bin file which is in the flash drive, you can use the flash: prefix before the file name to back that up. You need backup the IOS only once since that doesn’t change (unless you upgrade). Other files like the vlan.dat may require a backup more often depending on how often you change VLAN configs.
You can develop your own backup scheme, but possibly the simplest is to back up all files (except for the IOS .bin) periodically so you don’t have to have a different backup scheme for each type of file. I agree with Scott, you can never have enough backups, just make sure they’re organised so you can get to what you need when you need it.
I hope this has been helpful!
Laz
Thanks for the responses.
I always back up my configs. My issue was I deleted the files from flash:/ (all of it)
We had to rebuild the config.txt and vlan.dat etc from scratch. We never reloaded the switch so it wouldn’t load in rommon (or at all). So all of the files you see below, were deleted. I understand that backing up the config is key but things happen during late night implementations. I was thinking of the next time I do something like this (hopefully never) is to TFTP the config.text, vlan.dat, for the switch etc, along with the switch config.
Directory of flash:/ (went from this)
2 -rwx 6914 Jun 9 2018 00:56:39 +00:00 config.text
3 -rwx 616 Feb 7 2017 17:47:53 +00:00 vlan.dat
4 -rwx 21284864 Jun 5 2018 20:08:35 +00:00 c2960x-universalk9-mz.152-2.E7.bin
674 -rwx 3096 Jun 9 2018 01:09:08 +00:00 multiple-fs
6 -rwx 1916 Jun 9 2018 00:56:39 +00:00 private-config.text
7 drwx 512 Sep 17 2016 02:49:09 +00:00 c2960x-universalk9-mz.152-2.E5
672 drwx 512 Sep 17 2016 02:49:10 +00:00 dc_profile_dir
to this
Directory of flash:/
EMPTY
How would you go about rebuilding the flash if you deleted it? The text files can be created again in flash. I was asking to see if there’s a way to do this, I cant recall at this moment.
Hello Wesley
Concerning the vlan.dat file, Cisco has a procedure for recovery. This takes into account whether the device was a VTP server or client or transparent, and it also takes into account the situation where the vlan.dat file is deleted, but the switch is still running with all of its vital info in RAM. Take a look, it may be useful:
As for the config.text file, if you have a backup of the startup-config file, you’re fine. If you copy a backed up version of the startup-config file to the device, the config.text file will also be regenerated. Switches maintain a startup-config file in NVRAM and an IDENTICAL config.text file in the flash memory. This is so because if you have to do a password recovery, you don’t have access to NVRAM from the recovery mode to change the password in the startup-config file, so it is the config.text file that you must modify.
That is absolutely the best practice that you can follow to ensure that nothing like what you experienced will happen again.
I hope this has been helpful!
Laz
Thank you to all who replied. Appreciate the advice.
Thank you Laz for the link.