Why backups matter more in freight than almost anywhere else
Your TMS is not a filing cabinet. It is the live record of every load on the road right now: who the shipper is, where the driver is supposed to be at 0600, which rate applies, what accessorials you agreed to, and what you owe the owner-operator on Friday. When that system goes dark, the trucks keep moving but the office goes blind.
Think about what a bad Monday morning looks like when the server will not boot. Dispatch cannot see open loads. Customer service cannot answer a single "where's my truck" call. Billing cannot release invoices, so cash stops. Payroll cannot run settlements, so drivers start calling. EDI 204 tenders pile up unanswered and your customers' systems start routing freight to someone else. Every hour of downtime costs you on all of those fronts at once.
The good news is that backup and recovery is not a mystery. It is a discipline. The carriers who come through a server failure or a ransomware event in good shape are not lucky. They decided ahead of time what they needed to protect, how fast they needed it back, and they proved it worked before they needed it.
Step one: know what you are protecting
Before you talk about backup software or cloud storage, list what the business actually runs on. In most carrier offices, the list is longer than people expect:
- The TMS database. Orders, dispatch, rating, billing, settlements, and history. This is the crown jewel.
- Accounting. General ledger, AP, AR, and payroll if they live outside the TMS.
- Document imaging. Bills of lading, PODs, rate confirmations, and lumper receipts. Without them you cannot bill or defend a claim.
- Interfaces and configuration. EDI maps and trading partner settings, ELD and telematics connections, fuel card imports, mileage software settings, and any scheduled jobs.
- Custom reports and business documents. Invoices, settlement statements, and cheque layouts that took years to get right.
- Email and shared files. Rate quotes, customer contracts, safety files, and the spreadsheets someone in the office lives in.
- Identity and access. User accounts, passwords, MFA settings, and the admin credentials needed to rebuild everything else.
That last item catches people off guard. If the only copy of the database server's admin password lives on the database server, you do not have a recovery plan. Keep a sealed, offline record of critical credentials and license keys, and keep vendor support contacts in the same place.
The 3-2-1 rule, and why carriers should go further
The 3-2-1 rule is the long-standing baseline in IT: keep three copies of your data, on two different types of storage, with one copy offsite. It still holds up, and if you are not meeting it today, start there.
Ransomware has changed the threat, though. Modern attacks go looking for backups and try to encrypt or delete them first, because a carrier with no clean backup is a carrier more likely to pay. So many practitioners now talk about 3-2-1-1-0:
| Element | What it means | Carrier example |
|---|---|---|
| 3 copies | Production data plus two backups | Live TMS database, local backup appliance, cloud backup |
| 2 media types | Do not keep every copy on the same kind of storage | Disk on site, object storage in the cloud |
| 1 offsite | A copy away from the building | Cloud region in another part of the country |
| 1 offline or immutable | A copy an attacker cannot change, even with admin rights | Immutable cloud storage with a retention lock, or rotated media kept disconnected |
| 0 errors | Backups are verified and restores are tested | Monthly test restores with a written result |
The "1 offline or immutable" copy is the one that saves you in a ransomware event. Immutable storage means that once a backup is written, it cannot be modified or deleted until its retention period expires, no matter whose credentials are used. If your backup console uses the same domain admin account as everything else on the network, an attacker who gets that account gets your backups too. Separate the credentials, turn on MFA for the backup system, and make sure at least one copy is out of reach.
RPO and RTO in freight terms
Two numbers drive every backup decision, and both should come from operations, not from IT.
Recovery Point Objective (RPO) is how much data you can afford to lose, measured in time. If you back up the TMS once a night at 11 PM and the server dies at 4 PM, you lose 17 hours of work. Ask your dispatch and billing leads a direct question: how many hours of orders, dispatches, check calls, and status updates could we re-key from email, paper, and driver messages? For a small regional carrier, a few hours might be manageable. For a busy brokerage floor booking loads all day, losing even one hour of carrier confirmations and rate cons is painful.
Recovery Time Objective (RTO) is how long you can be down before the damage becomes serious. Could dispatch run on a whiteboard and cell phones for half a day? A full day? What happens to billing and cash flow if invoices stop for three days? What happens on settlement day?
| System | Questions to ask | What drives the answer |
|---|---|---|
| TMS dispatch and orders | How many hours of loads could we rebuild by hand? | Load volume, tender method, how many people book freight |
| Billing and AR | How long can invoicing stop before cash flow hurts? | Payment terms, factoring arrangements, customer billing portals |
| Settlements and payroll | Can we pay drivers on time if the system is down on pay day? | Pay schedule, owner-operator mix, driver retention risk |
| EDI | How long before customers re-route tenders? | Tender acceptance windows in customer routing guides |
| Document imaging | Can we bill without PODs for a few days? | Customer requirements for proof of delivery with invoices |
Once you have honest answers, you can design to them. Tight RPOs call for more frequent backups, such as database transaction log backups throughout the day instead of a single nightly job. Tight RTOs call for faster restore paths, such as a standby server, a recent virtual machine image you can boot quickly, or a documented cloud recovery option. Shorter targets cost more, and that trade-off is a business decision. Make it on purpose, not by default.
Snapshots, sync, and RAID are not backups
RAID protects you from a single failed disk, not from deletion, corruption, or encryption. File sync copies mistakes and ransomware to every connected device. Storage snapshots on the same array die with the array. Each has a place, but none replaces point-in-time backups stored separately, with at least one copy out of an attacker's reach.
Restore testing: the part everyone skips
A backup job that reports "success" tells you that something was written somewhere. It does not tell you the database is consistent, that the file you need is in it, or that anyone on staff knows how to bring it back. The only proof is a restore.
Build a simple testing calendar and keep a written log of every result:
| Frequency | Test | Pass criteria |
|---|---|---|
| Daily | Review backup job reports and alerts | Every scheduled job completed; failures investigated the same day |
| Monthly | Restore a random file, mailbox item, or imaged POD | Item opens correctly and matches the original |
| Quarterly | Restore the full TMS database to a separate test server | Database mounts; users can log in, open recent loads, and run a report |
| Twice a year | Full recovery exercise for a core system | Recovery completed within the RTO; gaps written up and fixed |
| After major change | Restore test after upgrades, migrations, or new hardware | Same as quarterly test, on the new configuration |
When you test the TMS restore, have someone from operations check it, not just IT. Can they find yesterday's loads? Does a recent invoice reprint correctly? Do settlement balances match? A database that restores but is missing the last week of imaged documents is a partial recovery, and you want to learn that on a quiet Tuesday, not during an outage.
Time the full restore. If your RTO is eight hours and the restore takes eleven, you have found a real problem, and you found it cheaply.
Ransomware: plan for it, not just against it
Prevention matters: patching, MFA on email and remote access, least-privilege accounts, and staff who know how to spot a phishing email dressed up as a rate confirmation or a load tender. But plan as if something will get through, because your recovery depends on decisions you make beforehand.
- Isolate the backup system. Separate admin credentials, MFA, and no shared domain accounts. Restrict who and what can delete backups.
- Keep enough history. Attackers sometimes sit quietly in a network before encrypting. Retain backups long enough that you can reach a point before the compromise began.
- Write the first-hour runbook. Who disconnects what, who calls your insurance carrier, who calls outside incident response help, and who talks to customers and drivers.
- Know your insurance terms. Many cyber policies set conditions on controls such as MFA and backups, and some require you to use approved responders. Review the policy with your broker before you need it.
- Plan manual operations. Paper load sheets, a printed driver roster with phone numbers, a printed list of key customer contacts, and a way to accept tenders by phone or email while the TMS is down.
- Restore clean. Do not restore onto infected machines. Rebuild or wipe, restore from a known-good point, and change credentials.
Run a tabletop exercise at least once a year. Put the owner, the controller, the operations manager, and IT in a room and walk through a scenario: it is 5:30 AM on a Monday and the dispatch screens show a ransom note. Who does what? The gaps you find in that hour are worth more than most software purchases.
Hosted and cloud TMS: whose backup is it?
Moving to a hosted or software-as-a-service TMS shifts the infrastructure work, but it does not shift accountability for your data. Before you assume the vendor has you covered, get clear answers in writing:
- How often is our data backed up, and how long is each backup kept?
- What is the vendor's committed recovery time if their environment fails?
- Can we restore a single record or a single day, or only the whole database?
- Can we get a full export of our data on a schedule, in a usable format, without a special request?
- What happens to our data if we end the contract or the vendor is acquired?
For many carriers, the right answer is a regular export of the data you control, stored in your own backup system. That protects you in a vendor outage, a billing dispute, or a future migration. The same logic applies to email and file platforms in the cloud: the provider keeps the service running, but recovering your deleted or encrypted data is often your job.
Who owns backups in your company
Most backup failures are not technical. They are ownership failures. The person who set up the backup left two years ago, the alerts go to a mailbox nobody reads, and everyone assumes someone else is watching. Assign clear roles:
| Role | Responsibility |
|---|---|
| Executive sponsor (owner, president, or CFO) | Approves RPO and RTO targets and the budget to meet them; reviews results quarterly |
| Backup owner (internal IT or a named outside provider) | Runs jobs, watches alerts, performs restores, keeps the log |
| Operations validator | Checks restored TMS data from a dispatch, billing, and payroll point of view |
| Vendor contacts | TMS, hosting, and backup vendors with known support paths and contract terms |
If your IT is outsourced, get the backup scope in writing. "We back up your server" is not the same as "we test a full restore of your TMS database every quarter and send you the results." Ask for the report.
Backup readiness checklist
- We have a written inventory of every system the business runs on, including interfaces and documents.
- Operations has signed off on RPO and RTO targets for the TMS, accounting, imaging, and EDI.
- We meet 3-2-1, with at least one offline or immutable copy.
- Backup admin credentials are separate from everyday network admin accounts, with MFA turned on.
- Retention is long enough to reach a point before a quiet compromise.
- We restore something every month and the full TMS database every quarter, with a written log.
- We have timed a full restore and it fits inside our RTO.
- Critical passwords, license keys, and vendor contacts are stored securely offline.
- A ransomware runbook exists, and we have walked through it in a tabletop exercise.
- Hosted vendors have documented backup, retention, restore, and export terms.
- One named person owns backups, and leadership reviews results every quarter.
How Strong Tower Consulting helps
Strong Tower Consulting has worked inside carrier systems since 2008, at the database level, in the dispatch office, and during go-live weeks. That background matters in data protection, because a restore is only good if the TMS, imaging, and interfaces come back working together. Through our Data Protection & Business Continuity practice, we review your current backups, set recovery targets with your operations team, design the offline and immutable layers, and run the restore tests and tabletop exercises with you.
For carriers running an older system, our Legacy TMS Advisory work often starts with backup and recovery checks before any upgrade. If you need ongoing hands to watch the jobs and run the monthly tests, our On-Site & Remote Support agreements can cover it, and our IT Strategy & Planning practice ties backup spending to the rest of your technology roadmap.
Independent by design
Strong Tower Consulting never requires you to buy our software. We protect the systems you run today, whatever vendor built them, and we will tell you plainly where the risk is and what it costs to fix.
Frequently asked questions
How often should a trucking company test its backups?
Run a small file or table restore every month and a full restore of the TMS database to a separate server at least once a quarter, plus after any major upgrade or hardware change. A backup you have never restored is a hope, not a plan.
Is cloud sync the same as a backup?
No. Sync tools copy changes, including deletions and encrypted files, to every connected device. A real backup keeps point-in-time versions you can roll back to, and at least one copy should be offline or immutable so ransomware cannot reach it.
What is a reasonable RPO and RTO for a TMS?
It depends on your freight. Ask how many hours of orders, dispatches, and check calls you could re-key from paper and email, and how long you could run dispatch on whiteboards before customers and drivers feel it. Those answers become your recovery point and recovery time targets, and they drive the backup design and budget.
Our TMS is hosted by the vendor. Do we still need our own backups?
Read the contract. Many hosted agreements cover the vendor's infrastructure but not your ability to get a usable copy of your data on demand. Confirm how often they back up, how long they keep it, how fast they restore, and whether you can get a regular export you control.
Do you require us to use Exspeedite software?
No. Strong Tower Consulting is independent. Our data protection work covers whatever systems you run today, and consulting never requires buying our sister company's software.