=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...

=over 4

=item * a C<max_allowed_packet> too low for MySQL or MariaDB in either the client or server

=item * encoding issues

=item * running out of disk space

=back

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<rt5> 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 and MariaDB

    ( mysqldump --default-character-set=utf8mb4 rt5 --tables sessions --no-data --single-transaction; \
      mysqldump --default-character-set=utf8mb4 rt5 --ignore-table rt5.sessions --single-transaction ) \
        | gzip > rt-`date +%Y%m%d`.sql.gz

If the default character set for the entire database is not set to
utf8mb4, it is especially important to set the character set in the
mysqldump command to avoid corrupted backups. As always, it's important
to test your backups to confirm they restore successfully.

The dump will be much faster if you can connect to the MySQL or
MariaDB 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 and MariaDB 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:

    rt-setup-database-5 --action create,acl

By default, this will create an rt5 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 rt5

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 and MariaDB.

    gunzip -c rt-20141014.sql.gz | mysql -uroot -p rt5

MySQL and MariaDB 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 rt5 database or rt_user user.

=back

=head3 PostgreSQL

    ( pg_dump rt5 --table=sessions --schema-only; \
      pg_dump rt5 --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:

    rt-setup-database-5 --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 rt5

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:

    rt-setup-database-5 --action drop
    rt-setup-database-5 --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 rt5

=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 PACKAGE LISTS

This will help you decide which packages to reinstall.

    dpkg --get-selections > rt-get-selections-`date +%Y%M%d`

=head2 FILESYSTEM

Although this section is mostly about database backups, there are other
files on the filesystem you should back up to capture the state of your RT.
You will want to back up, at the very least, the following directories and files:

=over 4

=item /var/lib/request-tracker5

Miscellaneous data, including GPG data, if it exists.

You can omit F</var/lib/request-tracker5/mason_data> and
F</var/lib/request-tracker5/session_data> if you'd like since
those are temporary caches.  Don't omit all of F</var/lib/request-tracker5/>
however as it may contain important GPG data.

=item /etc/request-tracker5

RT configuration files.

=item /usr/local/share/request-tracker5

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-tracker5> 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.

=item External storage

If you use L<RT::ExternalStorage>, you will want to backup
the attachments in your chosen storage engine.

If you're using L<RT::ExternalStorage::Disk>, then you need only back
up the files under the C<Path> option under C<%ExternalStorage> in your
RT_SiteConfig.pm.

If you're using a cloud storage engine like
L<RT::ExternalStorage::AmazonS3>, consult that service's documentation
regarding backups.

=back

Simply saving a tarball should be sufficient, with something like:

    tar czvpf rt-backup-`date +%Y%M%d`.tar.gz /var/lib/request-tracker5 /etc/aliases /etc/httpd ...

Be sure to include all the directories and files you enumerated above!

=head1 Migrating to a Different Database

RT supports many different databases, including MySQL, MariaDB, PostgreSQL,
and Oracle. Each of these databases is different and if you want to switch
from one type to another, you can't just take a backup in one and try to
restore it to another. One exception is MySQL and MariaDB, which are currently
compatible and don't require the extra steps discussed here.

RT provides tools that allow you to export your RT database
to the filesystem and then import it back into another database through
RT. The tools are L<rt-serializer> and L<rt-importer> and the general
process for migrating from one database to another is described below.

Plan to do a full test of this process and thoroughly check the data
in a test version of the new database before performing a final conversion
on your production system.

The serializer and importer tools can also be used to move only part of
your RT database, like an individual queue. The process is similar to the
steps described here, but the options will be different.

You do not need to perform these steps when upgrading RT on the same database.
See the L<README> for upgrade instructions.

=over

=item Export from Current Database

First run the L<rt-serializer> tool to export your database to the filesystem.
Note that this will require space similar to the size of your database, so
plan accordingly. If your database is very large, it can take some time.
The documentation contains additional information on available flags.
It's also a good idea to run the L<rt-validator> tool to detect and resolve
any errors in your database before starting:

    rt-validator-5 --check (and maybe --resolve)
    rt-serializer-5 --clone --directory /path/to/serialized/data

=item Setup New Database

After the database serializes cleanly, you can then begin to set up your
new database. As you are working from some existing data, you do
not need the initial RT data inserted into the databases, but you will need
the tables created. When you use the L<rt-importer> tool, the data will fill
the corresponding tables.

RT's L<rt-setup-database> tool can set the database up for you.
If you are running the import in the same RT installation, you will need to
update your database options in C<RT_SiteConfig.pm> to point to the new database
before running this step.

    rt-setup-database-5 --action create,schema,acl

=item Import Data

Once you have your new database set up, you can then use L<rt-importer>
to insert the serialized data:

    rt-importer-5 /path/to/serialized/data

As with the serializer step, this will take time proportionate to the size of
your database.

=item Reset Sequences

Some databases, like Postgres, use sequences for RT table values like ids. For
these database types, you need to reset the sequences from 1, set in the newly
created database, to the next available id for each table. The C<reset-sequences>
script will reset these for you:

    /usr/share/request-tracker5/etc/upgrade/reset-sequences

=item Test

Test your new system and confirm all of the expected data is available. Your RT
system should look exactly the same as before, but the backend is on an entirely
new database.

=back