TMS Disaster Recovery: RTO and RPO Targets for Dispatch, Billing, and Settlements, Immutable Backups, and Failover Drills

RTO and RPO in Plain Language

Two measurements define every recovery plan. Recovery time objective, or RTO, is the maximum time a function may be unavailable before the harm becomes unacceptable. It is measured from the moment the function fails to the moment people can use it again, which includes detection, decision, restoration, and verification, not just the technical restore. Recovery point objective, or RPO, is the maximum amount of data loss the business can accept, measured as time. If the last good copy of the database was taken at midnight and the failure happens at ten in the morning, ten hours of work is at risk, and the RPO states whether that is tolerable.

The two numbers drive different engineering. A short RTO requires standby infrastructure, rehearsed procedures, and people who know their roles, because the clock starts the moment something breaks. A short RPO requires frequent copies, which in database terms means transaction log backups or continuous replication rather than a nightly full backup. A carrier that writes a single RTO and a single RPO for the entire TMS has usually chosen numbers that are too aggressive for billing and too loose for dispatch. The useful exercise is to set them per function, and the rest of this page follows from that decision. The NIST contingency planning guidance for information systems, Special Publication 800-34, uses the same two measures and the same function by function logic, and it is a reasonable reference for a carrier that wants a structured framework without inventing one.

Why Each Function Warrants a Different Target

Dispatch is the function with the least tolerance. If dispatchers cannot see loads, assign drivers, and send instructions, freight stops moving within hours, appointments are missed, and the cost compounds. Dispatch also generates new data continuously: tenders accepted, loads built, drivers assigned, stops arrived, status messages sent. Losing even a short period of that data means reconstructing what happened from phone calls and driver memory. Dispatch therefore needs a short RTO and the shortest RPO the carrier can afford.

Billing tolerates a longer outage if, and only if, the source records survive. Invoices can be issued a day or two late without losing customers, and most customers will not notice a delay that short. What billing cannot tolerate is the loss of posted invoices or rated loads, because that creates revenue leakage and customer disputes that take months to resolve. Billing's RTO can be longer than dispatch's; its RPO still has to be tight enough that no completed billing run disappears.

Driver settlements have a hard calendar. Drivers are paid on a schedule, and a missed pay cycle is a safety, retention, and in some jurisdictions a legal problem. Settlements can be recomputed from dispatch and billing data if those survive, so the RPO can lean on upstream copies, but the RTO must land before the next pay run with time to review. ELD and hours of service records have a regulatory shape of their own. FMCSA rules require motor carriers to retain ELD records of duty status and supporting documents for six months and to keep a backup copy of ELD records on a device separate from where the originals are stored. The ELD provider typically holds the primary data, but the carrier's own retained copies and the TMS fields that reference them should be part of the plan.

An Illustrative Target Table by Function

The table below is an illustration of how a carrier might lay out targets, not a recommendation for any specific fleet. Actual targets depend on fleet size, customer commitments, staffing, and budget, and the exercise of filling in each row with the operation's own leadership is more valuable than the numbers themselves. What matters structurally is that each row has its own RTO, its own RPO, a named owner, and a named fallback procedure.

Backup Tiers: Hot, Warm, Cold, Immutable, and Offline

Recovery targets translate into backup tiers. A hot tier is a replica that is current to within seconds or minutes and can take over quickly; it protects against hardware and site failure but not against a logical error or an attacker, because whatever corrupts the primary replicates to the hot copy. A warm tier is a recent copy that can be restored in hours, typically nightly full backups plus frequent transaction log backups. A cold tier is older, retained for compliance and for the case where corruption went unnoticed for weeks.

Two further properties cut across those tiers and are the ones most carriers lack. An immutable backup is written to storage configured so that the object cannot be modified or deleted until a defined retention period expires, even by an administrator; cloud object storage with an object lock or write once setting is the common implementation. An offline backup is physically or logically disconnected from the production network, such as rotated media stored off site or a copy in an account with no trust relationship to production. The widely cited practice of keeping three copies of data on two different media with one copy off site is a reasonable floor; adding the requirement that at least one copy be immutable or offline is what makes it a ransomware plan rather than a hardware plan.

• Hot - Replica current to minutes; protects against hardware and site loss only.
• Warm - Nightly full plus frequent log backups; the normal restore source.
• Cold - Long retention for compliance and late discovered corruption.
• Immutable - Object locked so no credential can alter or delete it inside the retention window.
• Offline - Disconnected from production trust; the copy of last resort.

Ransomware Considerations

Ransomware is now the most likely reason a carrier will invoke this plan. The Cybersecurity and Infrastructure Security Agency publishes general ransomware guidance for organizations, and FMCSA has published cybersecurity awareness material directed at motor carriers; both emphasize backups that attackers cannot reach, tested restores, multifactor authentication, and an incident response plan written before it is needed. The operational point for a TMS is simple. Attackers who gain administrative access typically search for backup systems first, delete or encrypt what they can reach, and only then detonate the main payload. Any backup reachable with the same credentials as production should be assumed lost in that scenario.

Design accordingly. Backup credentials should be separate from production administrative credentials and protected with multifactor authentication. The immutable tier's retention window should be longer than the time it would plausibly take to notice an intrusion, because an attacker who dwells for weeks before acting will have waited out a short window. The restore procedure should assume the production environment itself may be untrustworthy and should include rebuilding servers from known good images rather than restoring data onto compromised hosts. And the plan should state who decides whether to pay, who contacts law enforcement and insurers, and who speaks to customers, so those decisions are not improvised under pressure. Our data protection practice builds these controls around the carrier's actual TMS, imaging, and accounting platforms.

Log Shipping and Point in Time Recovery

Relational databases underneath most TMS platforms support two recovery concepts that directly serve a short RPO. Transaction log backups capture every committed change since the previous log backup; taking them every few minutes means the exposure window for dispatch data is a few minutes rather than a day. Point in time recovery uses a full backup plus the chain of log backups to restore the database to a specific moment, such as the minute before a bad update or the minute before encryption began. Log shipping automates copying those log backups to a standby server and applying them there, producing a warm replica that lags production by a configurable delay.

That delay is a feature. A standby that lags by, for example, an hour gives operators a window to stop the apply process when a destructive change is detected, preserving a clean copy that the hot replica would already have corrupted. The configuration decisions are the log backup interval, the standby lag, the retention of the log chain on immutable storage, and the alerting that fires when the chain breaks, because a missing log backup silently turns a minutes RPO into a day RPO. Verify the chain weekly by restoring to a scratch instance and querying a recent load. Our SQL data mining team often builds that verification query as part of a reporting engagement, since the same skills apply.

Hosted Versus On Premise: Who Owns Which Control

When the TMS is hosted by the vendor, the vendor operates the servers, the database, and the backups, and the carrier's obligation shifts from doing the work to verifying and supplementing it. When the TMS runs on the carrier's own servers or in the carrier's own cloud account, every control on this page is the carrier's to build. Many fleets sit in between, with a hosted TMS and on premise imaging, accounting, or integration servers, and those local systems are frequently the weakest link because nobody wrote them into the plan.

In the hosted case the carrier still owns four things. First, knowing the vendor's actual RTO, RPO, backup immutability, and restore testing, in writing. Second, obtaining a periodic export of critical data in a documented format that the carrier controls, so the operation is not dependent on the vendor's recovery for its own survival. Third, the manual dispatch fallback, because a hosted outage looks identical to a local one from the dispatcher's chair. Fourth, the local components: workstations, network, identity provider, integration middleware, and any file shares that drivers' documents land on. A fractional freight CIO engagement typically maps this responsibility split on one page and keeps it current as systems change.

What to Require in a Vendor SLA

A service agreement that says the vendor performs regular backups is not a recovery commitment. Ask for, and record in the agreement where possible, the stated RTO and RPO for the carrier's environment, the backup frequency and retention by tier, whether at least one tier is immutable or offline and for how long, how often the vendor performs and documents restore tests, whether the carrier may observe or receive the results of those tests, the notification timeline when an incident affects the carrier's data, and the carrier's right to a full data export in a usable format on request and at termination. Ask also where the data physically resides, who at the vendor has administrative access, and whether the vendor's own backups are separated from its production credentials. A vendor that answers these questions readily is demonstrating maturity; one that cannot is telling you where your risk sits.

The Manual Dispatch Fallback Runbook

Every recovery plan contains a period, however short, when the TMS is unavailable and freight still has to move. The manual dispatch runbook covers that period. It should be a short, printed document kept where dispatch can reach it without a working network, and it should answer practical questions in order. Where is the most recent load list, printed or exported to a spreadsheet on a schedule, that shows today's and tomorrow's loads with shipper, consignee, appointment, driver, and tractor. How do dispatchers record new tenders, assignments, arrivals, and deliveries while the system is down, using a numbered paper log or a shared spreadsheet with the same columns the TMS will need on re entry. How do drivers receive instructions and report status by phone and text, and who logs each contact. Who talks to customers about delays, and what they are authorized to say. And how, when the system returns, the paper or spreadsheet record is keyed back in, in what order, and who verifies it against the driver and customer record.

The runbook only works if the scheduled export exists and is current. Automate a daily or more frequent export of the active load list, the driver roster with phone numbers, the customer contact list, and the tractor and trailer list to a location that survives the outage, such as a printed copy, a separate cloud account, or an encrypted drive in the dispatch office. Practice re keying from the paper log during drills, because the re entry step is where most manual fallbacks fail. A business process optimization review can design the paper and spreadsheet forms so that re entry is a transcription task rather than a reconstruction task.

Failover Drill Design and Scoring

A plan that has not been drilled is a document, not a capability. Design drills in escalating tiers. A tabletop drill walks the team through a scenario verbally, confirming that everyone knows their role and that contact lists are current. A technical restore drill restores the database to an isolated environment and verifies that a dispatcher can open loads and billing can print an invoice from the restored copy. A full failover drill cuts the team over to the standby or the manual runbook for a defined period during real operations, with the primary deliberately unavailable to them, and then cuts back.

Score each drill against the targets. Record the time from declared failure to each function being usable and compare it to the RTO for that function. Record the timestamp of the last transaction present in the restored data and compare it to the declared failure time to compute the achieved RPO. Record every step where the runbook was wrong, missing, or unclear, every person who could not be reached, and every credential that did not work. Assign each finding an owner and a due date, and treat the drill as failed if any function missed its target, even if the team improvised a workaround, because improvisation under drill conditions will not repeat under real ones. Publish a one page scorecard to leadership after every drill.

Communication Plan, Restore Cadence, and Documentation

The communication plan names who declares an incident, who is told in what order, and through what channel if email and the TMS are both down. It includes drivers, customers, the ELD and TMS vendors, the insurer, legal counsel, and where ransomware is involved, law enforcement. It includes pre written customer and driver messages that can be sent in minutes, with blanks for the specifics, so the first hour is spent recovering rather than drafting. Phone numbers should live on paper and in a personal device, not only in a directory that the outage took with it.

Restore testing needs a cadence, not an intention. A workable pattern is a monthly automated restore of the database to an isolated instance with row count or checksum comparison against production, a quarterly application level restore where real users perform real tasks on the restored copy, and an annual full failover drill that exercises the manual runbook and the communication plan end to end. Each test produces a dated record of what was restored, from which backup, how long it took, and what was found.

Documentation ties the program together. Maintain one recovery plan document with the target table, the backup tier design, the responsibility split with each vendor, the SLA excerpts, the manual runbook, the communication plan, the drill schedule, and the log of every test and drill with findings and closure. Store it in at least two places that will survive the scenarios it addresses, keep a printed copy, and review it whenever a system, vendor, or key person changes. Our TMS implementation engagements treat this document as a deliverable of the implementation itself, because the day a new TMS goes live is the first day it can fail.

Related practice areas for this work include Data Protection TMS Implementation Fractional Freight CIO SQL Data Mining. Each practice page describes scope, deliverables, and how an engagement starts with a short discovery call.

How Strong Tower Consulting Helps

Strong Tower Consulting helps carriers convert a vague sense that backups exist into a written, tested recovery program with targets per function. The work begins with the target table and the responsibility split across the TMS, imaging, accounting, ELD, and integration systems, moves to backup tier design including the immutable and offline copies, and then establishes the manual runbook, the drill calendar, and the scorecards that prove the plan to leadership, insurers, and customers. Strong Tower Consulting, LLC and Exspeedite LLC are separately organized sister companies under common ownership. That separation keeps consulting advice vendor neutral and focused on the carrier operation.

To discuss your systems, your vendors, and your current backup practice, call 763-244-1373 and ask for Scott Elliott. A short call is enough to identify which function is most exposed today, what the hosting agreement actually commits to, and the first drill worth running.

Frequently Asked Questions