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
|
=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.
This documentation has been modified by the Debian maintainers to be more
specific to file locations in Debian. It removes the upstream recommendation
to back up the distributed code, as this should be reinstalled via the
Debian packaging system. However, this means it is important not to
modify files in /usr/share directly (a good general rule) as those changes
will be lost in the event of having to restore.
=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.
=head3 PostgreSQL
( pg_dump rt4 --table=sessions --schema-only; \
pg_dump rt4 --exclude-table=sessions ) \
| gzip > rt-`date +%Y%m%d`.sql.gz
=head2 PACKAGE LISTS
This will help you decide which packages to reinstall.
dpkg --get-selections > rt-get-selections-`date +%Y%M%d`
=head2 FILESYSTEM
You will want to back up, at the very least, the following directories and files:
=over 4
=item /var/lib/request-tracker4
Miscellaneous data, including GPG data, if it exists.
=item /etc/request-tracker4
RT configuration files.
=item /usr/local/share/request-tracker4
Local code customisations and plugins.
=item Webserver configuration
If you're using Apache, as per the Debian default, this is in
F</etc/apache2>.
=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
As installed by Debian, this is F</etc/cron.d/request-tracker4> but
you may have used additional files.
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 /var/cache/request-tracker4/data /etc/aliases /etc/httpd ...
Be sure to include all the directories and files you enumerated above!
|
