rt/docs/backups.pod

   1 =head1 BACKUPS
   2
   3 RT is often a critical piece of businesses and organizations.  Backups are
   4 absolutely necessary to ensure you can recover quickly from an incident.
   5
   6 Make sure you take backups.  Make sure they I<work>.
   7
   8 There are many issues that can cause broken backups, such as a
   9 C<max_allowed_packet> too low for MySQL (in either the client or server), or
  10 encoding issues, or running out of disk space.
  11
  12 Make sure your backup cronjobs notify someone if they fail instead of failing
  13 silently until you need them.
  14
  15 Test your backups regularly to discover any unknown problems B<before> they
  16 become an issue.  You don't want to discover problems with your backups while
  17 tensely restoring from them in a critical data loss situation.
  18
  19 =head2 DATABASE
  20
  21 You should backup the entire RT database, although for improved speed and space
  22 you can ignore the I<data> in the C<sessions> table.  Make sure you still get
  23 the C<sessions> schema, however.
  24
  25 Database specific notes and example backup commands for each database are
  26 below.  Adjust the commands as necessary for connection details such as
  27 database name (C<rt4> is the placeholder below), user, password, host, etc.
  28 You should put the example commands into a shell script for backup and setup a
  29 cronjob.  Make sure output from cron goes to someone who reads mail!  (Or into
  30 RT. :)
  31
  32 =head3 MySQL
  33
  34     ( mysqldump rt4 --tables sessions --no-data; \
  35       mysqldump rt4 --ignore-table rt4.sessions --single-transaction ) \
  36         | gzip > rt-`date +%Y%M%d`.sql.gz
  37
  38 If you're using a MySQL version older than 4.1.2 (only supported on RT 3.8.x
  39 and older), you should be also pass the C<--default-character-set=binary>
  40 option to the second C<mysqldump> command.
  41
  42 The dump will be much faster if you can connect to the MySQL server over
  43 localhost.  This will use a local socket instead of the network.
  44
  45 If you find your backups taking far far too long to complete (this point should
  46 take quite a long time to get to on an RT database), there are some alternate
  47 solutions.  Percona maintains a highly regarded hot-backup tool for MySQL
  48 called L<XtraBackup|http://www.percona.com/software/percona-xtrabackup/>.  If
  49 you have more resources, you can also setup replication to a slave using binary
  50 logs and backup from there as necessary.  This not only duplicates the data,
  51 but lets you take backups without putting load on your production server.
  52
  53 =head3 PostgreSQL
  54
  55     ( pg_dump rt4 --table=sessions --schema-only; \
  56       pg_dump rt4 --exclude-table=sessions ) \
  57         | gzip > rt-`date +%Y%M%d`.sql.gz
  58
  59 =head2 FILESYSTEM
  60
  61 You will want to back up, at the very least, the following directories and files:
  62
  63 =over 4
  64
  65 =item /opt/rt4
  66
  67 RT's source code, configuration, GPG data, and plugins.  Your install location
  68 may be different, of course.
  69
  70 You can omit F<var/mason_data> and F<var/session_data> if you'd like since
  71 those are temporary caches.  Don't omit all of F<var/> however as it may
  72 contain important GPG data.
  73
  74 =item Webserver configuration
  75
  76 Often F</etc/httpd> or F</etc/apache2>.  This will depend on your OS, web
  77 server, and internal configuration standards.
  78
  79 =item /etc/aliases
  80
  81 Your incoming mail aliases mapping addresses to queues.
  82
  83 =item Mail server configuration
  84
  85 If you're running an MTA like Postfix, Exim, SendMail, or qmail, you'll want to
  86 backup their configuration files to minimize restore time.  "Lightweight" mail
  87 handling programs like fetchmail, msmtp, and ssmtp will also have configuration
  88 files, although usually not as many nor as complex.  You'll still want to back
  89 them up.
  90
  91 The location of these files is highly dependent on what software you're using.
  92
  93 =item Crontab containing RT's cronjobs
  94
  95 This may be F</etc/crontab>, F</etc/cron.d/rt>, a user-specific crontab file
  96 (C<crontab -l $USER>), or some other file altogether.  Even if you only have
  97 the default cronjobs in place, it's one less piece to forget during a restore.
  98 If you have custom L<< C<rt-crontool> >> invocations, you don't want to have to
  99 recreate those.
 100
 101 =back
 102
 103 Simply saving a tarball should be sufficient, with something like:
 104
 105     tar czvpf rt-backup-`date +%Y%M%d`.tar.gz /opt/rt4 /etc/aliases /etc/httpd ...
 106
 107 Be sure to include all the directories and files you enumerated above!
 108