Business Continuity & Backup

← Back to the Trust Centre

1. Purpose

This document sets out how xlabs (Pty) Ltd ("xlabs", "we") protects the availability of Clara and the data organisations keep in it: how data is backed up, how we recover from a failure, how changes are rolled out safely, and how we keep you informed during an outage.

It applies to Clara at getclara.co.za and its organisation sub-domains. Read it with the POPIA Statement and the security controls on the Trust Centre.

2. How Clara is hosted

Clara runs on managed cloud infrastructure:

• The application is hosted and delivered by Vercel.
• Each organisation's data is held in its own separate Supabase database, with its own file storage and encrypted secrets.
• Hosting and databases are currently in the European Union.

Because each organisation has its own database, a problem with one organisation's data does not spread to another's, and each database can be recovered on its own.

3. Backups

• Every organisation database is backed up through Supabase's managed backup service.
• Backups are encrypted, like the live data.
• Point-in-time recovery, which restores a database to a chosen moment rather than only to the last daily backup, is being enabled across production databases. Until it is on for a database, that database is recovered from its most recent daily backup.
• Passwords, API keys and connection secrets are stored in an encrypted vault inside the database and are covered by the same backups.

Email, files and calendars in accounts a user connects stay in the provider that holds them (for example Microsoft 365 or Google). Clara reads from those accounts; it does not replace their own backups.

4. Records survive everyday mistakes

Many recoveries never need a backup, because Clara is built so that records are not lost in normal use:

• Clients are never hard-deleted. A client is archived and can be restored, and their orders, quotes, projects, invoices and policies remain.
• Every insert, update and delete on key records (policies, clients, products, projects, orders, quotes, invoices, payments, expenses and supplier bills) is written to an audit log with the old and new values, whatever made the change. This lets us see exactly what changed and put it back.
• Client-facing sends, payments and accounting writes run only after a named person approves them, which limits the damage an automation can do.

5. Safe changes to the platform

Changes to the structure of organisation databases are the most likely cause of a wide outage, so they follow a staged rollout:

1. Dry run: the change is checked against the fleet without being applied, to show which databases it will reach.
2. Canary: it is applied first to a small set of databases, including our own template database.
3. Fleet: it then rolls out in waves, from a small slice to the rest of the fleet.
4. Halt on failure: any failure in the first wave stops the rollout, and in later waves it stops when failures pass a set threshold. Databases not yet reached are left untouched.

Changes are written to be safe to run more than once and to add before they remove, so a stopped rollout can be resumed without harm. Each database records the schema version it has reached, and Clara only uses a new feature once that database is ready for it.

6. Critical dependencies

7. Recovery approach

When an incident affects availability or data, we follow these steps:

1. Detect and confirm the problem, and identify which organisations and features are affected.
2. Contain it: stop any rollout, scheduled job or integration that is making it worse.
3. Tell affected organisations that we are aware and working on it (see section 9).
4. Restore service: redeploy the application, or recover the affected database from backup or to a point in time before the problem.
5. Check the restored data against the audit log and correct any records changed in the gap.
6. Confirm with affected organisations that service is restored, and record what happened and what we will change to prevent it.

Recovery objectives (how much data could be lost and how quickly service is restored) are being finalised. Once set, they will be published in this document and in customer agreements. Until then, we recover service as quickly as the steps above allow.

8. Testing

• We are setting up regular tests that restore a database from backup into a non-production environment, to confirm backups can be recovered and how long it takes. Results will be used to set the recovery objectives in section 7.
• Every schema change is proved on the canary databases before it reaches the fleet.
• New organisations are created from a curated template database, which is kept up to date with every change and confirms that a database can be rebuilt from known structure.

We review these arrangements, and the results of tests, at least once a year.

9. Communication during an outage

• We tell affected organisations without undue delay when an incident affects Clara's availability or their data.
• We give updates by email while the incident is open, and confirm when service is restored. We do not have a public status page yet.
• Where personal information may have been compromised, we follow the POPIA Statement and help the organisation notify the Information Regulator and the people affected.

To report a problem or ask about an incident, email miles@xlabs.co.za.

10. Ending your use of Clara

When an organisation stops using Clara, we export its data on request in a format agreed with the organisation, then delete it from our systems, unless the law requires us to keep it longer. Backups that still hold the data expire on the provider's normal schedule and are not restored except to recover the service.

11. Contact

Information Officer, xlabs (Pty) Ltd: Miles Marshall, CEO, miles@xlabs.co.za.
Information Regulator (South Africa): inforegulator.org.za

12. Review

We review this document at least once a year, and whenever Clara's hosting or recovery arrangements change materially. The version and effective date above identify the current version.