glibc update and other update elements on production server

[forever]

Dear Vicidial Community

I hope that you are all well!

Due to the expense of lead data on our system and increasing agent quantities we are looking at third party hybrid cloud/on premises backup solutions for our Vicibox server and potentially automated DR as well. I am not looking at a DIY/manual approach for this as it will not tick all the boxes for us. I'd have virtualised originally but the manual dissuades that.

However, the key issue I am having is that the linux backup agents for most of these solutions (the rare ones I can find that state specific support for OpenSUSE) seem to require a newer version of glibc (whatever that is).

Please excuse my novice linux skills, I am hoping that someone may be able to assist. Is this something that is easy to update (and perhaps other elements also) without breaking a mission-critical production server? I've largely left it as-is in terms of the 'if it aint broke dont fix it' methodology.

Our current versions are as follows:
Vicibox with Vicidial 2.10-452a
Build 141111-0554

For reference the linux components as shipped with this version of Vicibox:
OpenSUSE 13.1 x86_64
Kernel 3.11.10-29-default
glibc 2.18

I'm not sure if it's useful to the support request but as per forum policy etiquette please see below:
1) Version of VICIDIAL (as above)
2) loadavg 0.44-1.2 across CPU cores (I think we're on about ~30% overall CPU usage with maximum ~70 concurrent system calls so far)
3) Server Specs - Fujitsu RX1330M1 Rack Server / Xeon 3.1GHz Quad Core / 16GB RAM / 4x 600GB SAS 15K RAID 10 / 512MB Hardware RAID / Intel dedicated server NIC
(13 agents / blended ratio outbound and inbound)
4) Codecs used G711
5) VOIP or PSTN - G711 VOIP SIP trunks with Bria Stretto SIP endpoints on the PCs
6) OS - OpenSUSE 13.1 (as above)

Thanks in advance - much love

[mflorell]

Most VICIdial admins just use the built-in ADMIN_backup.pl script(which has the ability to FTP to a separate server) and put an entry for that script into the crontab to run regularly. We have several clients that use those backups to bring up warm spare servers based upon what server in their cluster has gone down. That's why there really hasn't been a need for integration with costly commercial backup solutions.

[williamconley]

I concur. We have plenty of servers and the backup routine on all of them is very simple and fully automated. The Vicidial-stock backup perl script does the trick. Copies everything you could need for reconstructing a server in case of catastrophic HD failure (this has been tested).

First configure and test access with write permissions to an FTP server. The put those permissions in /etc/astguiclient.conf's "REPORT" section.

Code: Select all

# REPORT server connection information
VARREPORT_host => 10.0.0.4
VARREPORT_user => cron
VARREPORT_pass => test
VARREPORT_port => 21
VARREPORT_dir => REPORTS


Test with this at the CLI to be sure it all runs (verify on the ftp server that the backup set arrives!):

Code: Select all

/usr/share/astguiclient/ADMIN_backup.pl --ftp-transfer --debugX

Next configure the backups to run, and automatically send the data through the aforementioned FTP connection

Code: Select all

crontab -e

Add this at the bottom.

Code: Select all

## Vicidial Backup
## Leave before midnight in case of "emergency backup" during the day
## ... don't overwrite TODAY's backup, make a new one!
45 23 * * *  /usr/share/astguiclient/ADMIN_backup.pl --ftp-transfer >/dev/null  2>&1
#options: --db-only --db-without-logs --without-web --conf-only --without-db
#    --without-conf --without-web --without-sounds 
#         --without-voicemail --without-crontab --ftp-transfer --debugX --debug --test

In the end, you'll have rolling daily backups, with a number for each day of the week that overwrite the prior week as they go.

[forever]

This is thoroughly excellent THANK YOU both.

Does this back up all data on the server in its entirety (leads/lists/etc) or does it leave out things like call recordings?

Likewise is it tolerant of things like a WAN disconnection (not very likely as it is an all-Cisco environment with a 50/100 fibre ethernet leased line ) -- or am I better off backing up to a local FTP server and then in turn synchronising that with cloud/remote storage as a secondary action?

Also this particular customer may outgrow their single-server setup in a few months --- if I wanted a little bit of paid assistance with setting up our first cluster (or even better, migrating the existing one box solution to a multi-server environment) who would be the best person to speak to?

[williamconley]

This backs up everything except client audio. There is a section in the crontab -e that deals with recordings, and there is a "commented out" ftp script that will copy those to an FTP server (ie: Get them off the vicidial server) and a followup script that will copy them to a backup FTP server (ie: and now you have a backup).

That's what the manual is for, and that uses the other set of ftp credentials in the astguiclient.conf file.

The script can also be activated manually with --debugX (for debugging) and --help (to do nothing except show options). When testing, it's fun to use the debugX option along with the "limit=1" option (see precise method in --help) so you can see it move ONE file and verify that everything worked as expected.

The ftp transfer script will also change the recording link in the Vicidial interface to the file's new home. So you'll want to verify that the new link works. This makes the movement of the audio files to the ftp server (and new web home) seamless to the administrators who may later want to listen to the recordings. And the 2nd ftp service then becomes a "catastrophic failure" restore location for backup purposes.

Nothing resides on the Vicidial servers themselves. Concept: If you *do* have a drive failure, and you go to the trouble of rebuilding the server and restoring the database ... do you also want to have to wait for 2.5Terabytes of audio recordings to copy to the restored hard drive? Not really. If they are not on the server at all, then that does not matter regardless of how large your audio recording library becomes. Separate storage, unrelated to the Vicidial restoration. Especially if you create a domain name for the final storage to guard against IP changes.