The Process (OTRS 4.0.8 on Fedora 21 Server with PostgreSQL)
- On the original system (from which you are migrating), execute the OTRS backup utility (as described here) and make the resulting tar.gz archive available to the target system (to which you are migrating).
- On the target system, install OTRS as usual, including stepping through the browser-guided portion. Choose the settings as you intend for them to be established.
$ sudo mkdir /opt/otrs $ sudo yum install http://ftp.otrs.org/pub/otrs/RPMS/fedora/4/otrs-4.0.8-02.noarch.rpm postgresql postgresql-server postgresql-contrib $ sudo firewall-cmd --permanent --add-service http $ sudo systemctl enable httpd && sudo systemctl start httpd $ sudo chkconfig otrs on $ sudo service otrs start #Now visit the install.pl site and walk through it
- Stop the services on the target system
$ sudo systemctl stop httpd.service $ sudo service otrs stop
- Drop the new database and replace it with a blank one
$ su postgres $ psql # drop database otrs; # create database otrs; # \q
- Execute the restore.pl script from your backup. If this works, you’re done. I, however, received only the following output:
“Restore /2015-05-13_10-31/Config.tar.gz …”
And that was it. The script ended, and the system was not restored. So, I dissected the script and manually walked through its operations:
$ cd /opt/otrs $ sudo tar -xzf ~/2015-05-13_10-31/Config.tar.gz $ sudo tar -xzf ~/2015-05-31_10-31/Application.tar.gz $ gunzip ~/2015-05-31_10-31/DatabaseBackup.sql.gz $ cat DatabaseBackup.sql | psql -U otrs otrs
And everything went well. The only warnings I received were:
WARNING: no privileges could be revoked for "public" REVOKE WARNING: no privileges could be revoked for "public" REVOKE WARNING: no privileges were granted for "public" GRANT WARNING: no privileges were granted for "public" GRANT
Which doesn’t strike me as too worrisome, given that the privileges likely don’t need modification anyway.
- Start the services back up
$ sudo systemctl start httpd.service $ sudo service otrs start Starting OTRS.. Checking httpd ... done. Checking database connection... Trying to connect to database DSN : DBI:Pg:dbname=otrs;host=127.0.0.1 DatabaseUser: otrs Connection successful! done. Enable /opt/otrs/bin/otrs.PostMaster.pl ... done. Checking otrs spool dir... done. Creating cronjobs (source /opt/otrs/var/cron/*) ... done.
- Log into the site and enjoy your success!
I found myself in need of migrating an OTRS installation to a new, permanent home (I am basically taking it from a development system to a production system since I don’t feel like rebuilding the data). OTRS comes with some very convenient backup.pl and restore.pl perl scripts (in /opt/otrs/scripts, by default) and so I figured the task would be quite simple. I’m moving between systems with almost the same OS (Fedora 21 Workstation to Fedora 21 Server), so I didn’t anticipate any peculiarities.
Before we begin, it’s important to note that I use PostgreSQL (because it’s awesome) as the back-end for OTRS, and that comes into play later. The same principles should be in effect in MySQL or whatever, but some translation may be needed.
The concise overview of the scripts’ operation is here. To back up my current instance, I simply executed the backup.pl script as directed, noted the correct contents delivered to the tar.gz archive.
Now, I need to restore it to a fresh new system. I figure all I need to do is install the software and then execute the restore operation, so on Fedora 21 Server, I perform the installation as given in the procedure above. Once that’s done, I tried to perform the restoration by simply executing
$ sudo /opt/otrs/scripts/restore.pl -b /backup/2015-05-13_10-31/ -d /opt/otrs ERROR: Already existing tables in this database. A empty database is required for restore!
But sadly, as you can see, I was met with failure. I Googled the problem and came up with a boatload of stuff. While there were complex scripts written to delete tables belonging to a single database and there were recommendations to delete and recreate the entire public schema, the simplest solution to this problem seemed to be to simply stop the current OTRS instance (the fresh one I just installed), drop the otrs database in PostgreSQL, and then perform the restoration. However, once I attempted that, the restore.pl script would generate only the following output:
$ sudo /opt/otrs/scripts/restore.pl -b /backup/2015-05-13_10-31/ -d /opt/otrs Restore /2015-05-13_10-31/Config.tar.gz ... $
And that was it. A quick examination of the system showed that it was obviously not restored. This led me to open up the restore.pl script which is thankfully brief and legibly written. The basic rundown of operations boils down to very few, actually (below, I ignore the logic that was not applicable to my installation):
- Move into /opt/otrs, execute tar -xzf $backupLocation/Config.tar.gz
- From /opt/otrs, execute tar -xzf $backupLocation/Application.tar.gz
- gunzip $backupLocation/DatabaseBackup.sql.gz
- cat $backupLocation/DatabaseBackup.sql | psql -U postgres otrs
And that’s basically it. Neat! Thanks be to the OTRS developers who didn’t make this any more complicated than necessary. Clearly, the script is somehow getting hung up on step 1 for me, so I figured I’d just walk through the steps manually in the process described at step 5 above.
After starting the httpd and otrs services back up, I was able to log into my system and see that it is exactly as I expect! Awesome.
So, that all condenses to the process given at the start of the post for migrating OTRS from one system to another. Hopefully that helps someone who finds herself in the same situation!