The backup report is green. It has been green for two years. Then a database is lost and the restore runs successfully, and the maintenance system comes back without the last eleven days of work order history, because the attachment store was on a different schedule, the telemetry ingestion had no backup at all on the grounds that it could be re-collected, and the controller configuration that nobody listed as data turned out to be the only record of which point meant what.
The message up front: facilities data is not one dataset, and an estate-wide backup policy that treats it as one will leave specific, predictable gaps. Inventory the pieces, decide an acceptable loss window per piece rather than globally, test a real restore into a separate environment on a schedule, and test the pieces together rather than individually, because the failures that hurt are the ones where each component restores correctly and the relationships between them do not.
1. What there is to lose
The first task is unglamorous and almost always reveals something: list every store that holds facilities data, who owns it, and what backs it up.
| Data | Typically lives in | Why it gets missed |
|---|---|---|
| Asset register and hierarchy | CMMS or CAFM database | Rarely missed. This one is usually covered, and it is the piece everything else references, per asset hierarchy design |
| Work order history and costs | Same database | Covered, but the acceptable loss window is often never stated, so nobody knows what losing a day means |
| Attachments and photographs | File store or object storage, separate from the database | A different system with a different schedule. Restoring one without the other leaves broken references |
| Telemetry history | Historian or time-series store | Excluded on the assumption it can be re-collected, which is true for the last few days and false for the last few years |
| Point register and mappings | Spreadsheet, integration layer, or nowhere | Not seen as a database, yet it is the only thing that makes telemetry interpretable, per the point dictionary |
| Controller configuration and programmes | On the controllers, plus whatever the contractor kept | Owned by a contractor, not by IT, and frequently backed up only as a project deliverable years ago |
| Integration configuration | Middleware, scripts, scheduled jobs | Treated as infrastructure rather than data, and often the longest thing to rebuild from memory |
| Reports and dashboard definitions | Reporting tool | Nobody notices until the restored system has no reports |
The failures that hurt are at the joins
Each component in that list can restore perfectly and the result still be unusable, because the value is in the references between them. A work order points at an asset, an asset points at a location, a location points at a set of points, a point points at a telemetry series, and a work order points at an attachment. If two stores are restored to different moments, those references do not all resolve, and the system comes back internally inconsistent in ways that are hard to find and harder to repair. That is the argument for testing the set together and to a common point in time, not for testing each component in isolation and declaring the whole covered.
2. Deciding an acceptable loss window per piece
A single organisation-wide recovery objective is easy to agree and almost always wrong, because the pieces genuinely differ.
- Transactional records. Work orders, labour, parts issues and approvals are created by people and cannot be reconstructed. The tolerable loss here is usually very small, and it is the number worth arguing about.
- Telemetry. Often re-collectable for a short recent window if the controllers still hold the trend logs, which is a reason to know what those buffers actually cover, per trend logs versus historians. Beyond that window it is gone permanently.
- Reference and master data. Changes slowly, so a longer window is tolerable, but losing it is catastrophic because everything references it.
- Configuration. Changes rarely and is painful to rebuild. The right control here is version control rather than backup, which also gives you a history of who changed what.
- Audit and compliance records. The loss window may be set by obligation rather than by preference, and that constraint belongs in the retention policy alongside it.
Stating these separately costs an hour and changes the design, because it usually turns out that the expensive protection is only needed on one or two of them.
3. What a real restore test looks like
A restore test is not a verification that the backup file is readable. Most backup tools already check that, and it tells you almost nothing about recoverability.
- Restore into a separate environment, never over the live system, and with the integrations pointed at test endpoints so a restored scheduled job does not start writing to production or sending notifications.
- Restore the set to a common point in time, including the attachment store and the telemetry store, not just the main database.
- Measure how long it took, end to end, including the parts a runbook glosses over: locating the media, provisioning the target, applying the restore, and bringing the integrations up.
- Have somebody who uses the system check it, not only the person who ran the restore. A planner opening the system and trying to do their job finds problems a technical check will not.
- Write down what was wrong, because something always is, and the first few tests are the ones that find the real gaps.
4. Checks worth running on a restored copy
A short, repeatable list makes the test comparable between runs and keeps it from becoming a matter of opinion.
- Row counts on the main tables against the source at the backup moment, which catches a partial restore immediately.
- Referential checks: work orders whose asset no longer exists, assets whose location does not, attachments referenced but absent.
- The latest record in each store, which tells you the actual loss window rather than the intended one and is usually the most informative single check.
- A telemetry continuity check on a handful of points, looking for a gap at the restore boundary, using the completeness measures from data completeness KPIs.
- One end-to-end transaction: raise a work order, assign it, close it. This exercises far more of the system than reading does.
- One report that people actually use, run against the restored copy and compared to a known output.
5. Keeping it honest over time
Restore testing decays in a characteristic way. It is done thoroughly once during implementation, then becomes an annual tick, then becomes a statement that backups are in place.
Three things slow that decay. Name an owner for the test rather than for the backup, because those are different jobs and the second one is already covered by whoever runs the infrastructure. Record the measured restore duration and loss window each time, so the trend is visible and a degradation gets noticed. And re-run the test after any significant change to the estate: a new site, a new integration, a platform migration, or a change of storage. Each of those can break recoverability without touching anything the backup monitoring watches. Where responsibility for these stores is split across in-house teams and contractors, the ownership question is the same one examined in data governance in asset-heavy organisations.
6. Pitfalls specific to facilities estates
- Contractor-held configuration. If the only copy of a controller programme or an integration mapping sits with a contractor, your recovery depends on a commercial relationship. Get a copy, and get it on a schedule.
- Backups on the same infrastructure as the system. Common on a single-site deployment and a single point of failure for both.
- A restore that completes but takes too long. As volume grows, a procedure that worked can quietly stop fitting inside an acceptable outage. This is a capacity consideration as much as a continuity one, per storage sizing.
- Restored integrations waking up and acting. A test environment that still holds live credentials can create work orders, send notifications or write to a control system. Sever the connections before you start, not after you notice.
- Treating replication as backup. A replica protects against hardware failure and faithfully reproduces a deletion. They solve different problems.
Limits
No recovery time or recovery point targets are suggested here, because the right values depend on the operational and regulatory consequences of an outage in your context and a published figure would be adopted as a benchmark without that reasoning. Nothing here is a backup product recommendation, nor advice on backing up or restoring control system software itself, which is work for the controls vendor or contractor who owns that system and carries specific safety implications. This is written from the facilities data and integration side. Legal retention obligations vary by jurisdiction and sector and need to be confirmed with somebody qualified to advise on them.
The idea to walk away with
Facilities data recoverability fails at the joins. Each store can be backed up correctly and the restored estate still be unusable, because the references between stores only resolve if they were restored to the same moment.
Inventory the pieces including the ones nobody calls data, set a loss window per piece rather than one for everything, restore the set together into a separate environment on a schedule, and have somebody who uses the system try to use it.
Final thoughts
Two questions are worth asking this week. When was the last time anybody restored the maintenance system and used it, and where is the current copy of the point register and the integration configuration.
The first answer is often further back than anybody expects. The second is often a person rather than a location, and that is the finding worth acting on, because it is both the cheapest gap to close and the one most likely to matter.
Disclosure
Alongside advisory work I also build a CMMS and CAFM platform, so I have a commercial interest in this category. Nothing above is a recommendation for it, and no vendor named here has paid for inclusion or had any editorial input. Weigh the analysis accordingly.
Never actually tested a restore?
Independent help inventorying what your estate holds, setting loss windows that reflect real consequences, and running a restore test that finds the gaps. 22+ years across CMMS, CAFM, EAM and ERP implementations.
Book a conversationRelated reading: Data retention policy, Storage sizing, Data governance, BMS point dictionary, CAFM data migration strategy, Data completeness KPIs.
Muhammad Abbas
CMMS / CAFM Manager & Independent Advisor · 22+ years across enterprise CMMS, EAM, CAFM and ERP implementations in utilities, oil and gas, manufacturing, government and facility operations.
Work with me