Backup All Campaigns Leads User Carrier ...

[zenithbsolutions]

Hi,

I have an old server from which I would like to take backup of campaign, users, phones, leads, carriers & call logs and move it to a new server as my old server is giving me trouble.
I hope it can done through database backup.

Kindly help me how to acheive it or let me know the database name (asterisk) to backup or guide me if it is possible or not.

Thank you.

[williamconley]

1) Welcome to the Party!

2) As you are obviously new here, I have some suggestions to help us all help you:

When you post, please post your entire configuration including (but not limited to) your installation method (7.X.X?) and vicidial version with build (VERSION: 2.X-XXXx ... BUILD: #####-####).

This IS a requirement for posting along with reading the stickies (at the top of each forum) and the manager's manual (available on EFLO.net, both free and paid versions)

You should also post: Asterisk version, telephony hardware (model number is helpful here), cluster information if you have one, and whether any other software is installed in the box. If your installation method is "manual/from scratch" you must post your operating system with version (and the .iso version from which you installed your original operating system) plus a link to the installation instructions you used. If your installation is "Hosted" list the site name of the host.

If this is a "Cloud" or "Virtual" server, please note the technology involved along with the version of that techology (ie: VMware Server Version 2.0.2). If it is not, merely stating the Motherboard model # and CPU would be helpful.

Similar to This:

Vicibox X.X from .iso | Vicidial X.X.X-XXX Build XXXXXX-XXXX | Asterisk X.X.X | Single Server | No Digium/Sangoma Hardware | No Extra Software After Installation | Intel DG35EC | Core2Quad Q6600

3) Best method for this is to:

* Run the backup script: /usr/share/astguiclient/ADMIN_backup.pl OR
* run mysqldump on the asterisk database

One way or another, you want the entire database backed up.

Then you can copy that backup to a brand new freshly installed AND TESTED!!! server. Note of course that if you do not fully test the new server (to be sure it is capable of dialing in autodial mode) before you continue, there's no reason to believe it will work after your database copy. So: Test it. Be sure it works. Then back it up before you continue (so you can get back to a working server and try again if something goes wrong).

For fun, you could also copy all the tables for the modules you do NOT want to bring along for the ride. For instance: the system settins in admin->system settings and the server listed in "admin->servers" is correct and has just been tested. You may want to bring those back after the restore process to avoid having to edit them after the DB restore.

Next, you'll restore the old DB over the new one. I usually DROP and CREATE the asterisk database so it's an empty DB awaiting the restore process. This is done by executing the backup sql file you copied from the old server to the new one.

Code: Select all

mysql asterisk < filename.sql

Note that you may need to use "-pPASSWORD" if the root use has a password.

Now you are in an odd situation. You have all new code and an all OLD database. So the goal is to upgrade the database to match the code, then made any adjustments in the database necessary for it's new home.

So next stage, you will follow the UPGRADE instructions in /usr/src/astguiclient/trunk/UPGRADE to upgrade just the database from your old version to the new version.

If you check the "system settings" db_schema value in the DB, you will find the exact last line of upgrade sql code that was run on this database. Find that code in the "upgrade_2.???.sql" file matching your original server. Delete everything before it, and execute everything after it.

Notes:
a) Do not get confused about the "linux" file system ordering vs numerical order. When you get to 2.8, 2.10, 2.12 and 2.14 go in that order.
b) If you have a crash, delete all the lines above it (because they've already been run), resolve whatever caused the crash, and then run the line that crashed again and all after it.
c) Crashes on very old system upgrades are often due to newly added indexes that have record violations due to having multiple records with the same value in a "Unique ID" field or field combo. In most cases, the entire table can be deleted. If you want to get picky you can attempt to combine the records sharing that uniqueID field instead. Our experience has shown that these violations tend to occur on tables where Vicidial code will make records "as needed" during operation. So deleting them won't break anything, vicidial will just make them again (without violating the index, in the newer code).

Once you get to the "matching database schema", now you need to run the ip update script with the "OLD" IP being the previous server's IP address and the NEW IP being the new server's IP address.

And finally, the Environment ... has changed. You may have a different asterisk version. Carrier settings may no longer match the Asterisk version (if you have special asterisk code in the dialplan extensions fields or custom dialplan fields). But most often it's just the asterisk version itself. This value must be set in the admin->servers page.

Code: Select all

asterisk -V

Of course, you could just restore that one table IF you mysqldumped that one table earlier for ease of restoration. Same goes for the system settings table.

[zenithbsolutions]

Thank you William you are the lucky charm for vicidial forum. I will be taking backup of the database from one server and move it to another cause I couldn't get upgraded on the present dedicated server. So I wll be getting a new server with higher ram & core specs and moving the database over there inorder to avoid the setup again. Both servers were fresh installed yesterday just need to move all the data from old specs server to high specs server. So I hope there will not be any major version clashes.

Will try your backup procedure shorlty and update you.

Thanks Again