X-Git-Url: http://git.freeside.biz/gitweb/?p=freeside.git;a=blobdiff_plain;f=rt%2Fdocs%2Fbackups.pod;fp=rt%2Fdocs%2Fbackups.pod;h=554336fb9f6448d157bb4f83a6d1af6d5381aec0;hp=648105c66588c82254df7615c78716b82e1e8521;hb=1c538bfabc2cd31f27067505f0c3d1a46cba6ef0;hpb=4f5619288413a185e9933088d9dd8c5afbc55dfa diff --git a/rt/docs/backups.pod b/rt/docs/backups.pod index 648105c66..554336fb9 100644 --- a/rt/docs/backups.pod +++ b/rt/docs/backups.pod @@ -31,13 +31,9 @@ RT. :) =head3 MySQL - ( mysqldump rt4 --tables sessions --no-data; \ + ( mysqldump rt4 --tables sessions --no-data --single-transaction; \ mysqldump rt4 --ignore-table rt4.sessions --single-transaction ) \ - | gzip > rt-`date +%Y%M%d`.sql.gz - -If you're using a MySQL version older than 4.1.2 (only supported on RT 3.8.x -and older), you should be also pass the C<--default-character-set=binary> -option to the second C command. + | 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. @@ -50,11 +46,105 @@ 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 + | 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 +after your restore is complete. If you'd like to watch the progress, you +can run C. + +=back =head2 FILESYSTEM @@ -102,7 +192,7 @@ recreate those. 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 ... + 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!