[Rt-commit] rt branch, 4.0/backup-docs, created. rt-4.0.7-58-ge8e95b6
trs at bestpractical.com
Tue Sep 11 21:45:47 EDT 2012
The branch, 4.0/backup-docs has been created
at e8e95b66d148c4fdbb89944cb2ab2b24f361d45b (commit)
- Log -----------------------------------------------------------------
Author: Thomas Sibley <trs at bestpractical.com>
Date: Tue Sep 11 16:40:16 2012 -0700
Backup documentation covering the database and filesystem
MySQL and Pg specific notes, at the moment. None for Oracle. SQLite is
diff --git a/docs/backups.pod b/docs/backups.pod
new file mode 100644
@@ -0,0 +1,103 @@
+RT is often a critical piece of businesses and organizations. Backups are
+absolutely necessary to ensure you can recover quickly from an incident.
+Make sure you take backups. Make sure they I<work>.
+There are many issues that can cause broken backups, such as a
+max_attachment_size too low for MySQL (in either the client or server), or
+encoding issues, or running out of disk space.
+Make sure your backup cronjobs notify someone if they fail instead of failing
+silently until you need them.
+Test your backups regularly to discover any unknown problems B<before> they
+become an issue. You don't want to discover problems with your backups while
+tensely restoring from them in a critical data loss situation.
+You should backup the entire RT database, although for improved speed and space
+you can ignore the I<data> in the C<sessions> table. Make sure you still get
+the C<sessions> schema, however.
+Database specific notes and example backup commands for each database are
+below. Adjust the commands as necessary for connection details such as
+database name (C<rt4> is the placeholder below), user, password, host, etc.
+You should put the example commands into a shell script for backup and setup a
+cronjob. Make sure output from cron goes to someone who reads mail! (Or into
+ mysqldump rt4 --tables sessions --no-data > rt-`date +%Y%M%d`-sessions.sql
+ mysqldump rt4 --ignore-table rt4.sessions \
+ --single-transaction | gzip > rt-`date +%Y%M%d`.sql.gz
+It will be much faster if you can connect to the MySQL server over localhost.
+This will use a local socket instead of the network.
+If you find your backups taking far far too long to complete (this point should
+take quite a long time to get to on an RT database), there are some alternate
+solutions. Percona maintains a highly regarded hot-backup tool for MySQL
+called L<XtraBackup|http://www.percona.com/software/percona-xtrabackup/>. If
+you have more resources, you can also setup replication to a slave using binary
+logs and backup from there as necessary. This not only duplicates the data,
+but lets you take backups without putting load on your production server.
+ pg_dump rt4 --table=sessions --schema-only > rt-`date +%Y%M%d`-sessions.sql
+ pg_dump rt4 --exclude-table=sessions | gzip > rt-`date +%Y%M%d`.sql.gz
+You will want to back up, at the very least, the following directories and files:
+RT's source code, configuration, GPG data, and plugins. Your install location
+may be different, of course.
+You can omit F<var/mason_data> and F<var/session_data> if you'd like since
+those are temporary caches. Don't omit all of F<var/> however as it may
+contain important GPG data.
+=item Webserver configuration
+Often F</etc/httpd> or F</etc/apache2>. This will depend on your OS, web
+server, and internal configuration standards.
+Your incoming mail aliases mapping addresses to queues.
+=item Mail server configuration
+If you're running an MTA like Postfix, Exim, SendMail, or qmail, you'll want to
+backup their configuration files to minimize restore time. "Lightweight" mail
+handling programs like fetchmail, msmtp, and ssmtp will also have configuration
+files, although usually not as many nor as complex. You'll still want to back
+The location of these files is highly dependent on what software you're using.
+=item Crontab containing RT's cronjobs
+This may be F</etc/crontab>, F</etc/cron.d/rt>, a user-specific crontab file
+(C<crontab -l $USER>), or some other file altogether. Even if you only have
+the default cronjobs in place, it's one less piece to forget during a restore.
+If you have custom L<< C<rt-crontool> >> invocations, you don't want to have to
+Simply saving a tarball should be sufficient, with something like:
+ tar czvpf rt-backup-`date +%Y%M%d`.tar.gz /opt/rt4 /etc/aliases /etc/httpd ...
+Be sure to include all the directories and files you enumerated above!
More information about the Rt-commit