| Prev | Chapter�8.�Maintenance | Next |
|---|
+
This section describes how to make a one-time backup of the files and database. This is useful for rolling back to known-good versions of a service, such as at initial - installation and just before a backup.
PostGreSQL.�Create a backup file and verify that it was created and has a reasonable size (several megabytes).
[root@localhost root]# su - service0 + installation and just before an upgrade.
PostGreSQL.�Create a backup file and verify that it was created and has a reasonable size (several megabytes).
[root@localhost root]# su - service0 [service0@localhost service0]$ pg_dump -f /web/service0/database-backup/before_upgrade_to_4.6.dmp service0 [service0@localhost service0]$ ls -al /web/service0/database-backup/before_upgrade_to_4.6.dmp -rw-rw-r-x 1 service0 service0 4005995 Feb 21 18:28 /web/service0/database-backup/before_upgrade_to_4.6.dmp @@ -54,7 +54,7 @@ exitFile tree with CVS.�If you are already using CVS, you probably don't need to do anything to back up your data. Just make sure that your current work is checked into the system. - You can then roll back based on date - just note the + You can then roll back based on date - note the current system time, down to the minute. For maximum safety, you can apply a tag to your current files. Note that, if you did the CVS options in this document, the /web/service0/etc directory is not included in cvs and you may want to add it.
[root@localhost root]# su - service0 @@ -112,9 +112,7 @@ psql -f /web/service0/packages/acs-kernel/sql/postgresql/postgresql.sql service0 psql service0 < /web/service0/database-backup/before_upgrade_to_4.6.dmp svc -u /service/service0 -exit
Backup can encompass all files in /web/service0. For a development server, putting the files in cvs is sufficient. (It's important then to back up the cvs repository!)
A quick way to automate database backup is a cron job. This is not recommended for production and is not part of the Reference Platform, because it is not cross-platform and can fail silently. More thorough methods are documented in the section called “Backup Strategy”
[service0@yourserver service0]$ export EDITOR=emacs;crontab -e
Add this line to the file. The numbers and stars at the beginning are cron columns that specify when the program should be run - in this case, whenever the minute is 0 and the hour is 1, i.e., 1:00 am every day.
0 1 * * * /usr/local/pgsql/bin/pg_dump -f /web/service0/database-backup/service0_$(date +%Y-%m-%d).dmp service0
If you plan to back up the whole /web/service0 directory, then it would be redundant to keep a history of database backups. In that case, set up the cron job to overwrite the previous backup each time:
0 1 * * * /usr/local/pgsql/bin/pg_dump -f /web/service0/database-backup/service0_nightly.dmp service0
A quick way to automate database backup is a cron job. - (This should moved into OpenACS's scheduled task project so that - it's integrated with OpenACS's alerts and such.)
[service0@yourserver service0]$ export EDITOR=emacs;crontab -e
Add this line to the file. The numbers and stars at the beginning are cron columns that specify when the program should be run - in this case, whenever the minute is 0 and the hour is 1, i.e., 1:00 am every day.
0 1 * * * /usr/local/pgsql/bin/pg_dump -f /web/service0/database-backup/service0_$(date +%Y-%m-%d).dmp service0
Here's a quick manual way to back up a reference install - it should be replaced by an automated script within OpenACS. The command excludes the auto-generated supervise directory, which is @@ -133,7 +131,20 @@ recursive backup.
[root@yourserver root]# su - service0 [service0@yourserver service0]$ tar -cpsj --exclude /web/service0/etc/daemontools/supervise --file /tmp/service0-backup.tar.bz2 /web/service0/ tar: Removing leading `/' from member names -[service0@yourserver service0]$
On a test service, make sure that your backup-recovery process work. After backing up the database and file system, delete the service as detailed below and then recover it.
[root@yourserver root]# svc -d /service/service0 +[service0@yourserver service0]$
Backup can encompass all files in + /web/service0. For a development + server, putting the files in cvs, and backing up the database nightly, is sufficient. (It's important then to back up the cvs repository!)
Backing up the database consists of creating a file + which is a picture of the database at a particular moment. + Postgres can be backed up while running. A quick way to automate database backup is a cron job. This + is not recommended for production and is not part of the Reference + Platform, because it is not cross-platform and can fail silently. + A more thorough solution using the cronjob OpenACS package is + planned.
Depending on your overall backup strategy, you can + create a series of database backup files, or you can create a + single nightly backup file which is then collected into a + bigger backup file that includes the other parts of the + service (web pages, content, code). To make a new file every + night, edit the crontab file for service0:
[service0@yourserver service0]$ export EDITOR=emacs;crontab -e
Add this line to the file. The numbers and stars at the beginning are cron columns that specify when the program should be run - in this case, whenever the minute is 0 and the hour is 1, i.e., 1:00 am every day.
0 1 * * * /usr/local/pgsql/bin/pg_dump -f /web/service0/database-backup/service0_$(date +%Y-%m-%d).dmp service0
If you plan to back up the whole /web/service0 directory, then it would be redundant to keep a history of database backups. In that case, set up the cron job to overwrite the previous backup each time:
0 1 * * * /usr/local/pgsql/bin/pg_dump -f /web/service0/database-backup/service0_nightly.dmp service0
On a test service, make sure that your backup-recovery process work. After backing up the database and file system, delete the service as detailed below and then recover it.
[root@yourserver root]# svc -d /service/service0 [root@yourserver root]# mv /web/service0/ /web/service0.lost [root@yourserver root]# rm /service/service0 rm: remove symbolic link `/service/service0'? y @@ -148,7 +159,7 @@ DROP USER [postgres@yourserver pgsql]$ exit logout -[root@yourserver root]#
Restore the operating system and required software. +[root@yourserver root]#
Restore the operating system and required software. You can do this with standard backup processes or by keeping copies of the install material (OS CDs, OpenACS tarball and supporting software) and repeating the install guide.
Restore the OpenACS service. Assuming the user already exists, restore the database and files from backup and restore the daemontools link. (Because of a bug in Postgres backup-recovery, not all database objects are created in the correct order. To compensate, pre-creating some objects usually work.)
[root@yourserver root]# su - postgres @@ -173,7 +184,7 @@ [root@yourserver root]# ln -s /web/service0/etc/daemontools /service/service0 [root@yourserver root]# sleep 10 [root@yourserver root]# svgroup web /service/service0 -[root@yourserver root]#
Earlier strategies, included here because this section hasn't been fully updated yet.
(This has not yet been updated to fit with the Reference install. To do so, edit the backup script to save the backup @@ -265,8 +276,7 @@ root:~# crontab -l | grep export-oracle 0 23 * * * /usr/sbin/export-oracle root:~# exit -; Logout
If you see the line, go ahead and log out.
This is an alternate method to the crontab backup. Dowload this script to /tmp. At the top of the script are several variables that you'll need to customize: