5.6. Backing Up RT

RT doesn't store anything important about your users, groups, tickets, or queues directly on your filesystem. All the data you need to worry about on a day-to-day basis lives inside the database you've set up for RT.

5.5.5. Backing Up RT's Data

If you're already backing up your MySQL, PostgreSQL, or Oracle server, you can skip down to Backing up the RT Application below.

If you're still with us, that probably means you're one of the silent majority of users who doesn't yet backup your data, because you haven't yet suffered catastropic data-loss. Backing up RT is quick and easy. All you need to do is take a snapshot of your database and spool it out to disk as a series of SQL statements that you can run later if you need to recreate your database.

MySQL

MySQL's mysqldump command is a very convenient way to backup any MySQL database. It exports the contents of the database as a series of CREATE TABLE and INSERT statements, which then can be replayed to recreate a database. This method is slower than a disk-based byte-by-byte copy, but you are guaranteed to have a usable dump that can be used to recreate your database with minimal effort.

     mysqldump --opt --add-drop-table --single-transaction \     -u rt_user -prt_pass -h databasehost rt3 > rt3-mysql-backup 

rt_user, rt_pass, and rt_hostname should match the user, password, and hostname in your RT_Config.pm or RT_SiteConfig.pm.

PostgreSQL

pg_dump lets you dump out a live postgres database, including all schema and content. All of the previous comments about MySQL apply here, too.

     pg_dump --clean --blobs --format=C -U rt_user rt3 > rt3-postgres-backup 

Oracle

If you're running Oracle, it probably means you have a DBA. Take your DBA out to lunch, and discuss backing up your RT database. It's a business expense and a great way to ensure his cooperation if you ever need your RT database restored at 2 a.m.

SQLite

SQLite uses a single file as its entire database. To be sure your database is consistent, stop your RT daemon, copy the database file to your backup media, and start RT again. This should be automated with cron, and done regularly. SQLite's one file makes backups convenient. For example, you can use a source control system such as Subversion or CVS (in binary mode) to manage the file.

5.5.6. Backing Up the RT Application

The RT application itself is stored on disk. Certain cache files get written out at runtime, but they're not important to keep in the event of a catastrophe. If you've just installed RT from the source distribution and haven't customized any of the source files or web templates, you can get by without backing up the RT application. Just make sure you hang onto a copy of the original source files and reinstall RT when you need to. If you've made any changes to RT's configuration files, libraries, or web templates, you should keep backups of your RT installation. There isn't any danger to backing up RT while it's accepting tickets.

The most important file to back up is RT_SiteConfig.pm, since this the only file you are guaranteed to have changed. You can restore an RT instance using only RT_SiteConfig.pm and a database dump if needed.

When you back up the RT application and libraries, be sure that you have a backup of your webserver, database server, Perl installation, and other similar things on which RT depends. If you plan on making extensive changes to your RT instance, you should consider storing RT's libraries and document root in a local source control repository. CVS's vendor import facility was designed specifically to handle this situation (indeed, CVS originated as a way to track local modifications to vendor distributed source code), and other source control systems have analogous functionality.

Make Sure Your Backups Work!

We strongly recommend that you practice restoring your RT instance every couple of months, to make sure that your backups are working correctly and that you've got all the pieces and parts you need to get RT up and running normally after a catastrophe.

Even if you can't practice a restore very often, make sure you've done it at least once so that it's not a learning experience when you've got users breathing down your neck.