At first glance, scripting can be a very convenient way to automate common network management tasks like backing up configurations. While it’s easy to create infinitely customisable scripts, this technique comes with quite a few drawbacks that make it unsuitable for backups.
Most companies have lots of equipment from a variety of different vendors. Even the most experienced network engineer will have trouble remembering everything they need to script accurate backups for the entire fleet of network devices. This is especially true if network engineers use scripts from the Internet instead of following manufacturer guidelines.
You can’t trust a backup unless you’ve tested it and verified that it restored everything. Unless your company has the budget to buy a test lab with all the same network devices, your first restore test might be during a real outage. Scripts don’t make it easy to test your backup and restore procedures without a completely separate test setup.
Network configuration files often use brittle, text-based formats that can suffer from human error. Just misplacing a comma or typing a few letters incorrectly can cause a backup to fail. Worse yet, you might not know that your backups have errors until you try to restore them in a real disaster scenario.
With a scripting-based backup solution, network engineers have to manually write code to handle errors. This limits the alert types you might receive to simple emails, rather than traps logged to Syslog or via SNMP. You also have the potential of receiving too many alerts for failed backups if devices can’t be reached temporarily, or no alerts at all, if your scripts don’t work, or don’t know about the most recent devices you added to the network.
When you write a network backup script, you’re basically writing code. As a result, you have to deal with all the challenges associated with maintaining a program over time: responding to changing requirements, adding support for more network devices, and changing backup techniques when manufacturers deprecate old methods. The entire process is unintuitive and error-prone.
For a backup to be useful, it has to be complete and easy to restore. Scripting-based network device backup solutions don’t make any promises about completeness and frequently aren’t robust enough to restore correctly if something unexpected happens.
Many companies put their network backups taken by scripts right on a network share for convenient access by engineers. Network device configurations often contain lots of sensitive data: passwords, private keys, and internal IP address information that attackers would find very valuable. Role-based identity and access management combined with secure encryption is a must, but these security features can be a challenge to implement yourself.
Computer backup systems (think Time Machine on Macs) are usually smart enough to take delta backups, where they only store changes from the last snapshot instead of a complete disk image. While many network device backups are are much smaller than computer files, when it comes to network device configurations, delta backups cannot be restored.
It’s therefore simple to assume that you need to keep 3 or 6 months worth of backups, but some vendors (including f5, Check Point, Cisco FirePower) produce Gigabytes of backups on a daily basis, and, the storage usage from lots of devices backed up daily adds up fast. A way of managing Configuration Versions is therefore needed to reduce the amount of storage required, scripts just aren’t smart enough to understand if your latest backup is new, contains changes or differs in size to the previous backup.
Restorepoint is a multi-vendor network configuration management solution that allows customers to quickly run network backups without manual scripts.