A backup and restore plan states how many places hold a record at each point in its life, and which copy would bring it back. The count follows the path a record travels, and the path is drawn when somebody decides which store holds what. In AlgoKlima, a service record opened outside coverage sits on the phone alone and no server backup can hold it yet.
A backup plan answers where the record sits before it answers how often backups run
Ask a vendor how backups work and the answer arrives as a schedule. Schedules sound like answers because they are specific, and specificity is easy to mistake for coverage. What a schedule actually reports is how often a known location gets copied. Underneath it sits an assumption: that the locations are known. Where that assumption fails, the schedule guarantees nothing beyond the place it already reaches.
The inventory is not fixed, and that is what makes the assumption expensive. The same record sits in different places at different hours of its life. At some hours a single store is holding it; at others it is not alone. A plan built on a single backup line cannot express that. Each stop along the record’s path needs its own entry, and each entry has its own answer to the question of what would bring the record back.
AlgoKlima, the field service product we operate, makes that path visible. A service record is created in the field and held in the phone’s local queue. When the connection returns, the record reaches the database. A backup can be taken from the database and from nowhere earlier. Part of the record’s life is therefore spent somewhere the backup process cannot reach at all, and no schedule can report it, because a schedule only ever describes the store it runs against.
Stores split apart in other ways as well. In Secretum, the product we are building right now, a character record and the image it produces live in separate stores; restoring the record does not bring the file back. We set that separation out, along with how each item gets tested when a system changes hands, in the handover checklist that covers what actually reaches you.
What a backup misses is a handover question and it belongs in that checklist. This article asks the question that comes earlier: where does the record sit right now. Until the inventory exists there is nothing to measure a miss against, because a miss is defined by the places you were already counting.
The apparent shortcut is the hosting provider’s console. It lists backups with dates, and dates look reassuring. That list describes how often a disk the provider can see gets copied. It does not describe your record’s route. Every date on that console can read green while a record created in the field appears on none of them, and the console has no way of telling you so.
Where a record is only ever created on the server and carries no uploaded files, the inventory really is a single line. Writing it down takes a moment, and the plan can move on to the schedule question with a clear conscience. The failure mode is skipping the inventory step altogether, because in a business whose inventory is not a single line, the plan ends up blank exactly where it counts.
Out of coverage, the record sits on the technician’s phone and nowhere else
Field work happens where the signal is worst. The technician’s job is often in a boiler room at the bottom of a building, and coverage ends before the stairs do. AlgoKlima, which we run and keep extending, was designed around that condition: the technician opens and closes a record without waiting for a connection, the record is held in the phone’s local queue, and it reaches the database when the connection returns. How that queue behaves, and in what order records move through it, is set out in our article on field apps that keep working off the network.
The outcome is this. Until the connection returns, the record exists on the phone and nowhere else. The server knows nothing about it. The record is not a draft; it is a finished service record with a sole copy.
For a backup plan the consequence fits in a sentence. No server backup taken during that window contains that record. It cannot, because a backup copies what the server holds and the server holds nothing yet. This is not a misconfiguration waiting to be corrected. It follows directly from what a backup is.
Another consequence surprises people more. Increasing backup frequency does not change the window. Move the nightly job to midday, shorten the interval as far as your storage allows, and the record waiting on the phone sits in exactly the same position. Frequency shortens the gap between copies of server data. It has no reach into data the server has never received. This is where backup plans are most expensive when they go wrong: the window looks like something a setting can close.
An application where records are only ever created on the server does not have this window, and the price is paid somewhere else. Without a connection no record is created, and the technician stops working to go hunting for signal. If the way to close the window is to make records impossible to create in the field, what closes is not the window but the job.
A plan cannot close the window; it can name it, and the phone is a location
What sets the length of the window is not the backup schedule. It is when coverage comes back. Building, floor, site conditions: none of that sits under the software’s control, and none of it sits under yours. A variable you cannot manage cannot be written into a plan as a duration. Its existence can be written down, and it should be.
Pinning the window on user discipline does not work either. A line that reads “the technician syncs when back at the office” is a hope, not a plan entry. It does not change where the record sits; it moves responsibility onto a person. The plan has to state where the record is during those hours even when everyone behaves exactly as intended.
So the plan lists the phone as a location. Server, backup environment and device stand side by side in the same list. Next to the device entry goes the name of the loss that can happen there: a phone that goes missing, an app that gets deleted, a handset that gets replaced. In all of those cases, a record still waiting in the window is beyond the reach of every server backup. The sentence reads harshly and it should. A plan’s job is to make the boundary of a loss legible.
Nothing here says a backup is also taken on the device side. If such an item exists in your setup, it comes from your own documentation rather than from this article, and the same goes for a backup schedule: the schedule your plan carries is the schedule of your own installation.
Naming the window turns into a set of questions you can actually answer. How many records get opened in the field on a working day. What share of them start outside coverage. When does coverage typically come back. Those answers come out of your own field operation, and the plan gets written with them in hand.
For teams whose work stays inside coverage throughout, the device entry reads “none”. It is written, not deleted. A blank entry and a deleted entry are different objects: the blank records that this loss cannot happen to you, the deleted records that nobody asked.
The copy that could bring a record back changes as the record moves
Most backup plans imagine a record in a fixed state: a row sitting on a server. The same record actually occupies a different number of places at each stage of its life, and at each stage a different copy is what could bring it back. Setting the stages side by side is what makes a plan readable; every row answers the same set of questions.
A distinction has to hold while you count: the unit being counted is a store, never a screen. The cache that speeds up the readings the office panel puts on screen is derived from the database. It is not a copy in its own right and it does not earn a row. Counting derived data as a copy makes the inventory look safer than it is.
| Where the record is | In how many places it sits | Which copy contains it | What brings it back if it is lost now |
|---|---|---|---|
| Opened out of coverage | The technician’s phone alone, in the local queue | No server-side copy; the phone only | If the phone is lost or the app removed, no server backup does; the plan names this loss |
| Connection returned, record reached the database | In the database; whether a copy remains on the phone is a decision the software makes | The database alone; no backup holds it yet | On server loss, no backup; the phone copy if such a copy exists, and whether it does is the decision your plan must record |
| Being read through the cache | In the database; the cached reading is derived data and is not counted | The database alone | If the cache is lost, the database; if the database is lost, the cache is no substitute for a backup |
| Nightly backup taken | In the database and in the backup environment | The backup holds what reached the database by the backup moment; nothing holds what is still waiting on a phone | On server loss, the backup; it does not return what arrived after the backup moment |
| Backup restored | In the restored database; the backup environment stays where it is | Records up to the backup moment; whatever arrived between the backup and the failure is absent | The records in between do not return; whether phone-held records still flow in is the rehearsal’s question |
The lower rows describe stages of a plan: they show how a record that has been backed up and restored would appear in an inventory. Use the table as a frame for your own plan; which stores fill each row is a fact about your installation.
The window reopens on the server: from the moment the queue drains to the next backup
When the record reaches the database, relief follows. It is on the server now, so it must be safe. The relief arrives early. The record has not stopped being a sole copy; it has changed address. Until the next backup runs, the database is the only store holding it. If a server-side loss happens in that interval, the backup you fall back to does not contain that record.
This is the window the schedule actually governs, and it is the only place where the frequency question earns its keep. Raising frequency does nothing to the field window and genuinely shortens the server window. Seeing that the question was not wrong, only misplaced, changes how the plan gets built: frequency answers a particular entry in the inventory, not the plan as a whole.
Whether a copy remains on the phone after the queue drains is a decision the software makes. Your plan cannot leave that entry blank: ask your vendor and write the answer down. If a copy remains, a server-side loss leaves you something; if it does not, it leaves you nothing. Those situations look nothing alike, and only a written answer tells them apart.
There is a further counting error worth naming: treating interfaces that share one database as separate copies. The panel opened at the office and the app used on site read the same data. The screens differ; the store does not. An inventory that counts screens makes the loss of a lone store look more survivable than it is. The counting rule is short: as many rows as there are stores.
The same rule has a purchasing consequence. Adding an interface does not strengthen your inventory. Adding a store adds a row to the plan, a new way to lose something, and a new restore question to answer. Sometimes a new store is worth all of that. The point is that the cost should be visible in the plan rather than discovered on the day of a failure.
A backup is a copy; a restore is a rehearsal
“We have backups” is usually true and usually beside the point. A backup that has been taken and never restored is not evidence that it restores; it is an untested assumption. Language can carry the difference. Saying “backups are taken” instead of “backups exist” pulls the sentence back to what you can actually show.
The rehearsal closes that gap. It restores the backup into a separate environment and reads the recovered records back from every side of the business. It should not be confused with the reproducibility rehearsal that belongs to a handover: the handover rehearsal runs at delivery and measures whether the system can be stood up by you at all. The rehearsal in this article repeats, and it measures whether the backup restores. We described the handover version in our handover checklist; this version comes afterwards and recurs for as long as the system is in service.
Running it in a separate environment is not a nicety. Restoring a backup over a running system turns a test into a risk, because live records get written over by an older copy. A separate environment is what allows the rehearsal to come out wrong, and a test that cannot come out wrong produces no result at all.
For AlgoKlima, the reading list is concrete. Does the restored database still tie the customer to the unit the same way when it is read from the office as when it is read on site? Are warranty and maintenance entries still attached to the right unit? If the answers hold, the backup has shown more than that it was taken. If an answer fails, the backup is intact as a file and empty as a business record, and the day of a failure is the most expensive place to learn that.
Making the rehearsal a recurring entry matters. A rehearsal run a single time proves the backup of that day. Systems change: fields get added, stores get split, new integrations arrive. A backup that restored cleanly last month can restore incompletely this month, and nothing in the schedule will announce it.
One boundary matters here. Where the provider takes the backups and performs the restores, and you cannot run a restore yourself, “we have backups” is the vendor’s statement rather than your evidence. What your plan can specify in that situation is not the rehearsal itself but who will request it and in what form the result will be shown to you.
What the rehearsal measures: the records between the backup moment and the failure
What a rehearsal produces is a list of records. Everything that arrived in the database once the backup had already run is absent from it and does not come back with the restore. After a failure those records disappear quietly, because the system comes up working and an absence raises no error. The rehearsal shows which jobs make up that list before a failure forces the issue: which service calls, which device entries, which updates.
We are not attaching a figure to the length of that list, because the length depends on how busy your operation is and how far apart your backups run. The measure gets named in the plan; the value comes out of your own data.
Feeding the list back into the plan is also the rehearsal’s job. If the records in the gap represent a loss your business can absorb, the backup interval stays as it is. If they do not, the interval is what changes, and that decision now rests on a list rather than on a guess. This is how the frequency question becomes answerable: after the inventory, read off the rehearsal.
Records still waiting on a phone at the moment of failure raise a further question. Once the server is restored, do the queued records flow into the restored database, and in what state do they arrive? An article cannot answer that; the rehearsal you run against your own system can. Put the entry on the list when you design it: what does a waiting queue do when it meets a restored server?
Step back and the decisions underneath the plan become visible. How many places a record will occupy, which store holds what, which interface reads which store: all of it is settled before any record exists. What inherited decisions leave you holding is something we set out in our piece on why architecture comes before code.
The system architecture page sets out how we take those decisions: how the storage layout gets fixed at the start, and how many interfaces hang off a single database.
