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.
3 Likes
I agree that this feature will make stronger the MULTI TENANT Tool
1 Like
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.
1 Like
Following up on my last comment…instead of using the standard Tenant Prefix ID of “T1, T2, T3…T28”, you could require that we provide a “Custom Prefix ID” such as the following…“My First Customer” could be “MFC_” which would be unique and not overlap your default tenant mapping. Also, you could make the Backup/Restore module only be available to backup and restore a single tenant only if the tenant is using a Custom Prefix ID instead of the Default Tenant ID, which would be another assurance tactic to ensure it would not overlap other tenants.
I strongly believe that this feature would make your multi-tenant feature a much stronger and extremely competitive product when comparing to other platforms in the market. This could also lead VitalPBX into the Class 3/4/5 arena and breakaway from other comparable PBX systems such as Sangoma, Switchfox, 3CX, and others that are being used for multi-tenant platforms. Just thoughts and ideas trying to help make VitalPBX that much better.
This would be fantastic, it would make migrating Tenants between servers a breeze.
1 Like
Regarding this topic, a single-tenant backup could also be used as a template for onboarding new clients.
We could create different baseline backups tailored to specific customer profiles or business types. When a new client is acquired, restoring the corresponding backup template would instantly provision the environment with all standard configurations already in place. This approach would make the account creation and setup process extremely fast and efficient.
1 Like
And once again, VitalPBX is stating that it’s currently impossible to achieve this because the database architecture is sharing a single database. But yet, each of the tenants has a Tenant ID to be able to create a multi-tenant platform. Because we have the capability of customizing this Tenant ID, it should be possible for the backup server be able to identify if the tenants are using the default TID architecture or if they have a Custom TID.
My vision for Backup/Restore is that you can have a Full Server Backup to migrate Server-to-Server, and then a “Single Tenant” option to back up one tenant for migration, or a list of tenants to migrate. But only a Tenant List selection will be available that have Custom TIDs. This would ensure that only tenants with those custom TIDs would be able to be backed up and moved to another server without conflicting on the new server.
Having these capabilities for us as a ITSP/MSP Provider would be a powerful tool. And yes, this option would also create the ability to have a Default Tenant that could speed up the onboarding process of new clients. So, I’m not understanding how it would make VitalPBX to re-engineer and redesign the whole database architecture of the system. This should be an easy add-on with that approach and should only take a few weeks to engineer this and make it available in the next couple of releases.
I’ve discussed this with other people I know that have designed and coded custom multi-tenant Asterisk platforms for some major service providers, and they have confirmed that this would/should be a fairly easy task, as they have done that with their systems to make it easier on their Systems Administrators to manage and maintain their servers.
I’m not sure why VitalPBX is avoiding this, or dragging their feet on the subject, as this would make them an extremely stronger and more competitive manufacturer in the industry. I love this platform as it has provided us a multi-tenant Asterisk platform, which is something we’re familiar with. After looking into Netsapiens (or Crescendo now), Bicom, FreeSwitch, ThirdLane, and a couple of others, we would have to completely learn a whole new platform and language, go through their training and certifications, and also spend a lot more money to achieve the same thing. The only other thing I’d like to see is VitalPBX release a Carrier Class 4/5 platform similar to IvozProvider, which includes additional items such as Kamailio for SIP Users and SIP Carriers proxies for better security and routing, plus being able to take the call routing load off of the servers and allow them to be the PBX, while also having a single domain FQDN on the public side front-end while routing to multiple PBX servers on the back-end. I really like the architecture of IvozProvider except for not having a more “Up to Date” Front-End WebGUI for management. Their approach provides a solution that separates out the SBC, DB, and PBX, which can also provide better redundancy by means of HA or even GEO-HA.
IDK…maybe I’m getting ahead of myself at the size we currently are, but we have major goals to grow our business and would love to not have to move to another manufacturer to accommodate those goals as we scale up.