Backup Manager — install & user guide

Every device on your network holds a configuration that took someone a long time to get right. Backup Manager logs in to each of them on a schedule, takes that configuration away, and keeps every version it has ever seen. When a device fails you restore from last night. When something stops working you look at what changed and when.

It talks to equipment over SSH, including older kit that only accepts legacy ciphers, over Telnet for devices that offer nothing else, and over HTTP/HTTPS for firewalls with a config-export API. It runs on your own server — no cloud, no agent on the devices.

The dashboard — device and backup counts, storage used, server CPU, RAM and disk, and recent jobs.

Updating is one button on the Licence page, or one command on the server — see Updating. Your devices, credentials, archives and settings are kept.

Want a different port or a different place for the data? Pass them in:

Once you are in, go to Settings and set the password policy, session timeout and login lockout to whatever your organisation requires.

A new installation enrols itself for a 15-day trial the first time it can reach the licence server. The Licence & Subscription page shows the state, how long is left and how many devices the licence allows, and lists every feature with whether it is active.

To activate a purchased licence, paste the key Optimus Secure issued into Activate licence. The installation confirms it with the licence server before keeping it.

No route to the internet? Copy the machine fingerprint shown on the page, send it to Optimus Secure, and import the signed .lic file you receive — choose the file with Browse, or paste its contents. An offline term is spent in running time as well as by date, so moving the server clock does not extend it.

If the licence lapses, nothing already collected is locked away: stored backups stay readable and downloadable. New backups pause until it is renewed.

The Licence page — entitlement, activation and software updates. The data shown is an example, not a live network.

Store a login once as a credential set and attach it to as many devices as share it. Passwords and keys are encrypted at rest and never shown back to you — a credential can be used and replaced, not read.

The Credentials page is also the device address book. Each row carries the customer and site it belongs to, the vendor and model, and the protocol used to reach it. Two buttons open the device directly: the globe opens its web interface in a browser tab, and the console opens an SSH or Telnet session in the browser. Filter by customer to see only one client’s estate.

Adding a lot at once. Download the sample spreadsheet from the page, fill it in, and upload it: customers, sites, credential sets and devices all come in from one file. The preview shows what will be created and what will be skipped before anything is written.

Credentials and device access — one row per device, with browser and console access. The data shown is an example, not a live network.

The Devices page — every device with its host, platform, mode, schedule and retention.

On Devices, press Discover and give it a subnet in CIDR form, for example 172.26.10.0/24. It checks TCP 22, 23, 443 and 80 on every address and lists what answered, with the SSH banner where there is one. A /24 takes about a minute. Anything already in Backup Manager is marked already added so it cannot go in twice.

Choosing what to add

Tick the ones you want, or press Select all new and untick the few you do not. Every row also has Add this one: that opens the ordinary Add Device form with the address already filled in, so a single device gets every option that form has.

Adding a batch offers the same settings — platform, what to back up (including HTTP), exclude patterns, the enable password, schedule, retention, parallel sessions, tags, and whether they start enabled or paused.

One login for the lot

A rack of switches usually shares one account, so the form asks how to log in before anything else:

Choosing a saved set takes the username and password fields away and tells you which account it will use — the set supplies the login, so there is nothing to type. Everything else can be changed per device afterwards.

Naming the kind of device

The Platform list is a label used for grouping and for reading the device list, and it is not fixed. Choose + Add a platform… in any platform list, give it a name, and it is there from then on — for the switch vendor, appliance or box that is not in the list as shipped.

Manage the ones I added… in the same list removes them again. The names that came with Backup Manager stay, and one still in use by a device is kept until those devices are changed.

There is also Import CSV next to Discover, for when the list comes from somewhere else.

A profile says how to reach a vendor’s equipment: the transport, how to get past the login and any paging prompt, and which commands produce the configuration worth keeping. Profiles ship for the common vendors, and you can duplicate one and adjust it.

Test a profile against a real device from the profile itself — it connects, runs the commands and shows what came back, so you can tell whether the recipe works before attaching it to fifty devices. Profiles can be exported and imported between installations.

Device profiles — per-vendor recipes, testable against a real device. The data shown is an example, not a live network.

Each device has its own schedule, chosen from a time picker rather than written as a cron expression. Give different devices different times — or give them the same time and let the built-in stagger spread them out, so forty switches do not all get hit on the same second.

A job that fails retries on its own, with a growing gap between attempts. Jobs that are queued or running appear under Running Tasks with a live percentage, so you can watch a large copy progress instead of wondering whether it has hung.

Running Tasks — what is queued, what is running, and how far along it is.

Every backup is compared with the one before it. When the configuration differs, the Changes page records a version with a side-by-side diff, and classifies what sort of change it was — an access-list edit, a routing change, a new user, a credential — and how risky it looks.

Filter by device, customer, risk or kind of change, export the list, and mark a change as reviewed so the next person knows it has been looked at. A configuration that differs from the one before it can be kept forever regardless of retention; that is the default.

Changes — every configuration difference, classified and reviewable. The data shown is an example, not a live network.

A rule is a pattern that must appear, or must not appear, in a device configuration — no Telnet, an NTP server set, logging enabled, no default community strings. Rules ship with the product and you can add your own.

Checks run after every successful backup, so the page is current without a separate scan. Findings are weighted by severity into a single score, and each one can be re-checked, remediated, or given a recorded exception with a reason — an exception is a decision, so it is counted and shown rather than hidden.

Compliance — findings by severity, with remediation and recorded exceptions. The data shown is an example, not a live network.

The Backup Storage page lists every archive with its device, customer, size, age and integrity. Open one to see the files inside without downloading it, or download it as a zip.

A downloaded archive keeps the folder structure the files had on the device, so extracting it at the root puts everything back where it came from. Nothing is renamed or flattened.

Verify re-reads an archive and compares it with the checksum recorded when it was written. A mismatch is recorded as a mismatch — the stored checksum is never overwritten by what was found, or a tampered archive would read as verified ever after. Mark an archive keep and retention will leave it alone.

Backup Storage — every archive with its size, age and integrity. The data shown is an example, not a live network.

Open Config Push. The page is three steps on one screen: what to send, where to send it, and what happens around it.

1 · What to send

Type the commands one per line, exactly as you would type them into PuTTY. Nothing is added or rewritten — if the change needs enable, configure terminal and write memory, those are lines you type. A line starting with # is a note to yourself and is not sent.

A command can carry values that differ per device: {{name}}, {{host}}, {{username}}, {{platform}} and {{tags}}. Sets you use often can be saved by name and loaded again.

2 · Where to send it

Tick the devices. Search by name or address, narrow by platform, or use Select shown to take everything the filter is showing. Nothing is ever sent to "all devices" by default — the Push button stays disabled until you have chosen, and it tells you how many it will reach.

3 · Try it on one device first

Try on one device opens a live session to a single device from your selection. Press Run my commands here and you watch the device answer line by line. There is a box at the bottom to type anything else you want to check, and the session stays open while you do. When it looks right, Looks good — push to N takes you straight to the rest.

This is the same code that runs the real push, so what you see here is what the other devices will do.

Just opening a device

Every device in the list has a Console button, and there is an Open a device console button with the others. Either one opens a real terminal on that device — no commands to write first, nothing to select.

It behaves the way PuTTY does, because every key you press goes straight to the device rather than being collected into a line first:

Paste sends a block of text — a config stanza, for instance — as if it had been typed, and Maximise gives the session the whole window. The device is told the new size, so it wraps and pages to what you are actually looking at. The same button is on the configuration viewer.

What happens around the change

While it runs, and afterwards

Each device gets a row: waiting, running, done, failed or skipped, how far through the set it got, and how many configuration lines changed. What happened opens the full transcript for that device — every command and everything the device said back. You can stop a push part way; devices already changed stay changed, and the rest are skipped.

When a device says no

A device that answers Invalid input, % Incomplete command or command not found is marked failed rather than counted as a success, and the rest of the set is not sent to that device — running the remaining commands after one was refused is how half a change gets made.

The row tells you both things you need: how many commands went in before it stopped, and what the device actually said. The same reason appears against the run in Recent pushes, so you do not have to open anything to see it.

Config Push needs the operator or administrator role. A viewer cannot open it.

Before it runs. A push is checked first: the page shows which devices would be affected, how risky the change looks, roughly how long it will take, and any syntax it cannot make sense of. A push can require approval from another administrator and can be scheduled for a window — both are real gates, not labels, and nothing runs until they are satisfied. Every push keeps a rollback.

Config Push — pre-flight checks, risk, approval and scheduling. The data shown is an example, not a live network.

The Reports page opens with the figures worth knowing: backup success rate against the period before it, how many devices are genuinely protected, the compliance score, and how much is stored. Underneath, a daily chart separates successful, failed and partial runs, and a donut breaks compliance results down by severity.

Choose a report type, a period and a format — PDF to send, CSV to work with — and generate it. Pick a customer and the whole document is limited to that customer’s devices, which is what you want when the report is going to them rather than to you.

Generated reports are kept exactly as they were handed over, so the copy you send and the copy you keep are the same file. A schedule can email one weekly or monthly; the page says plainly when no email channel exists yet, because a schedule without one saves but delivers nothing.

Reports — the figures, the daily trend, and reports kept as they were handed over. The data shown is an example, not a live network.

Health is the page to open first thing. Four figures across the top — critical issues, warnings, what is in the queue, and the success rate over the last 24 hours — and the first three filter the table when you click them.

The Needs attention table is a work queue rather than a report. Each row names the device, its vendor and site, what went wrong, when it was last seen and how many times in a row it has failed. Two buttons sit on every row:

Tick several devices and back them up together; they are spaced out the same way a schedule spaces its devices, so selecting forty does not open forty sessions at once.

A device set to copy paths with none listed is flagged before it fails, rather than after three failures — it would collect nothing if it ran.

Below the table: what is running and waiting, the health of each place backups are kept with when it was last verified, and the recent run history. Set up notifications under Settings → Notifications so you do not have to look — email, a webhook or Slack, on failure, on a configuration change, or as a daily summary.

Health — critical issues, warnings, the queue, and per-row Diagnose and Retry. The data shown is an example, not a live network.

Under Settings you can point Backup Manager at S3-compatible storage and have every archive mirrored there automatically. If the backup server itself is lost, the backups are not.

Retention keeps the disk from filling up. As well as a simple age limit per device, there is a grandfather-father-son scheme that keeps a number of daily, weekly and monthly copies — so you keep a year of history without keeping a year of daily archives.

Settings are grouped into cards — Execution, Retention & Lifecycle, Storage & Integrity, Security Defaults and Device & Compliance — and each field says what it does underneath it. A setting that only matters because of another is dimmed with the reason shown: the GFS copy counts, for instance, only apply when the retention policy is set to GFS.

Edits are held as a draft. Nothing changes until you press Save changes, Discard puts everything back, and leaving the page with unsaved work asks first. Turning off archive encryption, checksums or SSH host-key checking asks for confirmation, because each one removes a protection.

The System health panel beside the form shows the settings that matter most — encryption, checksums, host-key policy, whether email can actually be delivered, and when the settings were last exported. Anything not in a good state explains why, and clicking the row jumps to the setting.

Under Maintenance you can export every setting to one file and import it again — useful before a change, or to set up a second server the same way. The file holds settings only, not devices, credentials or archives.

Settings — grouped cards, a draft that must be saved, and a system health panel. The data shown is an example, not a live network.

Every account has a role, which decides what it may do; a set of modules, which decides what it can reach at all; and optionally a customer, which decides whose devices it can see.

Narrowing an account. Pick the key icon beside a user and tick the modules it should reach, grouped as Core, Operations, Governance and Administration. This is enforced on every request, not merely hidden from the menu — a narrowed account that asks for a page it does not have is refused. The navigation is built from the same list, so it only ever offers what will work.

Limiting an account to one customer. Set a customer on the account and it sees only that customer’s devices and backups — on the dashboard, in the device list, in backup storage and in credentials and access. Asking for another customer by name or by id returns nothing. A view that cannot yet be limited that way is refused rather than widened, and the Customer access tab lists exactly which views a limited account can open.

Disabling an account ends its current session immediately, not at its next sign-in. Every action is recorded in the audit log, and sign-ins — successful or not — in the login history. For scripts and monitoring, create an API token under Settings rather than sharing an account password.

Users and access control — role, modules and customer, with the feature list that is actually enforced. The data shown is an example, not a live network.

From the dashboard

Open Licence and press Check for updates. If a newer release exists you get the version, its size, when it was published and what changed — and an Install update button next to it.

The page follows the update as it runs. Part way through, the service restarts — that signs you out, which is expected. Sign back in and the Licence page picks the update back up and tells you how it ended.

From the terminal

The same update, run by hand. It asks the licence server what is available, shows you the release notes, and installs it if you say yes. The download is checked against a published SHA-256 and refused if it does not match, so a tampered mirror cannot push code onto your server.

What happens to your data

Your database is copied aside first, the new version is put in beside the old one, and the service is switched over. If the new version does not come up healthy, the old one and the database go back automatically — by either route. Backups, configuration and history are never replaced.

The quickest thing you can send us is the output of sudo journalctl -u backup-manager -n 200 along with the device name and what you were trying to do. For a device that will not connect, the Test Connection transcript tells us most of what we need.