Master to 4.2.8
[usit-rt.git] / 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 --single-transaction; \
35       mysqldump rt4 --ignore-table rt4.sessions --single-transaction ) \
36         | gzip > rt-`date +%Y%m%d`.sql.gz
37
38 The dump will be much faster if you can connect to the MySQL server over
39 localhost.  This will use a local socket instead of the network.
40
41 If you find your backups taking far far too long to complete (this point should
42 take quite a long time to get to on an RT database), there are some alternate
43 solutions.  Percona maintains a highly regarded hot-backup tool for MySQL
44 called L<XtraBackup|http://www.percona.com/software/percona-xtrabackup/>.  If
45 you have more resources, you can also setup replication to a slave using binary
46 logs and backup from there as necessary.  This not only duplicates the data,
47 but lets you take backups without putting load on your production server.
48
49 =head3 PostgreSQL
50
51     ( pg_dump rt4 --table=sessions --schema-only; \
52       pg_dump rt4 --exclude-table=sessions ) \
53         | gzip > rt-`date +%Y%m%d`.sql.gz
54
55 =head2 FILESYSTEM
56
57 You will want to back up, at the very least, the following directories and files:
58
59 =over 4
60
61 =item /opt/rt4
62
63 RT's source code, configuration, GPG data, and plugins.  Your install location
64 may be different, of course.
65
66 You can omit F<var/mason_data> and F<var/session_data> if you'd like since
67 those are temporary caches.  Don't omit all of F<var/> however as it may
68 contain important GPG data.
69
70 =item Webserver configuration
71
72 Often F</etc/httpd> or F</etc/apache2>.  This will depend on your OS, web
73 server, and internal configuration standards.
74
75 =item /etc/aliases
76
77 Your incoming mail aliases mapping addresses to queues.
78
79 =item Mail server configuration
80
81 If you're running an MTA like Postfix, Exim, SendMail, or qmail, you'll want to
82 backup their configuration files to minimize restore time.  "Lightweight" mail
83 handling programs like fetchmail, msmtp, and ssmtp will also have configuration
84 files, although usually not as many nor as complex.  You'll still want to back
85 them up.
86
87 The location of these files is highly dependent on what software you're using.
88
89 =item Crontab containing RT's cronjobs
90
91 This may be F</etc/crontab>, F</etc/cron.d/rt>, a user-specific crontab file
92 (C<crontab -l $USER>), or some other file altogether.  Even if you only have
93 the default cronjobs in place, it's one less piece to forget during a restore.
94 If you have custom L<< C<rt-crontool> >> invocations, you don't want to have to
95 recreate those.
96
97 =back
98
99 Simply saving a tarball should be sufficient, with something like:
100
101     tar czvpf rt-backup-`date +%Y%m%d`.tar.gz /opt/rt4 /etc/aliases /etc/httpd ...
102
103 Be sure to include all the directories and files you enumerated above!
104