|< Day Day Up >|
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.
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.
|< Day Day Up >|