Revision as of 11:58, 9 January 2008

Introduction

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

• the configuration files
• any customized /etc/sysconfig/freeside (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.