Network backup for large-scale networks
At scale, backup is a discipline, not a copy. Windows that keep closing, every config versioned and diffable, and a fast route back to a known-good when a change goes wrong.
100% of devices captured on cadence, every config versioned and diffable.
01 · WINDOW Closes On Timescheduled · parallel02 · VERSION Versioned Alwaysevery poll, kept03 · DIFF Line-By-Line Diffany two versions04 · RESTORE Known-Good Restorefast, verified
Every device captured on cadence and versioned, so a known-good is always one restore away, not a reconstruction.
- 100%of devices on cadence
every device, every window
- ~200kdevices backed up
single Tier 1 ISP deployment
- 0silent overwrites
every config versioned and diffable
- 24/7scheduled collection
windows that keep closing
Figures describe how rConfig operates; deployment-specific results are published with customer permission.
Backup is a discipline, not a copy
At a few hundred devices, configuration backup is a copy job. At large scale it becomes a discipline. The question is no longer whether you can pull a config; it is whether every device is captured on a cadence you can defend, whether you can see exactly what changed, and whether you can put a device back the way it was when a change goes wrong.
The context for all of this is size. For how the platform itself holds up at six figures, see managing 100,000 network devices; this page is about the backup discipline that runs on top of it: the cadence, the versions, and the route back.
Windows, versions, and a way back
The first test of backup at scale is the window. A nightly backup is only useful if it actually finishes. rConfig schedules backup as parallel, queue-driven work sized so the window closes on time as the estate grows, so the cadence keeps up with the network instead of slipping a little further behind each quarter until it quietly stops being current.
A backup you cannot compare is just storage. Every config rConfig collects is versioned from the first poll, not overwritten, so you hold a full history rather than a single latest copy. Any two versions diff line by line, so what changed on a device last Tuesday has an immediate answer, and a config that drifts out of standard shows the exact lines that moved.
Versioned history is only defensible if you keep it for as long as your obligations require, at the granularity an auditor will ask for, so retention is policy-driven, set to match your compliance regime rather than a fixed default. And when a change goes wrong, recovery is the point of the whole exercise: roll a device, or a group, back to a verified known-good fast with network configuration restore, so a bad change is an inconvenience instead of an incident.
What backup at scale has to do
The parts of the backup discipline that have to hold across the whole estate, on schedule, without anyone babysitting them, built on network configuration backup.
Windows that keep closing
Scheduled, parallel backup sized so the window finishes on time even as the estate grows, instead of slipping a little further behind every quarter.
Versioned, not overwritten
Every config is kept as a version from the first poll, so you hold a full history of each device rather than a single latest copy that erases the last one.
Diff on every change
Compare any two versions line by line, so what changed on a device, where, and when is a question with an immediate answer, not an investigation.
Retention you can defend
Policy-driven retention set to your compliance and audit obligations, at the granularity an auditor will ask for, rather than a fixed default you have to explain.
Restore to a known-good
Roll a device, or a group, back to a verified configuration fast when a change goes wrong, so a bad change is an inconvenience instead of an incident.
Proof the backup ran
Evidence that every device was captured on schedule, so a missed backup is an alert you act on, not a surprise you discover at restore time.
One discipline across every vendor
One backup discipline has to span the whole estate, not a separate tool per platform. Because rConfig sells no network hardware, its neutrality is structural: backup, versioning, and restore run the same way across every vendor in the network, so a known-good is a known-good whoever made the box. See multi-vendor configuration management for how that neutrality is built.
Make every backup window close
See rConfig back up, version, and restore a multi-vendor estate at scale. Book a working demo, or talk to our team about your backup and retention obligations.