Scheduled Backups - Configuration Retention Best Practices?

[dyndelta78]

Hi all,
We're currently implementing scheduled backups across our network infrastructure using Unimus. We've noticed that some configuration changes, particularly those made through scripting or automation, seem to revert to previous states after a backup and subsequent device restoration.
We're keen to understand best practices for managing this, specifically:
* **Frequency of Backups:** How often should we be backing up devices? Are there recommended intervals based on the volatility of the configuration?
* **Exclusion of Specific Configuration Sections:** Is there a way to exclude certain sections of the configuration from the backup process? For example, dynamic routing protocols or temporary configurations used for troubleshooting.
* **Version Control:** How are others handling version control of configurations? Are you using Unimus' built-in features or integrating with external version control systems like Git?
* **Backup Retention Policies:** What are your retention policies for backups? How long are you keeping them and what criteria are you using to determine when to purge older backups?
* **Pre/Post Backup Scripts:** Are you using any pre or post backup scripts to manipulate the configuration or perform other tasks?
Any insights or examples you can share would be greatly appreciated. We're aiming to establish a robust and reliable backup strategy that minimizes the risk of data loss and ensures consistent device configurations.
Thanks in advance!

[Tommy.c]

We've noticed that some configuration changes, particularly those made through scripting or automation, seem to revert to previous states after a backup and subsequent device restoration.

If the backup is older than the most recent change, then yes you will lose those configuration changes that occurred after the most recent backup.

* **Frequency of Backups:** How often should we be backing up devices? Are there recommended intervals based on the volatility of the configuration?

This is highly dependent on your backup strategy, your equipment and your network.
If you are going to have frequent changes that you need to have backed up, you will want to increase the frequency of backups. The old adage of "save it or lose it comes to mind".

That said, some equipment can be burdened by too many backup requests. Backing up every couple of minutes is probably not realistic in many situations.

Lastly, while most networks can handle a massive number of SSH sessions, if you have bandwidth limitations or very high latency connections to some equipment you probably want to approach your backups with a bit more strategy.

I would recommend looking into triggered backups of your devices, Unimus's API allows you to initiate a backup from another application. A blog post we are working on shows how you can trigger Unimus to perform a backup from NetXMS when NetXMS receives a configuration change syslog message. This can be applied to any software that can take syslog messages and perform actions depending on their content.

* **Exclusion of Specific Configuration Sections:** Is there a way to exclude certain sections of the configuration from the backup process? For example, dynamic routing protocols or temporary configurations used for troubleshooting.

There is, we have a couple routes you can take to achieve this end, depending on your situation.

Backup Filters:
With backup filters you have two options, Ignore data filters and Delete data filters.
Ignore data filters will allow you to tell Unimus to save the data, but not make a change notification about whatever was changed.
Delete data filters allows you to remove configuration lines that meet certain criteria.
Both can be applied to entire Vendors, Device Types or Device Tags. Matching can be done via RegEx or beginning/end of line text.

Backup Flows:
Custom backup flows is the alternative option, you can create a unique backup flow for Vendors, Device Types or Tags that will only create a backup of the data you want.

If your situation is really complex, you may need to utilize both tools to make the backups you desire.

* **Version Control:** How are others handling version control of configurations? Are you using Unimus' built-in features or integrating with external version control systems like Git?

What are you trying to achieve?
Unimus' built in version control gives a good linear timeline of configuration changes.
You can also comment configuration changes inside of Unimus (In Backups you can select an individual backup). My understanding is that some companies are tying configuration changes with tickets by putting the ticket number into the comment.
You can also pull device backups from Unimus through the API, so you could do version control by integrating it with your existing system that way.

[ngocnhungplaza]

Great set of questions — we've gone through similar challenges when rolling out scheduled backups at scale.

Frequency: For core devices or anything with frequent changes (e.g., firewalls, routers in dynamic environments), we back up daily, sometimes even hourly if critical. For more static devices, weekly works fine.

Exclusions: Unimus doesn’t support selective config exclusion natively, but we handle this by filtering post-backup diffs and documenting which sections are "expected to change."

Version Control: We're using Unimus' internal diff/history for quick comparisons, but for long-term auditability, we sync exports with a Git repo using a custom script.

Retention: 90 days for daily backups, 1 year for weekly/monthly snapshots. We tag "known good" configs for long-term retention manually.

Pre/Post Scripts: We run a pre-backup script to normalize interfaces and temp settings, especially on devices that generate volatile config lines (e.g., session data, DHCP bindings).

Hope that helps — happy to share script examples if useful!

[Ales]

Hi all,
We're currently implementing scheduled backups across our network infrastructure using Unimus. We've noticed that some configuration changes, particularly those made through scripting or automation, seem to revert to previous states after a backup and subsequent device restoration.

It's near impossible to pinpoint the exact cause without more details, given the many unknown variables at play.

There are three key steps where things might be going wrong:

1.Configuration change: Are you perhaps missing a final "commit" command to save the new configuration to the running or startup state? Some devices have built-in rollback mechanisms that automatically revert to a previous state if a faulty config is detected.

2.Backup procedure: Did you define a custom backup flow or backup filter for the devices exhibiting this problem? Does the Unimus backup actually capture the configuration changes made in step 1? If it does, the issue likely lies in the next step.

3.Config rollback mechanism: Are you restoring the correct backup version to the device during the rollback? It’s possible you might be pushing the outdated config snapshot.

Let us know a bit more, and we'll try to help you sort this out.

* **Frequency of Backups:** How often should we be backing up devices? Are there recommended intervals based on the volatility of the configuration?

The ideal backup frequency typically depends on the criticality of the devices, the volatility of their configurations, retention policies and database size constraints.

While there are no rules set in stone, a daily backup schedule for all devices is often a straightforward and effective approach. It's also worth mentioning that Unimus only creates a new backup (or 'backup point') if the configuration has changed since the last backup. This prevents the accumulation of redundant backups when configurations remain static, conserving database space.

However, if your primary goal is to maintain a more comprehensive and reliable backup strategy, consider implementing triggered backups for critical devices. This involves configuring your devices to generate syslog or SNMP messages upon a configuration change, which can then be sent to an NMS capable of invoking the Unimus API to perform a backup.

A hybrid approach—combining triggered backups for high-priority devices with daily backups for the rest—can provide the best balance of reliability and efficiency.

Ultimately, the right strategy depends on your specific network environment and risk tolerance.

* **Exclusion of Specific Configuration Sections:** Is there a way to exclude certain sections of the configuration from the backup process? For example, dynamic routing protocols or temporary configurations used for troubleshooting.

Yes, this is entirely possible using the Backup Filters feature introduced in Unimus version 2.1.0. This feature allows you to exclude certain sections of your device configurations from the backup process, which is particularly useful for filtering out dynamic routing protocols, ephemeral configurations, or temporary troubleshooting commands.

You can read more about this feature here:

https://blog.unimus.net/new-backup-filt ... mus-2-1-0/
https://wiki.unimus.net/display/UNPUB/Backup+Filters

* **Version Control:** How are others handling version control of configurations? Are you using Unimus' built-in features or integrating with external version control systems like Git?

Just a quick note for those who may not be aware—we have a detailed guide for exporting backups from Unimus to GitHub or GitLab:

https://blog.unimus.net/unimus-backup-exporter/

* **Backup Retention Policies:** What are your retention policies for backups? How long are you keeping them and what criteria are you using to determine when to purge older backups?

When planning your backup retention strategy, you need to consider the storage capacity of your database. The speed at which your database fills up will depend on the number of devices, their volatility, and the chosen retention period.

For example, if you have 10,000 devices, each generating a 100kB backup once per week (assuming that the device configs actually change every week), and you plan to keep a year’s worth of history, the math looks like this:

Code: Select all

100kB * 1 change/week * 52 weeks * 10,000 devices = 52,000,000 kB (≈50 GB)

Adding a 20% margin to this result will give us a final estimate of 60 GB.

* **Pre/Post Backup Scripts:** Are you using any pre or post backup scripts to manipulate the configuration or perform other tasks?
Any insights or examples you can share would be greatly appreciated. We're aiming to establish a robust and reliable backup strategy that minimizes the risk of data loss and ensures consistent device configurations.

This is also possible through Custom Backup Flows, a feature in Unimus that allows you to define specific pre- and post-backup command sequences. These command sequences can be used to manipulate configurations, run preparatory commands, or perform clean-up tasks before or after the backup process. The outputs of these commands can be ignored or included in the backup, depending on your needs.

For more information, check out:

https://blog.unimus.net/custom-backup-f ... nimus-2-5/
https://wiki.unimus.net/display/UNPUB/Backup+Flows