We would love to be able to create a single-tenant configuration backup to be able to migrate a tenant from one server to another. Right now, the only system backups we can do is server-wide and backs up all tenants and configuration settings. Or least be able to have a simpler process of moving a single tenant from one server to another.
I agree that this feature will make stronger the MULTI TENANT Tool
At the moment, this type of functionality is not feasible due to the way VitalPBX is architected. VitalPBX uses a single shared database for all tenants, where data is scoped internally by a tenant ID. This means that all configuration data—such as extensions, trunks, inbound/outbound routes, and more—is stored in shared tables, with each tenant’s records identified by a unique tenant identifier.
Because of this design:
- Data across all tenants is deeply interwoven in the same database structure.
- There are complex dependencies between tables (e.g., linking extensions, users, and dial plans), many of which rely on internal IDs that are not portable across servers.
- Exporting just one tenant’s data without affecting others or breaking referential integrity would require an intricate, manual process that’s highly error-prone.
We understand the value of such a feature, especially for migrations or backups, and it is something we are exploring. However, to properly support tenant-level portability, we would likely need to move toward a more isolated model (such as one database per tenant), which is a significant architectural change.
Even though there is a single database, whether it’s MySQL or MariaDB, etc…isn’t it possible for the multitenant version to create a new DB instance in the database that is isolated from the other tenants. Essentially creating an individual database for that tenant to make this achievable? Or, is it possible with the multitenant version to have the Tenant Backup feature use the Tenant Prefix as it’s reference point when making the backup? I understand that if you use the standard prefix ID that this could overlap with another tenant on a different server, but you could require that the “Tenant Backup” feature would only work if you use a unique prefix ID instead of the autopopulated standard ID. Just a thought.