RMAN 10G NFS Mount Options

We backup our Oracle databases using RMAN and then write the backup pieces out to an NFS share. This has always worked well, but RMAN started complaining that the NFS share was not mounted with the correct options when we upgraded to Oracle 10G. After some poking around in the docs I finally came up with a set of mount options that work.

Vfstab entry on a Solaria 8 box:
nfsserver.domain.com:/path/to/remote/mountpoint /local-mountpoint nfs 0 yes rw,bg,intr,hard,timeo=600,wsize=32768,rsize=32768
Manual mount on a Solaris 8 box:
mount -o rw,bg,intr,hard,timeo=600,wsize=32768,rsize=32768 nfsserver.domain.com:/path/to/remote/mountpoint /local-mountpoint

According to the docs, the options on a Linux box are pretty much the same, except you would add the following:
nfsver=3,tcp

Setting Up The Automounter Service on RHEL

Mounting filesystems in RHEL is pretty straightforward and easy. Occasionally, however, you will not want the filesystem to remain mounted all the time, but rather to automatically mount for a set period of time only when it is needed. Because of networking overhead, and the general unreliability of networks, NFS mounts are a good example of when this can be especially useful.

In order to manage the automatic mounting and unmounting of filesystems on RHEL, we use the Automounter service. Here is how.

First, The main configuration file is “/etc/auto.master”. It should look something like this:

#
# $Id: auto.master,v 1.3 2003/09/29 08:22:35 raven Exp $
#
# Sample auto.master file
# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# For details of the format look at autofs(5).
#/misc  /etc/auto.misc --timeout=60
#/misc  /etc/auto.misc
#/net   /etc/auto.net


Let’s assume that we want to set up an NFS mount on “/misc/backups”. We would first create an entry in this file that looks something like this:

/misc   /etc/auto.misc --timeout=120


This tells the autofs service that we want to use it to manage mounts from within “/misc”, that the configuration file is “/etc/auto.misc”, and that it should disconnect after 2 minuets of inactivity.

Now, let’s edit the “/etc/auto.misc” file. The file has three columns: the mount point from within the /misc directory, the options for mounting the filesystem, and the filesystem to be mounted. It also includes the remote server’s name since we are using NFS. It should look something like this when you are done:

#
# $Id: auto.misc,v 1.2 2003/09/29 08:22:35 raven Exp $
#
# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# Details may be found in the autofs(5) manpage

cd              -fstype=iso9660,ro,nosuid,nodev :/dev/cdrom
backups         -rw,soft,intr remoteservername:/path/to/nfs/export

# the following entries are samples to pique your imagination
#linux          -ro,soft,intr           ftp.example.org:/pub/linux
#boot           -fstype=ext2            :/dev/hda1
#floppy         -fstype=auto            :/dev/fd0
#floppy         -fstype=ext2            :/dev/fd0
#e2floppy       -fstype=ext2            :/dev/fd0
#jaz            -fstype=ext2            :/dev/sdc1
#removable      -fstype=ext2            :/dev/hdd


Next, we create the directory for the mount point in /misc:

# mkdir /misc/backups

And finally we restart the autofs service:

# service autofs restart

That should pretty much do it. If you don’t have autofs configured to start up, you can use chkconfig to enable it. “/misc/backups” will now be mounted whenever a user or process attempts to access data on it, and it will be automatically disconnected after 120 seconds of inactivity. Last, but not least, you can always confirm that it is running with the “service” command:

# service autofs status

As always, change the details to match your own requirements.

WordPress Backup Script

I wrote this little script the other day to back up my WordPress install. Because I use Navicat, I had always been pretty good about backing up the database, but I didn’t backup the install base nearly as often as I should have. I’m sure it won’t be useful for everyone because it requires access to the command line, and mysqldump, but it’s nice to know that my blog is getting backed up.

It’s really just a simple shell script that is executed nightly by cron. You can set up the backup directories in any way you like, but if you store your database backups in a subdirectory of the WordPress install, make darn sure that the directory is not readable by the web server.

The example below assumes the following:

  • WordPress (your web root) is: /webserver/wordpress
  • Your dumps directory is: /home/backups/wp-backups
  • The name of your WordPress database is wpdata
  • Your WordPress database user is: dbuser
  • Your WordPress database password is: dbpassword

Remember to change these variables for your install.

———-SNIP———-
#!/bin/sh
Date=`date “+%Y-%m-%d”`;
echo “Creating Database Backup”;
mysqldump -u dbuser -pdbpassword wpdata | gzip > /home/backups/wp-backups/wordpress-$Date.sql.gz;
echo “Done”;
echo “Creating Filesystem Backup”;
cd /webserver/;
/usr/bin/tar -czf /home/backups/wp-backups/wordpress-$Date.tgz wordpress;
Echo “Done”;
echo “Backup Complete”;
———-/SNIP———-

Each time the script is run, it will create two timestamped files in /home/backups/wp-backups. The first one: wordpress-TIMESTAMP.sql.gz is a compressed export of your database. The second file: wordpress-TIMESTAMP.tgz is a compressed tar archive of your WordPress install.