How to back up your PSA with a read-only database
The backup nobody thinks about
Almost every MSP runs a PSA of some kind, and almost every one of them assumes the same thing: that the vendor is backing it up. For the most part, that is true — it is backed up by the vendor (hopefully). If you haven’t yet asked your vendor about it, now is a good time to ask them to provide their backup strategy to you in writing.
But the vendor’s backup is not the same as yours — and you have no access to it. They back up their platform so they can recover their service; that is not the same as you holding an independent, usable copy of your own data.
As an MSP, you preach the 3-2-1 strategy to your customers all day long. You tell them to make sure they have good backups in place, and you always tell them the same thing: the vendor is not responsible for your backups — you are.
The PSA is the single most important system in your business. It holds every ticket, every time entry, every contract, every invoice and every asset record you have — and yet virtually no MSP keeps their own PSA data backed up.
Why?
The answer is simple: because no one tells you there is a way to back it up yourself. Until now, that is!
The read-only database
All the major players — HaloPSA, Autotask and ConnectWise — offer what is generally called a read-only database: a complete copy of your data, exposed either as a set of views or as full database access, and refreshed every 24 hours. It is one of the most useful and most overlooked features in the platform.
The beauty of these databases is that they are exactly that — read-only. You are not touching production, so nothing you do against them can change, corrupt or slow down the live PSA your team is working in. It is a mirror you can look into and pull from but never write back to — though, as we’ll come to later, the API gives you a way to push data back when you genuinely need to. That read-only nature makes it safe to hand to reporting tools, or to anyone who needs the data, without giving them keys to the live system.
What makes it so powerful is that you are getting the real data — the actual tables, with the actual relationships between them. Not a flattened CSV of tickets with the context stripped out, but tickets linked to time entries, linked to contracts, linked to companies, contacts and invoices, exactly as the platform stores them. That structural fidelity is the difference between “we have some spreadsheets somewhere” and “we have a genuine, restorable copy of our business.”
There is, however, a cost to having a read-only database. Most vendors charge roughly the price of a standard licence for read-only database access, and some require you to upgrade to a new licence type — but that is a small price to pay to have every record in your business available on demand, through direct access to the database, whenever you need it (within the 24-hour refresh window).
Turning it into a real backup
On its own, the read-only database is a near-current mirror of your data. To turn it into a backup, you copy it. Run a script once a day that pulls the whole database offsite — into any database of your choosing, on your own infrastructure, that you can keep, move and restore however you like — and you now hold your own independent copy, entirely outside the vendor’s control.
Do that every day and you also build up a history: each daily copy captures the state of your data at that point, so you can see what changed since the last run and recover from it. It is not a live, to-the-second backup — if a record is both created and deleted inside the same 24-hour window it will slip between copies — but for the majority of real-world scenarios, such as accidental deletions, a botched integration run, a billing query about last year’s ticket, or a compliance request, a daily offsite copy in your own hands is exactly what you need. That makes it a genuinely viable PSA backup solution.
It also solves one of the biggest problems MSPs face when moving to a new PSA: getting their data from the old vendor, which is not always as easy as it seems. Whether it is an Autotask to HaloPSA migration, a move to or from ConnectWise, or any other switch between platforms, the hardest part of a PSA migration is always extracting complete, well-structured data from the system you are leaving. A daily backup means that if you ever switch, you still have your data — even after you have cancelled and are no longer a customer — because it is already sitting safely in your own systems. It is the most effective insurance against vendor lock-in there is.
Why the API alone isn’t enough
The obvious objection is “why not just use the API?” to do the backup — and it is a fair one. The trouble with APIs is that you are working across many endpoints, and it is not always obvious how they link together unless you really understand how the API is built. They are also rate-limited, so a full extract of any sizeable instance is slow, and they expose the data the vendor chooses, in the shape the vendor chooses — very seldom the full picture.
Where the API comes into play is alongside the read-only database rather than instead of it. Because we hold the full, structured picture in the database and can use the API to write back, we have everything we need to push data into a PSA when you need to restore or migrate to a new system — which makes putting the data back straightforward when the time comes.
How we do it at Sondela
We wrote a script that takes a copy of your database every day and stores it in an offsite database (which you host), so your data is there the moment you need it — and when you do need to put it back, we use the API to restore it into a PSA.
Within that tool we have built a front end that sits on top of that read-only data and makes sense of it for you. Rather than facing a wall of hundreds of interlinked tables, you work with your records through an easy-to-use interface — almost a mini-PSA — where you browse the business the way you actually think about it: open a company, see its tickets, click into a ticket to see the time logged against it, and so on.
It also means that if your plan is simply to keep the records for historical reference rather than migrate them into a new PSA all at once, you have a nice easy view of your data — everything stays readable and searchable in one easy-to-use place.
I’d bet the vendors never designed the read-only database to be used quite like this. But it is your data, and you have every right to keep it and use it any way you like.
Keeping it all secure
A daily offsite backup is a copy of your most sensitive business data, so it goes without saying that it must be treated accordingly. It needs to live somewhere secure, with encryption and tight access control, and it falls squarely within your data-protection and GDPR obligations — the same care you would apply to any system holding client and financial information. It is worth deciding up front where the copy is hosted, how long you retain each daily version, and who is allowed to query it.
Frequently asked questions
Can you back up your Autotask, HaloPSA or ConnectWise data?
Yes. All three of the major PSA platforms offer a read-only database — a complete, structured copy of your data refreshed every 24 hours. By running a script that copies it offsite each day, you hold your own independent backup of your PSA data, entirely outside the vendor’s control.
Does Autotask (or HaloPSA) have a read-only database?
Yes. Autotask, HaloPSA and ConnectWise all provide read-only database access, exposed as views or as full database access and updated on a 24-hour cycle. Most vendors charge roughly the price of a standard licence for it, and it is the cleanest way to get direct access to your real data.
How do I export my data from Autotask or HaloPSA?
You can export data through CSV or the API, but both are partial and rate-limited and rarely give you the full relational picture. A read-only database copied offsite gives you the complete set of tables and relationships, which is a far stronger foundation for backup or export than CSV files.
How does this help with an Autotask to HaloPSA migration?
The hardest part of any PSA migration is getting complete, well-structured data out of the system you are leaving. If you already hold a daily read-only copy of your data, you have removed that problem before it starts — and the API can then push the data into the new PSA, making an Autotask to HaloPSA migration (or any other move) far less painful.
What happens to my data if I cancel my PSA?
If you have been backing up your read-only database offsite, you keep your data even after you cancel and are no longer a customer — because it already lives in your own systems. Without that, you are dependent on whatever export the vendor allows you before your access ends.
Conclusion
You would never let a client run their business on a system with no independent backup. Your PSA deserves the same discipline. The read-only database — copied offsite every day and made sense of with the right tooling — gives you a controlled, structured, restorable copy of the data your entire operation runs on. It is protection while you are with your PSA vendor, and a clean way out if you ever leave. It is one of the highest-value, lowest-drama things an MSP can put in place, and almost nobody does it until they wish they had. Now is the time to speak to your PSA vendor to get access to your read-only database — not when you are in your cancellation period and they push back on giving you the data.
