5.7. Restoring RT

The worst has happened. Your RT database server went up in a big ball of flames about 20 minutes ago. And your users are already clamoring for you to replace the server and let them get on with their work.

To get RT up and running after a crash, restore your RT application from your regular system backups. If that's not an option, start with a brand new, fresh installation of the RT version you were running. Make sure RT's configuration file has the same values it had before your crash. It's particularly important that you get the $rtname and $Organization variables right, or RT won't work properly.

5.7.1. Restoring RT Data

Once you have RT installed, it's time to restore your existing RT database. This is essentially the reverse of the dump process you go through when making backups.

5.7.1.1. MySQL

To restore a mysql-based RT instance, you just need to use the mysql command to feed your rt3 database back in from your backups using this command:

     mysql -u rt_user -prt_pass -h rt_hostname rt3 < rt3-mysql-backup 

5.7.1.2. Postgres

You can restore a Postgres RT instance from a backup you made with the procedure we outlined earlier using this command:

     pg_restore --create < rt3-postgres-backup 

All the data postgres needs about the database name, tables, and columns is embedded in the backup file.

5.7.1.3. SQLite

Since SQLite stores its database in a single file, restoration means copying the backup file to where RT expects to find it. What could be simpler?

5.7.1.4. Oracle

Ask your DBA to switch RT over to the hot spare database they configured when setting up your Oracle instance in the first place or to restore from the most recent nightly backup.

5.7.2. Recover a Lost Administrative Password

RT's default administrative user is called root, after the Unix super-user of the same name. When you installed RT, this user started off with the default password password. If you followed our instructions, you changed this password immediately. For one reason or another, you might no longer know root's password. Either you changed it to something you couldn't possibly forget or, more likely, someone else set up your RT instance and is hiking in the Himalayas or otherwise uncontactable. No problem. Just log in as another user who has either the SuperUser right or the AdminUsers right and change root's password. If you don't happen to have one of those around, you can write a simple Perl one-liner to change a user's password. In the example below, we're going to change root's password to secret. You'll need to run this script as root or as another user who can read RT's private configuration file.

     perl -I/opt/rt3/lib -MRT -e'         RT::LoadConfig(  ); RT::Init(  );         my $u = RT::User->new($RT::SystemUser);         $u->Load("root");         print $u->SetPassword("secret");         ' 

When you run the script, you should see the response "The new value has been set." Then you should be all set to log in as root.

5.7.3. Recover SuperUser Privileges

If you ever find yourself in the unfortunate situation of having removed your only administrator's SuperUser rights, don't panic.

The following one-liner uses the RT API and the internal module RT::SystemUser to grant the root user the SuperUser right safely. As with the last tip, you'll need to run this as a local user who can access the RT config file.

     perl -I/opt/rt3/lib -MRT -e'         RT::LoadConfig(  ); RT::Init(  );         my $u = RT::User->new($RT::SystemUser);         $u->Load("root");         print $u->PrincipalObj->GrantRight(             Object => $RT::System,             Right  => "SuperUser"         );         ' 

If you've really clobbered your administrative user or don't even know who your RT administrative user is, don't despair. This tip will turn any RT user into a superuser in seconds. Just replace root in this example with any other valid username.