Backup internet for business continuity

What counts as a backup path

A backup path is a route to the internet that does not share a single point of failure with your primary route. That is a stricter test than having two circuits, and it excludes most of what is sold as redundancy. Two services from the same supplier usually share that supplier's access network. Two suppliers often share the same physical duct into the building. A second circuit that terminates on the same street cabinet fails when that cabinet is damaged or when a contractor cuts the pavement outside. The design question is therefore not how many circuits you have but which events each circuit survives, written down as a list.

• Different supplier, and ideally a different access technology.
• Different physical entry into the premises where available.
• No shared street cabinet or duct on the last mile.
• A written list of the failures each path does and does not survive.

Audit the facilities, not the brand: ILEC, CLEC and who owns the last mile

Two circuits from two brands are not necessarily two paths, because carriers buy access from one another. The incumbent local exchange carrier owns the access plant in its territory; a competitive local exchange carrier may build its own, but may equally lease the incumbent's fibre, conduit or unbundled loops. Two competitors sitting on the same unbundled loop share the failure that loop suffers, and a wireless path is not automatically immune either, because its tower depends on backhaul that can fail with the wireline plant it rides on. The audit is therefore about ownership per segment rather than logos: for each circuit, name the facilities-based carrier behind the access segment, the aggregation node and the transport, and the access method — own plant, leased dark fibre or wholesale Ethernet. Then require the answer in writing. A product taxonomised as Business Data Services, the FCC's term for dedicated point-to-point transmission at guaranteed speeds and service levels, is still a dedicated line capable of sharing a duct with the next one; the classification describes the service, not the route.

• Name the facilities-based carrier behind each segment, not the reseller brand.
• Incumbent, competitive and wholesale access are different claims on the same conduit.
• A wireless path depends on backhaul that can fail with the wireline plant.
• Ask for a written attestation of shared entrance, sheath, poles, ducts and nodes.

Design for the failure you will actually get

Outages that reach a business are usually last-mile rather than core-network events: a damaged cable, a failed cabinet, a power problem at the local exchange, or work in the street. Provider core networks are engineered with substantial redundancy, and an incident there is both rarer and shorter for most businesses. That asymmetry is what should drive the design. If your continuity plan assumes a supplier-level outage while your actual exposure is the pavement outside, the plan protects against the less likely event. Ask the supplier to describe the last mile specifically — where it enters, what it depends on, and what else uses it — and treat every shared component as a single point of failure regardless of who bills you for it.

• Most business outages are last-mile, not core-network.
• Shared duct, cabinet and building entry are single points of failure.
• Ask where each path enters, and what else depends on it.
• Plan for the frequent failure rather than the dramatic one.

Failover: automatic, manual, and how long it takes

Failover is three separate questions: how the switch is triggered, how long it takes, and what survives it. An automatic failover using a router with two uplinks is measured in seconds; a manual switch to a separate device is measured in the time it takes someone to notice, find the equipment and act, which is usually minutes at best and can be much longer outside working hours. Even with automatic failover, established sessions do not survive the change: calls drop, file transfers fail, remote sessions end and have to be re-established. Addresses change unless the design provides for it, which means anything published by IP needs a plan. Decide what actually has to keep running during an outage, and design failover for that rather than for everything.

• Automatic trigger, manual switch, or manual with a documented procedure.
• How long the switch takes, and who is permitted to perform it.
• Which sessions survive — usually none — and what re-establishes them.
• How published services are reached when the address changes.

SD-WAN steers between paths; it does not create one

SD-WAN is the layer that chooses among paths, not a path in itself — worth stating plainly because it is often bought as though it were redundancy. An SD-WAN edge sits at the site and forwards traffic over two or more underlays, which may be fibre, cable, Ethernet, cellular or fixed wireless, measuring latency, loss and jitter continuously and steering each class of application to the path that meets its threshold. The overlay tunnels are assembled from ordinary protocols — IPsec to build the tunnel, BGP to exchange reachability — so the security and routing properties come from those standards rather than from the vendor's name. Two consequences follow. A controller can detect a dead underlay in well under a second, but the interruption users see is longer, because routing must converge, tunnels re-establish, firewall state is rebuilt and open sessions retransmit; an 'instant failover' claim describes the interface, not the payment terminal. And a failover usually changes the public address, which breaks anything pinned to it — allowlists, inbound VPNs, hosted services, some fraud controls — so a design that needs a stable address must provide for one deliberately.

• The edge steers; the underlay paths are what actually fails over.
• Sub-second detection still leaves a longer application-visible gap.
• IPsec and BGP carry the overlay — ask which standards, not which brand.
• A changed public address breaks allowlists, inbound VPN and hosted services.

Cellular and fixed wireless as backup paths

Cellular and fixed wireless make practical backup paths for small sites because they arrive over a different medium and are unaffected by a cable fault. They also carry characteristics that decide what can run over them: a data allowance that may be consumed quickly by backup traffic, addressing that is often shared rather than public, latency that is higher and more variable than a fixed line, and indoor coverage that is worse than the coverage map suggests. The two are not the same product: cellular uses a SIM on a shared mobile network, while fixed wireless uses a fixed antenna aimed at a provider's radio site and can carry engineered service levels, at the cost of depending on line of sight and local capacity. Used for point-of-sale and general browsing they are effective; used as a drop-in replacement for a busy office they disappoint. Test the coverage inside the building, in the location the equipment will actually sit, rather than trusting a map.

• Data allowance sized for realistic backup use, not a token figure.
• Whether the equipment can obtain a public address on the backup path.
• Coverage measured indoors at the equipment location.
• Fixed wireless adds a line-of-sight dependency that cellular does not.

Restaurants and retail: deciding what stays up

For most restaurants and stores the workloads that must survive an outage are narrower than the list the site runs day to day, and separating them is what makes a modest second path adequate. Payment authorisation and till traffic belong at the front of the queue, together with the line that takes orders and the inventory synchronisation that keeps stock accurate; a cellular path covers exactly this kind of short, low-volume traffic well. Guest access, video, large software updates and cloud backups do not belong on a metered path — an update that runs unnoticed can consume an allowance meant to last a month in an afternoon. The configuration is a set of priorities rather than a single setting: payment and tills fail over first, voice is held to a tight loss and jitter threshold, back-office traffic is allowed on the secondary path but capped, and guest and update traffic is suspended while the primary is down. Across a chain the exercise repeats store by store, so the requirement is written once and the design confirmed at each address.

• Payment and tills first, then voice, then back-office traffic, capped.
• Suspend guest access and software updates while the primary path is down.
• A metered second path is sized for backup hours, not for peak workload.
• Write the priority list once; confirm the design at every store.

If it has never been tested, it does not exist

A continuity arrangement that has not been tested is an assumption. The test is simple to describe and rarely performed: disconnect the primary path during working hours, confirm that traffic moves, check that the applications people rely on actually work over the backup, note how long the switch took, and record what failed. Then repeat it on a schedule, because equipment is replaced, configurations drift and coverage changes as buildings and networks change around you. Monitoring matters as much as testing: if nobody is alerted when the primary circuit drops, the business may run on backup for weeks without noticing, which is a problem in its own right when the backup has a data allowance.

• A scheduled failover test with the primary path physically disconnected.
• Applications verified over the backup path, not just connectivity.
• The recorded switch time, compared with the business's tolerance.
• Alerting that tells someone the primary path is down.

What to gather before asking for pricing

Bring the address and the constraint that matters, which is usually which failures the business wants to survive. Include what runs over the connection and which of those things must keep working during an outage, how long an outage can last before it becomes a business problem, whether inbound services such as a phone system or a remote-access gateway depend on fixed addresses, and how the primary circuit enters the building. For a chain, add the per-site detail: the carrier legal entity and the facilities owner on each segment, the entrance and demarcation, the shared plant, the power dependency, and the cellular or fixed-wireless signal measured where the equipment will sit. State the honest constraint too — the useful conversation starts from the failure you are trying to survive, not from a brand.

• The specific failures the business wants to survive.
• What must keep working, and for how long an outage is tolerable.
• Any service that depends on a fixed, publicly reachable address.
• For a chain: carrier, facilities owner, entrance and signal, per site.

PUT THE OPTIONS SIDE BY SIDE

Your comparison checklist

Common questions