By the Onsites AI team · Last updated · 5-minute read
Nobody wants a disaster-recovery lecture; every team wants the one that arrives too late. So this guide inverts the usual order — it starts with what support teams actually lose in an incident (yesterday's conversations, this quarter's invoices, the CRM record of who promised what), then works backwards to the smallest backup routine that makes those losses impossible. It covers all three delivery shapes — free cloud, paid cloud, self-hosted — because the recovery story is the single biggest honest difference between them.
Rank your data by replaceability and the priorities write themselves. Conversations and CRM history: irreplaceable — a rebuilt product page is a cost; a lost record of what you promised customer #302 in March is a dispute. Invoices, quotes, orders: legally sensitive, usually reproducible but expensively. Attachments and images: annoying, reproducible from the customer's side in a pinch. Configuration: tags, SLAs, routing rules, templates — tedious to rebuild, but documented in your runbook if you followed the export ritual. A backup plan is therefore not one big copy; it is a schedule where the irreplaceable data is captured most often.
Free cloud: workspaces are not backed up server-side — this is the stated design and the free tier's one real obligation. The duty of backup transfers entirely to you: use Settings → Exports on a schedule (the weekly exports habit exists for exactly this), keep the CSVs and JSON on your own drives, and understand that a workspace-side catastrophe means rebuilding from your last export, not from a vendor promise. Make the export automated-adjacent: same admin, same weekday, same checklist line. Paid cloud: automatic encrypted backups are included — snapshots handled server-side, no operator duty beyond keeping your own off-site export on the same cadence you would any SaaS you care about. Self-hosted: the desk ships with backup and restore scripts in the deployment guide, and the entire recovery regime is yours — which sounds like a burden until you notice it is also the only shape where backups are under a policy you wrote, with copies in locations you chose, verifiable by drill rather than by trust.
The storage rule survives translation: three copies of the data, on two different media, with one off-site. Concretely on a self-hosted box: the live volume is copy one; a nightly database dump plus a weekly attachments snapshot to a second disk or NAS is copy two; a rotated encrypted copy to a bucket, another building or a colo drawer is copy three. Set the cadence by damage tolerance, not ambition: if a day's conversations disappearing is acceptable, nightly covers you; if the morning's tickets must survive lunch, you want dumps twice daily — they are cheap, because conversation text is megabytes and even attachments rarely strain a gigabyte for a small team. Encrypt the offsite copy, and decrypt-test it once: an encrypted archive nobody has ever opened is Schrödinger's backup.
Two numbers define every recovery plan worth the name. How much data may vanish? (the recovery point — "we lost the last 4 hours" is an RPO of four hours). How long until the desk answers customers again? (the recovery time — a restore that finishes Thursday for a Monday outage is a five-day RTO). Write both down as small business commitments: for a three-person team, "lose at most 4 hours of conversations, desk back within 2" is a defensible and entirely achievable target; for a regulated enterprise, hours tighten and the plan grows, but the shape — dump, second disk, offsite, drill — does not change. The self-hosted scripts exist precisely to compress RTO: tested restore is a documented sequence, not an improvisation.
When the desk dies, the plan earns its keep in two hours of choreography. Minutes 0–15: triage and switch. Confirm scope (one workspace, one server, the whole host), decide restore-versus-repair from the failure signature, and start answering customers where you can — the auto-attendant on your site can hold "we are experiencing issues, replies delayed" while the status template goes out on active threads. Minutes 15–90: restore by the runbook. Fresh VM or the standby, latest dump, attachment snapshot, verify sign-in and a known thread; resist debugging the broken instance in parallel — rebuild first, forensics later, because customers care about availability, not autopsy. Minutes 90–120: verify and inform. The drill's checklist in miniature — known thread renders, inbound email connects, a test message flows from widget to queue — then an honest all-clear to affected customers with what was and was not lost (your RPO, stated plainly, buys more goodwill than pretending it was nothing). Write the timestamps and gaps into the runbook the same afternoon; the delta between the planned two hours and the actual ones is next quarter's drill syllabus.
Backups are proven by restoration, and only by it. The drill is unromantic: on a spare machine or a fresh VM, restore the most recent backup end-to-end, against the clock — spin the compose stack, load the dump, point the attachments directory at the snapshot, sign in as a test admin, open a known thread from last week, confirm a known invoice renders. Time it, log the result, and fix whatever the drill exposes before it exposes itself during a real incident. Teams that drill quarterly discover small breakages (a moved bucket credential, a full restore disk, a mis-encoded dump) on a Tuesday afternoon in a good mood; teams that skip drills discover them while customers watch. Write the successful sequence into a one-page runbook — future-you, at 2 a.m., will read no further than the second step, so the second step had better be right.
Close the plan with ownership: a named person holds the backup keys, the runbook and the drill calendar, and that person taking a vacation is itself a documented risk with a deputy. Disaster recovery is not a product you buy; it is a habit with a price tag that only seems expensive until you compare it to the invoice for losing a year of customer history.
Are free-tier cloud workspaces backed up?
No — free cloud workspaces are not backed up server-side by design. That is the free tier's one real obligation: export your data regularly from Settings and keep copies on your own storage. Paid cloud workspaces include automatic encrypted backups.
What should a small team back up and how often?
The irreplaceable small stuff most often: conversations, CRM records and documents daily or twice daily (text is only megabytes), attachments weekly, with an encrypted off-site copy on rotation. The weekly-export ritual covers the free-tier cloud case; backup and restore scripts cover self-hosted.
What does 3-2-1 mean for help desk data?
Three copies of the data (live volume, nightly dumps to a second disk, rotated off-site copy), on two different media, one of which is off-site. Encrypt the off-site copy and verify you can actually decrypt and restore it at least once.
What are RPO and RTO in plain language?
RPO is how much data you can afford to lose (an RPO of 4 hours means at most 4 hours of conversations vanish). RTO is how long until the desk serves customers again. Write both as business commitments — e.g. "lose at most 4 hours, back within 2" — before an incident sets them for you.
How do we prove our backups actually work?
Run a quarterly restore drill on clean hardware: rebuild the stack, load the latest dump and attachment snapshot, sign in, and open a known conversation and invoice. Time it, log it, fix what breaks, and keep the successful sequence as a one-page runbook.