OTRS Restore Procedure and backup script

As I note in my previous post, I managed to kill my OTRS install and as usual had to trawl around the net to remember how to restore it. In a nutshell:

# mysql -u root -p
msyql> drop database otrs;
mysql> create database otrs;
mysql> ext
# /opt/otrs/scripts/restore.pl -d path_to_backup /opt/otrs

You did back up right?

Nightly I run a script with the following in it:

otrs_backup.sh


#!/bin/bash
# Variables below - change these to suit
NOW=$(date +"%Y-%m-%d_%H-%M") # this gets the correct file name for OTRS backup
LOCAL=/root/backup # a local directory for OTRS to backup to
REMOTE="user@backupserver:~/backup/OTRS/" # remote backup dir - nfs share, ftp or cifs
/opt/otrs/scripts/backup.pl -d $LOCAL # OTRS internal backup (files and DB)
tar -cf $LOCAL/$NOW.tar $LOCAL/$NOW # creates a file from the OTRS backup folder - more efficient to copy over a network
gzip $LOCAL/$NOW.tar
rm -rf $LOCAL/$NOW # tidy up
scp -r $LOCAL/$NOW.tar.gz $REMOTE # scp to remote directory

You may wish to run this from crontab after copying otrs_backup.sh to /usr/local/bin:

0 20 * * * /usr/local/bin/otrs_backup.sh

This will run at 10pm each night - theoretically you could run it more frequently. OTRS databases will a lot of attachments get quite large though so be mindful of that (I have a couple I manage that are 1GB and are only 5 months old)

Enjoy

Restoring OTRS on an Ubuntu Server

Some time ago I relocated our OTRS server from a failing server to a virtual machine under Microsoft Hyper-V. While the change to a virtual machine ran smoothly and I used the details in a previous post to set it up, after a month I noticed some strange errors creeping in to the installation - the nightly log emails had inconsistencies in them. Fortunately I was able to run a full backup of the OTRS installation using the built in backup tool and very shortly thereafter the server fell in a heap. Rebooting it caused a complete failure of the virtual disk. Now, how the hell something like that happens is beyond me. It was like the virtual disk dropped a head or something.... Ridiculous I know, but the fsck I ran basically told me the disk had failed and corruptions crept in to everything on the disk. Realising that I was fighting a bad fight, I decided to create a new virtual machine and transfer the data back across.

The recovery procedure, described here: http://doc.otrs.org/3.0/en/html/restore.html doesn't really cover everything that needs to happen. Here is a short breakdown of the notes that I made while I was running the recovery process:

• make sure you set the MySQL (or whatever database you use) password to be the same.
• in fact, make sure you match up all the passwords where possible.
• Install OTRS first using the Ubuntu install method - which is well described here: http://wiki.otrs.org/index.php?title=Installation_on_Ubuntu_Lucid_Lynx_(10.4) 
• make sure you run all the right commands, including the cron ones (which I initially forgot - oops!)
• Run the restore as per the link above and then restart apache and cron.
• Test your installation and see how it goes.

Since this error, I've written a very simple script that runs the backup and scp's it across to another server I have. This in turn is backed up to my FreeNAS box, hopefully protecting my useful data. Here is the script:

---------------------------------------------------------------------------------------------------

#!/bin/bash

NOW=$(date +"%Y-%m-%d_%H-%M")

/opt/otrs/scripts/backup.pl -d /home/user/backup

scp -r /home/user/backup/$NOW user@server:/home/user/backup/OTRS/

---------------------------------------------------------------------------------------------------

The $NOW variable is configured to match the output of the OTRS backup.pl script and then I simply scp it across to my server. It's date organised and works pretty nicely. rsync might be a nicer way to do it, but this virtual machine only provides OTRS and nothing else so I'll keep it simple. 

If you can use any of this then please do.

AB out.