Backup
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.
184,000versions captured today
- DEVICES
- ~200k
- WINDOW
- closed
- OVERWRITES
- 0
- RESTORE
- fast
BACKUP PROOF
Every device captured on cadence and versioned, so a known-good is always one restore away, not a reconstruction.
- 100%
- of devices on cadence
- ~200k
- devices backed up
- 0
- silent overwrites
- 24/7
- scheduled collection
every device, every window
single Tier 1 ISP deployment
every config versioned and diffable
windows that keep closing
Figures describe how rConfig operates; deployment-specific results are published with customer permission.
The challenge
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.
Approach
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.
Capabilities
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.
CADENCE
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.
Learn moreVERSIONING
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.
Learn moreDIFF
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.
Learn moreRETENTION
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.
Learn moreRECOVERY
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.
Learn moreASSURANCE
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.
Learn more
Independence
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.
Explore the Service Provider hub
- 01Pillarnetwork configuration management for service providersThe Service Provider pillar: positioning and architecture for carrier and ISP estates.
- 02In clusterTier 1 ISP configuration managementBackup, audit, and change control across a ~200k-device estate.
- 03In clusterconfiguration compliance for service providersContinuous policy checks, drift detection, and carrier audit trails.
- 04Solutionmulti-vendor configuration managementOne neutral plane across every vendor in the estate.
- 05ReferencerConfig reference architectureHow the platform is engineered to run 100k+ device fleets.
TALK TO US
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.
Tell us your device count, vendor mix, and project timeline, and we will map a rollout to your estate.