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