Backups Are Not the Same as an Export
A backup restores the vendor's copy of your data to their system. An export is a file you hold, in a format you can read without them. Where the documentation is silent, and what to ask instead.
Two things get called the same word in conversation, and they are opposites in the way that matters. A backup is the vendor's copy of your data, held by the vendor, restorable by the vendor into the vendor's system. An export is a file that you hold, in a format you can read without asking anybody for anything. One is about continuity. The other is about ownership. A business that confuses them does not discover the gap during a routine backup check, because a routine backup check passes perfectly. It discovers it during an incident, which is the worst possible moment to discover that the thing you were relying on is a promise rather than a file.
This is the last of four articles on data trust. The first was about the shared login that makes attribution impossible, the second about the difference between a recorded action and a reconstructable one, the third about the person who configured the system and then left. This one is about the boundary between what a system holds for you and what you hold.
And it needs an honest opening. This article is about the question, not a claim about the product. Our published capability inventories document backup and restore, and CSV and Excel exports, and accounting-format exports. They do not document retention periods, restore point objectives, whether a restore is whole-tenant or record-level, or whether an export is a full-fidelity archive or a report-shaped extract. That silence is itself the subject of this article, and we would rather point at it than fill it.
Read this before believing any of itWhat is documented, and what is not
Here is precisely what our published capability inventories say, so that the reader can judge the rest of this article on evidence rather than on reassurance.
On the Nox-Billings capability inventory there are three relevant entries. A backup and restore capability, described as automated data backup with restore capability for business continuity, listed as available on the web and API surfaces. A CSV and Excel exports capability, described as exporting reports and data to CSV and Excel, also available on web and API. And an accounting exports capability, described as exporting invoice data in accounting-software-compatible formats, available on the API surface only.
On the Nox-Tickets inventory there is a CSV exports capability for reports and ticket data, available on web and API. On the NoxCRM
Two things follow, and they point in opposite directions. First, the honesty about this article: the absence of a documented retention period, a documented restore point, a documented restore scope, and a documented archive format means that we cannot tell you from the published material how much of your data you could read without us, in what shape, and how quickly. We are not going to fill that gap with adjectives. Second, the asymmetry between import and export is worth noticing on its own, and it is not unusual in this category — many products are much better documented on the way in than on the way out.
The distinctionWhat a backup does, and what an export does
Illustrative: backup and export are different answers to different questions. Constructed for this article.
| Question | A backup answers it | An export answers it |
|---|---|---|
| If the system fails this afternoon, can we carry on | Yes, if a restore is possible and in scope. This is what a backup is for. | No, not on its own. A file does not run your business. |
| Can we read our data without the vendor | No. The copy is the vendor's, in the vendor's system, in the vendor's format. | Yes, and this is the whole point of it. |
| Who can act on it | The vendor, and you, in the vendor's interface. | You, with any tool that reads the format, including a text editor. |
| What happens if the relationship ends badly | An argument about the contract and the restore process. | Nothing. You already have the file. |
| What shape is it in | Whatever shape the system stores, which is the system's business. | Whatever the export produces — and this is the part to actually check, row by row, before you rely on it. |
| How do you know it worked | A restore test, performed in advance, into a place you can see. | Open it. If you cannot open it, you do not have an export. |
The last row is the only one that matters on the day. A backup is verified by performing a restore, and a restore performed during an incident is not a verification, it is a hope. An export is verified by opening the file. That is why an export has a much lower verification cost than a backup, and why a business that has never opened its export does not actually have one.
The thing that surprises peopleA report export is not an archive
This is the part that matters most in practice, and it is a structural property of the records rather than a shortcoming of any one product. An invoice is not a self-contained record. It carries a number, a date, a reference to the customer, a taxable value, a tax value, and a total. It does not carry the customer's name, their address, their tax registration details, or their contact person, because those live on the customer record and the invoice holds a link to it.
So if you export invoices, what you get is rows that are individually meaningless and collectively very valuable. A constructed example. Suppose a Nox-Billings deployment issues 1,240 invoices in a financial year and you export the invoice rows for that year. You have 1,240 rows. Each row has an invoice number, a date, a customer reference, a taxable value, a tax value, and a total. Not one of those 1,240 rows tells you who the customer is. To make the file usable you need a second export of the customer records, and then you have to join the two yourself on the customer reference.
That join is the real test. It is a modest amount of work, and it is completely ordinary work — but it is work, and it is work that has to be done by someone, and doing it badly produces a file that looks complete and is subtly wrong. The invoices might contain a customer reference that does not exist in the customer export, because that customer was merged into another record after the invoice was raised. In NoxOrigin duplicate detection flags candidates and a person reviews them; nothing merges automatically, and match rules and merge behaviour are a setup decision. But a merge that was reviewed and approved still means the reference on an old invoice no longer points at a customer row you hold unless you exported the customer records as they were at the time.
What an export actually has to contain before it is an archive
This is the checklist to run against a file somebody has given you, whether that is a colleague at your own business or a vendor. It is deliberately blunt, because the failure mode is that everyone assumes someone else ran it.
1. Can you open it without the vendor's software? Open the file in something that is not the product — a text editor for CSV, a spreadsheet application, anything. If the only thing that reads it is the system that wrote it, you have a report, not an export.
2. Does it contain the records, or a summary of them? A report that aggregates is not an export. You need the individual records with their individual values, because a summary cannot be reconciled against anything afterwards.
3. Can each row be understood on its own? This is where invoice exports usually fail. An invoice row references a customer; it does not name one. If the customer file is not in your hands too, your invoice file is a list of codes and amounts.
4. Can you join the files back together correctly? Take two exported files and reproduce one known figure from memory — a total for a month you remember, an invoice number whose amount you are certain of. If you cannot reproduce it, the join is wrong and the export is not yet usable.
5. Does it survive the join? Check for records that reference something no longer in the second file. A customer merged after the invoice was raised will do this. These rows are not a minor edge case; they are exactly the rows you would need during a dispute.
6. Is it in a format that will still open in ten years? CSV in a plain encoding is a better answer than a proprietary format, and a plain text file with documented column names is better still. Write down what the columns mean. Column headers in a file that nobody documented are a riddle, and you will not remember the answer.
7. Do you know when it was taken, and does that date mean anything to you? An export is a snapshot. A snapshot is only useful if you know what it excludes — open invoices, unpaid balances, in-flight work, anything that existed only as a projection.
It is worth naming what a snapshot cannot carry, because this is where the mental model breaks. Several of the things a business would most want during a difficult week are projections rather than stored values, and a projection has to be recomputed. Paid is a projection of allocations, not a field on the invoice. Quoted against billed against collected are four separate states per client. The outstanding balance on an invoice is not stored; it is what is left after subtracting the allocations made against it. None of those are missing from an export because exports of invoices are records, and records do not contain projections. They have to be derived, and deriving them needs the payments and allocations as well as the invoices.
How the gap actually shows upHow the dependency gets discovered
The typical sequence is unremarkable and repeats. Everything is fine. A relationship deteriorates for reasons that have nothing to do with data. Someone asks a reasonable question — can we get our data out. The answer takes days, involves a person, involves a format conversion, involves someone deciding what a record is, and produces something that requires a tool nobody in the business has. By then the question is no longer operational. It is adversarial, and it is being asked by someone who has already stopped trusting the answers.
The cost of avoiding that sequence is not large, and it is worth putting in the same units as everything else in this article. A constructed figure: if the export work takes one person a day, and you do it twice a year, that is two days a year. If instead you do it during an incident, and the incident takes three days, and the result is unusable without further work, then the two days a year bought something considerably more expensive than two days.
The other half of the discipline is where the file goes. An export on the same system, or in the same email account, or in the same cloud folder under the same credentials, is not a hedge against the dependency it is meant to hedge. It needs to be somewhere the vendor does not control, in a format that does not require the vendor's software, and with enough context — what the columns mean, what is excluded, when it was taken — that it will still be readable by someone who was not there.
A last thing to be careful about, and it is a compliance point rather than a technical one. An export of your customer and invoice records is a copy of personal and financial data, held outside the system, and it inherits whatever obligations the original data carries. Where a question arises about what you must keep, how long you may keep it, who may see it, or what must be produced to an authority, that is a question for your own chartered accountant and for whoever advises you on data protection. It is not a question this article can answer, and we are not going to guess at it.
An export and a backup routine, in order
- Ask, in writing, for the retention period of backups, the restore point available, and whether a restore is whole-tenant or record-level. Save the answer. An unanswered question is itself an answer about dependency.
- Export the invoice data for a period, using the accounting-format export if you have an accountant who wants a particular shape, and the CSV or Excel export if you want to read it yourself. Both are documented for Nox-Billings; neither is documented for every product area, so check the inventory for yours.
- Export the customer records separately. Invoice rows reference a customer rather than naming one, so an invoice export on its own is a list of codes and amounts.
- Open both files in software that is not the product. If the only thing that reads them is the system that wrote them, you do not have an export.
- Join them and reproduce a figure you already know. If you cannot, the join is wrong and the file is not yet usable.
- Write down what the columns mean, what the file excludes, and the date it was taken. A file with undocumented column headers is a riddle for whoever needs it.
- Store it somewhere the vendor does not control, and restrict who can open it. It is a copy of your customers and your money.
- Then, separately: ask to perform a restore test. A backup that has never been restored is an assumption, and it is the one assumption you would most like to be wrong about during an incident.
- Put both on a recurring calendar entry. Twice a year is enough to matter. A schedule that depends on remembering is not a schedule.
Frequently asked questions
Do you back up my data, and can I get it out?
Our published capability inventory for Nox-Billings documents a backup and restore capability and CSV, Excel, and accounting-format exports, and the Nox-Tickets inventory documents CSV exports. It does not document retention periods, restore points, restore scope, or archive formats, and it does not document an export for every product area. We would rather tell you that than fill the gap with adjectives. If a specific answer matters to you, ask us for it in writing.
If backups are automatic, why would I need an export?
Because they answer different questions. A backup restores the vendor's copy of your data into the vendor's system, which helps you carry on. An export is a file you hold that you can read without the vendor, which is what you have if the relationship ends badly. A business with only the first is exposed to dependency, and typically discovers it during an incident.
Is a CSV export a full backup of my records?
It is a file you can read, which is the important half, but it is not automatically a full-fidelity copy. An invoice row references a customer rather than naming one, so an invoice export on its own is a list of codes and amounts. You also want the customer records, and you have to join the two yourself and check the join against a figure you already know.
How do I know my backup actually works?
By performing a restore, in advance, somewhere you can see the result. A backup that has never been restored is an assumption rather than a control, and a restore attempted during an incident is not a verification, it is a hope. This is why an export is worth having as well: you can verify one by opening it.
Where should I keep the export?
Somewhere the vendor does not control, with a documented set of column meanings and the date it was taken. Restricting who can open it matters too, because an export of customer and invoice records is a copy of personal and financial data. On what you must keep and for how long, ask your own chartered accountant.