Cloning a ViciBox system

[darryldale]

We have been live with our Vicibox system for about a month now (guesstimate) and it has been working great. Couple of small issues we are still working through but in general have been very happy with the system provided by the guys at ViciDial.

Having said that I now need to make sure I have a backup system available off-site if the system I have here goes down.

We are small enough that we currently have a one-box system that does everything. My plan is to buy another system with similar specifications and copy the appropriate files over to the new system.

Having said that does anybody have a list of all the files I would need to copy from the current system over to the new one? Off the top of my head I'm thinking:

a) All asterisk conf files
b) All the files from my audio-store
c) My custom scripts to load my new leads nightly

Anything else?

Darryl

[williamconley]

there is a backup script in /usr/share/astguiclient, start there (it includes ftp transfer to push to your spare)

you will also need any client recordings (of course, there's a function in crontab that can be activated to push those to an ftp server as well)

you'll want to set the system to auto-update the server ip (with the script in that same folder) at reboot, and another script to take all these files being sent and "apply them" after they all get sent every day. then if your primary system ever "dies" the spare will actually be a "hot" spare.

1) create all backups before midnight (so that if you "panic" and create a new backup because of a dying drive, you will NOT be overwriting THIS MORNING's backup, you'll be overwriting LAST WEEKs instead )

2) copy all ftp recordings constantly and push to a non-related web server (archive), so they are independent of the vicidial system entirely (the ftp method will change the links in vicidial to point to them wherever you want them to be, as long as they are available on the web)

3) after the backups / files are moved, set the system to reboot and auto-update the ip address of the server ... BUT remember that any "Registrations" will interfere with the registrations of the REAL server, so you may need to disable the "carriers" until you actually go live (change the "Y" not "N" for active until you actually need it). Enterprise level carriers often have no registration, so also be sure that the IP address of the Hot Spare is AUTHORIZED at your carrier.

[darryldale]

Thanks for the info.

Sounds like I've got something to keep me busy this weekend.

Darryl

[striker]

hi

why cant to try acronis backup or g4u. as your are going to same specification servers.
as i am using acronis for past 1year for vicibox cloning , there is no problem i faced in clonig

[Kumba]

You can run into issues with the cloning because a lot of the system devices are enumerated by UUID. For instance, the hard-drives and NIC's will require you to edit the udev/fstab/grub files and make sure they are pointed right. Not the end of the world but not as simple as just cloning the drive.

For an ongoing back-up, you best bet would be to install ViciBox Redux on a machine, and then just push your back-up script from the primary dialer to it. That way if something horrible did happen, you could recover in under an hour (or less).

[darryldale]

Thanks for all the info guys.

My first thought was to just clone the hard drive but it sounds like I'm going to setup a second ViciBox and configure it to copy over the appropriate files each evening.

Darryl

[williamconley]

Vicidial can be cloned, but that's a LOT of disk writing every evening to keep it "up to date" OR a lot of disk writing at that crucial moment to try to restore the image onto a functional machine and "make it live".

BUT: at 2AM when neither you nor the equipment has anything better to do .. an automated mirror-type system would make your spare very hot.

[darryldale]

Well since I want to keep the "spare" off-site here is my current plan:

a) Setup the live system to dump it's backup to an internal machine every night around 2am
b) My normal backup process starts at 3am so those backup files will get archived onto my normal backup medium

I'll have the spare off-site and if anything ever happens I'll take the current backup from the previous evening and restore the files to the spare, change the ip address on the spare and fire it up and if all goes well nobody should even be able to tell the difference (if not for the little bit of downtime).

Darryl

[williamconley]

Now: Make me proud and TEST IT once! (USE the spare server for a day, or at least part of a day.)

[darryldale]

Oh don't worry, I've seen some weird looks on peoples faces when I say "You mean you've been backing up for years and never bothered to test them even once?".

I'll come in on a Saturday when our call volume is lower and go through a full phone system disaster recovery scenario to make sure it works OK.

Darryl

[williamconley]

Failing that you should AT LEAST reload the "asterisk" database into the 'OTHER' server as an asterisk database. ensure all your data is there. with that, the system can be rebuilt. if that's missing or corrupt ... your backups are worthless. and you do not have to down your server to test it (for instance: you can load it into a different server, even a virtual one and you can name the database something other than asterisk when you load it ...)

[Eugene]

Here is how I cloned Oracle DB and application servers.

a) OS of the same version was installed on the target servers.
b) Application processes were stopped on source servers. Then source servers were 'tar'ed. A lot of directories were excluded from tarball such as boot, dev, proc... and a number of individual files. To find out objects to be excluded from tarball took some trial and error.
c) Tarballs were untarred on the target servers.

Well, that worked.

By the way, they say that rsync can make differential updates to backup server very well.

[williamconley]

that method would also work here. it may take a tweak or two, but the version of Vicibox should not make any difference. HOWEVER: Kumba states that the newer version (3.1 and above) are now "packaged" so that zypper up will actually update packages ... which could then also be done on the target box to match. Even failing that, the "identical" .iso should not be required, you may just have to "dupe" less data, once you find that Vicidial is OS independent. In fact, you could model your rsync/dd after the data captured in the "backup.pl" script in /usr/share/astguiclient and just add a few spool directories which are normally ignored (and perhaps the entire web root, for instance). but none of that is "os dependent" per se.

my record, by the way, to "dupe" a dying vicidial (client said it had "smoke comin' out of it") stands at 45 minutes (mysqldump, compress, transfer, decompress, match vicidial version with SVN, truncate prior database, load transferred database into now empty asterisk database, update ip address, reboot and it was ON). the mysqldump compress transfer was only about 5-10 minutes, after which he shut the server down to get rid of the smoke