1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
|
=head1 BACKUPS
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
C<max_allowed_packet> 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.
=head2 DATABASE
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
RT. :)
=head3 MySQL
( mysqldump rt4 --tables sessions --no-data --single-transaction; \
mysqldump rt4 --ignore-table rt4.sessions --single-transaction ) \
| gzip > rt-`date +%Y%m%d`.sql.gz
The dump 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.
=head4 Restoring from backups
=over
=item New Database Server (Catastrophic Failure)
If you are starting fresh with a new database server (because your old
one no longer works or because you want to set up a dev machine to
test on) you will need to create a fresh database and database user
for RT to use. RT can do that for you using:
/opt/rt4/sbin/rt-setup-database --action create,acl
By default, this will create an rt4 database and an rt_user user. If
you've specified a custom password in RT_SiteConfig.pm, RT will use
that. Once the database and user exist, you can restore from your
backup using:
gunzip -c rt-20141014.sql.gz | mysql -uroot -p rt4
Changing -uroot -p as needed to access the database as a user with
enough rights to handle creating tables.
=item Restore over an existing database
If something terrible happened this morning and you want to roll back to
your backups, or if you want to update a dev server using your backups,
this is straightforward on MySQL.
gunzip -c rt-20141014.sql.gz | mysql -uroot -p rt4
MySQL will drop any existing tables before recreating and repopulating
them. It will leave the database and the rt_user untouched. This is
not suitable for restoring on a fresh database install since there will
be no rt4 database or rt_user user.
=back
=head3 PostgreSQL
( pg_dump rt4 --table=sessions --schema-only; \
pg_dump rt4 --exclude-table=sessions ) \
| gzip > rt-`date +%Y%m%d`.sql.gz
=head4 Restoring from backups
=over
=item New Database Server (Catastrophic Failure)
If you are starting fresh with a new database server (because your old
one no longer works or because you want to set up a dev machine to
test on) you will need to create a fresh database and database user
for RT to use. RT can do part of that for you using:
/opt/rt4/sbin/rt-setup-database --action create
You will need to create the rt_user separately.
createuser -P rt_user
This will prompt you for a password. You should ensure that it is the
same password you have configured in RT_SiteConfig.pm or RT_Config.pm
using C<$DatabasePassword>.
Once the database and user exist, you can restore from your backup which
will create tables, insert data and configure rights for your rt_user
user.
gunzip -c rt-20141014.sql.gz | psql rt4
This may need to be run as the postgres user or some other admin level
user who can create tables.
=item Restore over an existing database
If something terrible happened this morning and you want to roll back to
your backups, or if you want to update a dev server using your backups,
you will need to drop your database and recreate a fresh one to restore
into. RT can drop and recreate the database for you using:
/opt/rt4/sbin/rt-setup-database --action drop
/opt/rt4/sbin/rt-setup-database --action create
Remember that this will completely destroy the existing data and create
a fresh database. Your rt_user user will remain untouched. Once this
is complete, you can restore from your backup which will create tables
and insert data and configure rights for the rt_user.
gunzip -c rt-20141014.sql.gz | psql rt4
=item After Restoring
Postgres will generally perform poorly after restoring from backups
because it has outdated index statistics. You should run C<analyze>
after your restore is complete. If you'd like to watch the progress, you
can run C<analyze verbose>.
=back
=head2 FILESYSTEM
You will want to back up, at the very least, the following directories and files:
=over 4
=item /opt/rt4
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.
=item /etc/aliases
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
them up.
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
recreate those.
=back
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!
|
