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!