Your Backup Is Expensive. Does It Actually Get You Back on Air?
Hi, donash
Your channel goes black. The backup server is running.
Those two things can happen at the same time.
The replacement system may be healthy while the route to viewers is unavailable. The content may be present while the latest schedule is missing. The recovery procedure may be documented while the person authorised to execute it cannot sign in.
An outage is public. The dependencies behind it usually are not.
That is what makes broadcast resilience difficult to buy on a budget. A full second operation is expensive, but a cheaper backup that cannot restore service is expensive in a different way.
The test of a recovery plan is what viewers receive after something fails.
How can broadcasters build resilience on a limited budget?
Broadcasters can control disaster recovery costs by matching protection to each channel’s recovery requirements, identifying shared points of failure and testing the complete route back to viewers.
Start with the service that must be restored, the interruption the business can tolerate and the content or schedule changes it can afford to lose. Then choose the infrastructure, operating procedures and support needed to meet those requirements.
Different channels may justify different levels of standby capacity. The same channel may need additional protection during a major live event.
The budget decision should follow the recovery requirement.
What is the difference between redundancy and disaster recovery?
Redundancy provides additional components or paths so a service can continue when something fails.
Disaster recovery restores an acceptable service after a disruption that the normal operating environment cannot absorb.
A second playout server can help address a server failure. It may offer little protection against a shared storage outage, a site-wide power failure or loss of the network connection both servers use.
Both approaches matter. They address different failure scenarios.
Two servers sharing one critical dependency can still share one outage.
Before buying another machine, establish what you expect it to protect against.
Why isn’t cloud a complete disaster recovery strategy?
Cloud infrastructure can provide useful separation from a physical site and flexible recovery capacity. Its effectiveness still depends on the architecture and the ability to operate it during an incident.
If the backup needs the same unavailable credentials, network path or content source as the primary system, moving compute elsewhere may leave a critical dependency intact.
Arqiva’s 2026 resilience session makes a similar case: protection should reflect content priority and operating requirements, using an appropriate mix of cloud, on-premises and other recovery options.
The practical question is:
Can we operate the recovery environment when the primary environment is unavailable?
Test access, content, control and delivery as part of that answer.
Does every channel need the same level of protection?
Every channel needs an agreed recovery plan. The required protection does not have to be identical.
A live event, a rolling news service and a scheduled library channel may have different commercial consequences if interrupted. Contractual and service obligations also matter.
Even within one channel, the impact of an outage can vary by programme or time of day.
A useful planning exercise is to group services by recovery requirement.
| Recovery requirement | Possible approach to assess | What must be demonstrated |
|---|---|---|
| Interruption must be kept extremely short | Continuously running, synchronised backup capacity with an appropriate switching design | The complete output path meets the agreed interruption limit |
| A short, defined recovery period is acceptable | Prepared standby resources with current content and configuration | Activation and verification fit within the recovery target |
| A longer, agreed restoration period is acceptable | Rebuild or restore from maintained content, configuration and procedures | Resources, licences, access and restoration steps are available when needed |
These are planning options, not guaranteed recovery times or fixed product packages.
Lower standby expenditure generally means accepting more work or time during recovery. That trade-off needs to be deliberate and tested.
What are RTO and RPO in broadcast disaster recovery?
Recovery time objective, or RTO, is the target maximum time to restore an agreed level of service after a disruption.
For a broadcaster, define where that restoration is measured. A running playout application is different from a verified output reaching the distribution hand-off.
Recovery point objective, or RPO, is the maximum acceptable loss of recent data or changes, expressed as a period of time.
In broadcast workflows, that can include recent schedule edits, asset updates and configuration changes.
Ask two plain-language questions:
- How long can this service be interrupted?
- How far behind the current operation can the recovered state be?
These are targets to design and test against. They become credible when the recovery exercise demonstrates them.
Five questions to ask before spending more on backup
1. What exactly must come back on air?
Define the minimum acceptable service for each channel.
Does recovery require the full scheduled output, live contribution, graphics, captions and advertising cues? Is an approved emergency schedule acceptable temporarily?
Make the answer explicit.
A system that plays pictures may still fall short of the service your viewers, distribution partners or contracts require.
Recovery acceptance criteria should cover the elements that make the output usable.
2. Which failure could take down both systems?
Map the dependencies shared by the primary and backup environments.
Include power, storage, networking, identity services, licensing, contribution feeds and distribution hand-offs.
Also consider operational dependencies: the same person, the same workstation or a procedure accessible only through the failed environment.
The purpose is to identify where an additional component provides protection and where both paths remain exposed.
3. What must happen before the backup can serve viewers?
Starting a server is one step.
The recovery environment may also need current media, the correct playlist, graphics assets, configuration, credentials, licences and a working output route.
If resources are created on demand, establish whether capacity and permissions will be available when required.
Write down every activation step. Assign responsibility. Measure the complete sequence.
A fast startup does not prove a fast recovery.
4. Who takes control—and who authorises the switch?
Recovery procedures need clear decision-making.
Who declares an incident? Who confirms that the backup output is ready? Who authorises the transition? Who communicates with distribution partners?
Specify which actions are automated and which require operator approval.
Then make sure authorised staff can perform those actions under the failure conditions being tested.
A recovery plan should remain executable when the usual workstation or primary site is unavailable.
5. When did we last test the output and the return to normal?
A useful exercise establishes that the recovery path delivers an acceptable service, records the time taken and identifies any missing steps.
It should also cover the return to the primary environment.
Before switching back, teams may need to reconcile schedules, content, logs and configuration changes made during the incident.
Recovery continues until the operation is stable again.
Budget for the rehearsal as well as the backup.
How should broadcasters test disaster recovery?
Choose a specific failure scenario and agree the boundaries of the exercise.
Examples include loss of a playout server, unavailable storage, loss of primary-site access or failure of a contribution path.
Use an isolated test output or an agreed maintenance window where appropriate. Define stop conditions and responsibilities before starting.
A practical exercise should record:
- When the failure was detected.
- When the recovery decision was made.
- Whether staff could access the required controls and instructions.
- When the agreed output became available at the chosen verification point.
- Whether content, audio, captions and other required elements were correct.
- Which manual steps or dependencies delayed recovery.
- Whether the return to normal operation completed successfully.
Repeat relevant tests after material changes to the infrastructure, integrations or operating procedures, alongside a planned rehearsal schedule.
How do you compare disaster recovery costs fairly?
Compare the cost of achieving the same recovery requirement.
Include standby infrastructure, storage, replication, connectivity, licensing, support, rehearsals and the resources consumed during an actual recovery.
A low standby bill may be accompanied by more activation work. A continuously running duplicate may reduce some recovery steps while increasing ongoing expenditure.
Neither figure tells the whole story.
Also check the scope of any availability commitment. Establish which components and service boundaries it covers, how availability is measured and which exclusions apply.
Your channel’s recovery plan needs to account for the full path, including anything outside a supplier’s commitment.
Where do PlayBox Technology products fit?
PlayBox Technology’s AirBox playout software includes mirror-mode support for redundancy workflows. That can form part of a channel protection design, alongside the required storage, networking, routing and operational procedures.
Celebro Play provides a browser-based environment for coordinating broadcast workflows and operational control. Its published human-in-the-loop model includes operator confirmation for critical actions such as failover handling and playout control, with attribution and audit logging.
These capabilities should be evaluated within the proposed recovery architecture.
A suitable design starts with the channel requirements, identifies the failure scenarios and confirms how the complete output will be restored. Recovery times and switching behaviour should be demonstrated for that deployment.
Explore AirBox playout and Celebro Play media orchestration.
Bring a failure scenario to the demonstration
For your next supplier discussion, bring a brief such as:
“Our primary playout environment is unavailable. Show us how an authorised operator restores this channel’s agreed output, using the content and schedule state available in the recovery environment.”
Then ask to see the dependencies, approval steps and return to normal operation.
That gives the demonstration a measurable purpose.
To discuss a PlayBox Technology recovery design, start with your channel list, acceptable interruption, minimum service requirements and the infrastructure already in place.
Talk to PlayBox Technology about your channel recovery requirements.
If your primary system disappeared tonight, when did you last prove what viewers would see next?
