Data Maintenancev7.0.20
What the appliance keeps, for how long, and how you get it back: retention policy, partition pruning, configuration backups — and the private key without which no restore is possible.
A monitoring appliance is a history machine, and history has a size. This page covers the three instruments that keep the appliance’s storage healthy — retention policy, partition management, and backups — and the restore path you hope never to walk.
Database Retention
The Database Retention card lists each rolling measurement family with its current size and its retention in weeks. Among them are disk, latency, interface, performance, and the per-tracker families, plus the traffic record — Network Activity (the flow conversations behind the NetFlow stream, the topology map, and the traffic reports) and Protocol Analysis (the packet analyzer’s per-protocol statistics) — and Name Resolution. Data older than the setting is removed automatically, continuously. The card’s size column is your capacity-planning dial: the traffic families are routinely the largest, so their retention settings are where appliance storage is won and lost; lengthen retention for families you report on long-term, shorten what nobody reads twice.
Database Partition Management
The high-volume log families — syslog, Windows event logs, IDS events, and collected sensor history — are stored in weekly partitions and are not expired automatically. They accumulate until an operator prunes them, by design: log and security history is evidence, and discarding evidence is a human decision.
The Database Partition Management card shows the partitions and their sizes, and prunes everything older than the number of weeks you specify, in one explicit action.
Pruning partitions is immediate and irreversible — the appliance does not keep a recycle bin of dropped history. Confirm any compliance or investigation obligations before pruning, and take a backup first if the history has lasting value.
Backups
The Backup card keeps configuration backups of the appliance: the device inventory, settings, users, alerting configuration — everything you authored. Backups are entirely manual — Create Backup takes one, each row offers download and delete, and nothing runs on a schedule. The discipline is therefore yours:
- Make backing up a routine. Put it in your own calendar — after every configuration session, and on a recurring reminder besides. An appliance whose last backup predates its last change is unprotected exactly where it matters.
- Keep a copy off the appliance. Download backups to your own backup estate. A backup that lives only on the machine it protects is a hope, not a plan.
- Back up before you change. Take one immediately before bulk edits, upgrades, or experiments — the five seconds it costs is the cheapest undo you will ever buy.
The private decryption key
The appliance encrypts the secrets in its configuration — device credentials, outlet tokens — and the private key that unlocks them is offered for download on this card, to a super-administrator, normally during first-time installation (see Installation & First Sign-In). A full restore requires a backup file and this key: a backup without the key restores an appliance whose stored credentials cannot be decrypted.
Handle it like a crown-jewel secret: download it once at install, store it in a secrets vault alongside your other most sensitive material, and then delete it from the appliance using the card’s delete action. It is the key to the configuration’s secrets and should not sit on the box it protects.
If your appliance is past first install and nobody can produce the key, treat that as an open risk: raise it with support now, not during an outage.
Configuration backups deliberately exclude the bulk measurement and log history — that is what keeps them small enough to take often and keep forever. History protection, where required, is the partition card’s and your storage estate’s job.
Restoring
A full restore needs two things you prepared earlier: a backup file and the private decryption key. The restore itself is driven by the same out-of-band assistant that handles operating-system upgrades (see Software Updates & OS Upgrade), because a restore is the one operation that must keep working while Netmon itself is stopped:
- Have the appliance (or its replacement) at the same software version the backup was taken on, with your backup file and the private key at hand.
- From the System Upgrade card under System → System Settings, install and start the assistant. The card shows a one-time access token — it is displayed once, like everything on this page that matters.
- Open
https://<appliance-address>:7443/in a browser, enter the token, and choose the restore flow. - The assistant takes a pre-restore safety snapshot of the current state — the rollback target if anything goes wrong — then stops the monitoring services, replaces the configuration and database with the backup’s contents, and brings Netmon back up.
Monitoring is down for the duration; plan it like the small maintenance window it is. If anything about the situation is unusual — a failed disk, a replacement chassis, a version mismatch — involve support before step 2 rather than after: the safety snapshot can only protect what still exists when it is taken. What makes any of this possible is the discipline above: recent backups, stored off-box, with the key safe.
The out-of-band assistant that performs restores is the same one that performs OS upgrades. For a screen-by-screen walkthrough of its interface, see the System Upgrade Guide.