Difference between revisions of "Freeside:DeprecatedDocumentation:DisasterRecovery"

From Freeside
Jump to: navigation, search
m (Broke out pre-requisites into a list and rephrased the introduction.)
 
(10 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Preparation =
+
= DEPRECATED / OUT-OF-DATE =
 +
 
 +
Ancient documentation not germane to current installations/databases.
 +
 
 +
= Introduction =
  
 
You can restore a Freeside installation if you have backed up:
 
You can restore a Freeside installation if you have backed up:
  
 
* the configuration files
 
* the configuration files
 +
* any customized /etc/sysconfig/freeside (RPM specific - if used)
 
* authentication files
 
* authentication files
 +
* the database secret files
 
* and the database (including any encryption keys).
 
* and the database (including any encryption keys).
  
 
freeside-daily will produce a database dump if you have set up the configuration to enable the dump.  The configuration and authentication files will change rarely.  They can be scp'd or rsync'd to a backup server, or imported into CVS.
 
freeside-daily will produce a database dump if you have set up the configuration to enable the dump.  The configuration and authentication files will change rarely.  They can be scp'd or rsync'd to a backup server, or imported into CVS.
  
This assumes all the versions of software are the same on the old and new machines.  If you upgrade anything, you may have to make some alterations to the database schema or the dump file.  You're better off installing the same version as on the failed machine and then doing an upgrade after the restoral.  You will want to keep the tarballs or RPMs you installed from around so you can reinstall Freeside.
+
Restoration is easier all the versions of software are the same on the failed and replacement machines.  If you upgrade anything, you may have to make some alterations to the database schema or the dump file.  You're better off installing the same version of Freeside and the back-end database as on the failed machine and then doing an upgrade after the restoration.  You will want to keep the tarballs or RPMs you installed from available so you can reinstall Freeside. If you want to ensure you're installing the same versions of the required Perl modules as on the failed machine, you want to save all the RPMs or back up /usr/lib/perl5.  (Running regular CPAN auto-bundles may help.)
  
 
= How to restore a Freeside installation =
 
= How to restore a Freeside installation =
  
== PostgreSQL ==
+
== Preparation ==  
  
 
* Install the Freeside RPMs or install from the tarball, etc.  (You don't do the whole "new install" procedure as you want to restore a database dump instead of creating a new, empty database.)
 
* Install the Freeside RPMs or install from the tarball, etc.  (You don't do the whole "new install" procedure as you want to restore a database dump instead of creating a new, empty database.)
  
 
* Restore the configuration files.  They were in /usr/local/etc/freeside/conf* or /etc/freeside/conf*
 
* Restore the configuration files.  They were in /usr/local/etc/freeside/conf* or /etc/freeside/conf*
 +
 +
* Restore the /etc/sysconfig/freeside file if your failed system used one.  (This is currently only used on RPM installs.)
 +
 +
* Restore the database secret files.  Make sure these are owned by the freeside user
 +
 +
* Optionally, restore the authentication files (or do this later).
 +
 +
== Database restoration ==
 +
 +
=== PostgreSQL ===
  
 
* Create the freeside database user:
 
* Create the freeside database user:
Line 33: Line 49:
 
* Assuming your database dump is in /usr/local/etc/freeside/freeside.sql, load that into the database using:
 
* Assuming your database dump is in /usr/local/etc/freeside/freeside.sql, load that into the database using:
 
<pre>
 
<pre>
su postgres -c 'psql freeside < 'usr/local/etc/freeside/freeside.sql'
+
su postgres -c 'psql freeside < /usr/local/etc/freeside/freeside.sql'
 
</pre>
 
</pre>
 
(Note: you must perform this as the postgres user as the dump contains commands only the database superuser can perform.)  
 
(Note: you must perform this as the postgres user as the dump contains commands only the database superuser can perform.)  
 
(Note: if you're restoring an outsource database instead of the main freeside database, replace the database name, freeside in the example above, with the outsource database name.)
 
(Note: if you're restoring an outsource database instead of the main freeside database, replace the database name, freeside in the example above, with the outsource database name.)
  
* Restore any authentication database you use if not using basic HTTP authentication.  (Files for this are usually located under /usr/local/etc/freeside.)
+
=== MySQL ===
 
 
* Run dbdef-create
 
<pre>
 
su freeside -c '/path/to/dbdef-create freeside-user'
 
</pre>
 
 
 
* Restart httpd and the freeside services.
 
 
 
* Go into the new installation and spot check to make sure that the contents agree with the old installation.  (Missing required switches when creating the database can result in an incomplete database restoral.)
 
 
 
== MySQL ==
 
  
 
TBD.  Something along these lines:
 
TBD.  Something along these lines:
  
* Install the Freeside files and restore the configuration files as for the PostgreSQL instructions above.
+
* Set the MySQL root password if not already set:
* Set the MySQL root password:
 
 
<pre>
 
<pre>
 
mysqladmin -u root password 'set_a_root_database_password'
 
mysqladmin -u root password 'set_a_root_database_password'
Line 71: Line 75:
 
mysql -u root -p < /usr/local/etc/freeside/freeside.sql
 
mysql -u root -p < /usr/local/etc/freeside/freeside.sql
 
</pre>
 
</pre>
* Restore the authentication files and run dbdef-create
+
 
 +
== Wrap-up & Testing ==
 +
 
 +
* Restore any authentication database you use if you did not do so earlier.  (Files for this are usually located under /usr/local/etc/freeside or /etc/freeside.)
 +
 
 +
* Run dbdef-create
 
<pre>
 
<pre>
/path/to/dbdef-create freeside-user
+
su freeside -c '/path/to/dbdef-create freeside-user'
 
</pre>
 
</pre>
* Complete the procedure as for the PostgreSQL instructions above.
+
 
 +
* Restart httpd and the freeside services.
 +
 
 +
* Go into the new installation and spot check to make sure that the contents agree with the old installation.  (Missing required switches when creating the database can result in an incomplete database restoral.)
 +
 
 +
* Try making a minor modification to the database.  For example, run freeside-daily on a single, low-risk customer.  If that customer's number is 104, try:
 +
<pre>
 +
/usr/bin/freeside-daily -v fs_daily 104
 +
</pre>
 +
 
 +
* Set up SSH keys, firewall settings, MySQL/PostgreSQL grants on databases, etc., necessary to make your exports work.
  
 
= Disaster Planning =
 
= Disaster Planning =
  
Doing a practice restoral before going live with Freeside, and doing periodic practice restorals should be part of your disaster plan.
+
You should perform a practice restoral before going live with Freeside.
 +
 
 +
Doing periodic practice restorals should be part of your disaster plan as this reveals problems with restoration before it's needed.
  
 
= See Also =
 
= See Also =
  
 
PostgreSQL users can [[Freeside:1.7:Documentation:Administration:Slony|use slony to maintain a live backup server]].
 
PostgreSQL users can [[Freeside:1.7:Documentation:Administration:Slony|use slony to maintain a live backup server]].

Latest revision as of 15:12, 7 January 2018

DEPRECATED / OUT-OF-DATE

Ancient documentation not germane to current installations/databases.

Introduction

You can restore a Freeside installation if you have backed up:

  • the configuration files
  • any customized /etc/sysconfig/freeside (RPM specific - if used)
  • authentication files
  • the database secret files
  • and the database (including any encryption keys).

freeside-daily will produce a database dump if you have set up the configuration to enable the dump. The configuration and authentication files will change rarely. They can be scp'd or rsync'd to a backup server, or imported into CVS.

Restoration is easier all the versions of software are the same on the failed and replacement machines. If you upgrade anything, you may have to make some alterations to the database schema or the dump file. You're better off installing the same version of Freeside and the back-end database as on the failed machine and then doing an upgrade after the restoration. You will want to keep the tarballs or RPMs you installed from available so you can reinstall Freeside. If you want to ensure you're installing the same versions of the required Perl modules as on the failed machine, you want to save all the RPMs or back up /usr/lib/perl5. (Running regular CPAN auto-bundles may help.)

How to restore a Freeside installation

Preparation

  • Install the Freeside RPMs or install from the tarball, etc. (You don't do the whole "new install" procedure as you want to restore a database dump instead of creating a new, empty database.)
  • Restore the configuration files. They were in /usr/local/etc/freeside/conf* or /etc/freeside/conf*
  • Restore the /etc/sysconfig/freeside file if your failed system used one. (This is currently only used on RPM installs.)
  • Restore the database secret files. Make sure these are owned by the freeside user
  • Optionally, restore the authentication files (or do this later).

Database restoration

PostgreSQL

  • Create the freeside database user:
	su postgres -c 'createuser -P -A -d freeside'
  • Create an empty freeside database:
	su freeside -c 'createdb -E sql_ascii freeside'
  • If you've been encrypting your database dumps, unencrypt the dump.
  • Assuming your database dump is in /usr/local/etc/freeside/freeside.sql, load that into the database using:
	su postgres -c 'psql freeside < /usr/local/etc/freeside/freeside.sql'

(Note: you must perform this as the postgres user as the dump contains commands only the database superuser can perform.) (Note: if you're restoring an outsource database instead of the main freeside database, replace the database name, freeside in the example above, with the outsource database name.)

MySQL

TBD. Something along these lines:

  • Set the MySQL root password if not already set:
mysqladmin -u root password 'set_a_root_database_password'
  • Create the freeside database user:
$ mysql -u root -p
mysql> GRANT SELECT,INSERT,UPDATE,DELETE,INDEX,ALTER,CREATE,DROP on freeside.* TO freeside@localhost IDENTIFIED BY 'set_a_freeside_database_password';
  • Create the freeside database:
mysqladmin -u freeside -p create freeside
  • Restore the database dump after unencrypting it:
mysql -u root -p < /usr/local/etc/freeside/freeside.sql

Wrap-up & Testing

  • Restore any authentication database you use if you did not do so earlier. (Files for this are usually located under /usr/local/etc/freeside or /etc/freeside.)
  • Run dbdef-create
su freeside -c '/path/to/dbdef-create freeside-user'
  • Restart httpd and the freeside services.
  • Go into the new installation and spot check to make sure that the contents agree with the old installation. (Missing required switches when creating the database can result in an incomplete database restoral.)
  • Try making a minor modification to the database. For example, run freeside-daily on a single, low-risk customer. If that customer's number is 104, try:
/usr/bin/freeside-daily -v fs_daily 104
  • Set up SSH keys, firewall settings, MySQL/PostgreSQL grants on databases, etc., necessary to make your exports work.

Disaster Planning

You should perform a practice restoral before going live with Freeside.

Doing periodic practice restorals should be part of your disaster plan as this reveals problems with restoration before it's needed.

See Also

PostgreSQL users can use slony to maintain a live backup server.