Migrate from Hosted to Dedicated

[VFRDavid]

I need to move my data from a shared, hosted system to a new, dedicated / on premise system. Everything related to the data that I need is "tagged" with membership in an appropriate user group. I cannot just take an entire system backup / restore - at least not without permission - since there are other people using the shared hosted system. What I would like to know is - which of the asterisk.* mysql (mariadb) database.tables in the shared hosted system need to have my user group's data moved to the new dedicated on premise system? I know that I have to move the users, user groups, campaigns, lists, DNC records, and optionally the various logs...I was hoping that someone had a more definitive list of the actual table names that need to be (partially) migrated in this type of a situation. As I sort of alluded to earlier - I considered doing a complete system backup - which I could restore and then DELETE the stuff that I don't want / need afterwards - just don't know if I will get permission AND this might step on other data / settings that are already to go in the new system.

Both systems are running v7 of ViCiBox - they might be slightly different vintages - so I know I would have to check the schemas to be sure there aren't any new / updated fields - but again - if I had the list of tables, I think that I could more easily attack that issue...

I hope that this describes my situation welll enough for someone to give me some advice...does ANYONE have ANY (constructive) advice out there on what the best course of action might be? (The selective backup and restore ... the total backup, restore then delete ... or something that I haven't thought of yet?)

Thanks again for any reply / attempt to help me out...

David

[Noah]

Sounds like a migration, where you stand up the premise system first, and keep the hosted up and available for a bit for historical purposes and access to campaign settings, if you have to brut force manually enter and add stuff to your prem install.
A full backup and restore is probably your best bet though....if you can get that backup file.
Nearly all the tables are "required" user group ties into almost everything.

If the db on hosted is "older" from a db structure perspective than premise you can run the update.sql stuff in /usr/share/astgui...extras

Best - Noah

[VFRDavid]

I should be able to get the backup without too much difficulty - as long as I'm going through that - the only thing missing would be the actual recording files - so - if I could get my hands on those as well - the restore would take care of the pointers (provided that the IP Address Update is all that's required to update the pointers - if not - I'll have to leave them where they are now, or, update all of the pointers manually...

If there is anything else in the process that I *should* be doing - again - since I'm using the entire MySQL backup - is there anything else that I should be moving / cleaning up / dealing with ?

Thanks again for your reply! I really do appreciate it...David

[VFRDavid]

(CALL recordings...not the system audio files - those got installed with the new install)...

[williamconley]

Get yourself a nice FTP system to store your audio files and backups *off* the Vicidial server. Catastrophic failure then will require only a restore from last night's backup and you're online again.

After you have confirmed access to an FTP server with read/write access including the ability to make new folders, configure your Vicidial system's astguiclient.conf file with those FTP credentials. Engage backup (with the ftp switch to push to the ftp server). Then TEST the audio file ftp script (it's in crontab) with a single audio file. Verify that your http setting for that single file worked by going to that lead record and clicking on the recording link. If it bounces you successfully to the new file location in the FTP server, activate the FTP script in crontab. If not, adjust the http link settings until it does work before activation.

Then configure the crontab to delete the ORIG and FTP folder contents after XX days, since these files have all been pushed to the FTP server and are no longer needed (avoid filling the HD with them over time).

Configure MySQL to either not use binary logging or rotate/delete the binary logs to avoid filling the HD with them (and be sure your database backup is pushing to the FTP server one more time while you're in here).

Configure the log archiving script. This will push older logs into archive table and out of the live tables. While these log tables will never fill the HD, if you don't do this, eventually they will bloat their data table files to the point that Vicidial can not deal with them. Crashed tables stop the dialer very suddenly during heavier load times (ie: when you're busy, not cool). Later versions of Vicidial allow reports to optionally pull data from these log tables, which is nice.