Tenant backup, restore and migration

On a multi-tenant machine, backup stays whole-box: one encrypted .exovobak on one schedule captures every tenant. What changes is the restore side — the wizard on Admin → Backup & Restore (operator-only on a multi-tenant system, since the archive contains every tenant's data) offers three paths when you feed it an Exovo backup:

Restore the entire system

The same full restore as a single system: everything on the box is replaced from the backup, with a brief restart. All tenants come back exactly as they were when the backup was taken.

Restore a single tenant

The reason tenant-level restore exists: one tenant broke something, and the other tenants are on phones right now. Pick the tenant out of the backup — the wizard lists every tenant the archive contains by name and FQDN — and only that tenant is restored:

• It runs live. The target tenant is suspended for the duration and resumed after; every other tenant keeps signing in, ringing and recording throughout. No restart.
• The tenant is matched by identity, and a domain mismatch (say, a tenant that was deleted and re-created since the backup) is called out and needs an explicit confirmation before it will proceed.
• It's all-or-nothing: if a restore fails, the tenant is left suspended rather than half-restored — resolve the problem and run it again.

Migrate a standalone system into a tenant

The third path takes a backup from a standalone (single-organization) Exovo box and brings it in as a tenant — the consolidation move when a customer you host individually should become a tenant on the shared machine. Choose A new tenant (name, FQDN, extension limit — created on the spot) or overwrite an existing one, and the standalone system's users, trunks, routing, history and media all land inside the tenant. Machine-level settings from the old box (network, security hardening, and so on) deliberately stay behind — those belong to the host machine.

After a migration, treat it like any move between systems: repoint DNS and phone provisioning at the tenant's new FQDN, and re-check trunk registrations.

3CX and Yeastar imports on a multi-tenant box

The 3CX and Yeastar P-Series import guides apply unchanged on a multi-tenant machine, with one addition: the preview step asks where to Import into — a new tenant created on the spot, an existing tenant (a merge: same-numbered items are overwritten, everything else in the tenant is kept), or tenant 1.