[Rt-commit] rt branch, 4.2/restoring-from-backups, created. rt-4.2.8-6-g89b734a

Alex Vandiver alexmv at bestpractical.com
Wed Oct 22 12:05:53 EDT 2014


The branch, 4.2/restoring-from-backups has been created
        at  89b734a09ef15694c4312d2a105b813d5b9143be (commit)

- Log -----------------------------------------------------------------
commit 89b734a09ef15694c4312d2a105b813d5b9143be
Author: Kevin Falcone <falcone at bestpractical.com>
Date:   Wed Oct 15 13:15:18 2014 -0400

    Document restoring from backups.
    
    MySQL does DROP IF EXISTS $table; CREATE TABLE $table; which makes this
    straightforward (you need a database and a user).  In fact, you could do
    make initdb and restore from your backup and be fine, but I erred on
    doing the least needed.
    
    Our postgres backups don't clean, and if they did, they would get weird
    errors because we run two backups (sessions and the rest) and clean
    wants to drop the public namespace and you get errors about sessions
    existing.  So, we don't switch to clean.  Similar problems exist with
    telling pg_dump to ignore rights/acls since an admin would need to rerun
    acl.Pg for any extension that provides one (say assets).
    
    Instead, come up with a way to work with the existing backups which just
    CREATE TABLE; COPY and GRANT. This means you need a database and a user
    but *cannot* have tables. etc/acl.Pg assumes tables exist and will
    create a user and then fail to GRANT rights noisily. Rather than scare
    the admin by telling them to run rt-setup-database --action create,acl
    and ignore the errors, we'll create and then use createuser to set up
    the user.  This calls out that RT needs a separate step for "create
    user".  We should also allow rt-setup-database --action drop,create but,
    that's another branch.
    
    The instructions here should be sufficient to restore from the the
    backups we've been documenting.

diff --git a/docs/backups.pod b/docs/backups.pod
index efcfc81..16ba5b0 100644
--- a/docs/backups.pod
+++ b/docs/backups.pod
@@ -46,12 +46,99 @@ 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
+
+=back
+
 =head2 FILESYSTEM
 
 You will want to back up, at the very least, the following directories and files:

-----------------------------------------------------------------------


More information about the rt-commit mailing list