syback

Automating Hot Backups: The sybback.sh Script

There is a free script, that can automate the process of doing hot backups of Sybase -- sybback.sh. It is written in the Bourne shell, which is compatible with most Unix systems. By using GNU's config.guess script, the list of Unix platforms that it runs on is perhaps limitless. By setting various configuration options in a config file, sybback.conf, a wide range of hot backups can be accomplished. Sybback.sh supports these features:

Backs up to disk or tape
Backs up databases on filesystems or raw partitions
Mail-based success and error notification

The syback.sh script was written by R. Neill Carter of Collective Technologies. Neill specializes in large database projects, prefers working with interesting and slightly freaky people, and goes by the name Bongo. He can be reached at cartern@colltech.com.

How syback.sh works

Starting off, syback.sh sets up all the variables and paths it needs to run the backup. It uses config.guess to find out which flavor of Unix it is running on, and then sets what is appropriate for that system. After this, it then opens up its configuration file syback.conf. It locates this file in the directory where it was first started.

Syback.sh reads each line of its configuration file, loading them into its memory. There are three different entry classes it can read - backup class entry, disk device entry, or tape device entry. The backup class entry defines what to backup, where to back it up to, when to back it up, who to back it up as, and certain required Sybase environmental variables. The tape and disk entries define which backup server to use and what device or directory to use on that server.

Once all the entries are read in, syback.sh sequentially runs through each entry, and depending on the current time and the times specified in the backup class entry, it tries to run a backup. When it finds an entry that meets the time criteria, it outputs the entry. Next, it checks the entry and makes sure all the items in it are valid. The last of these checks uses the username and password entered to connect to the dataserver to be backed up. If any checks fail, a failure email is sent to the ADMIN entry defined in syback.conf.

When the entry passes all checks, syback.sh creates a T-SQL dump command to back up of the databases selected to the appropriate backup server and devices.

Installing syback.sh

Put the files syback.sh, syback.conf, config.guess, localpath.sh and rempath.sh into the same directory, then check the following value in the user-defined variables section at the top of the script. Change it to fit your environment:
CONFIG_FILE

Set this to the full pathname of the syback.conf configuration file.

Configuring and Customizing oraback.sh

Edit syback.conf in your favorite text file editor. You will need to edit this file and add backup class entries and tape/disk device entries in order to configure your backup. The syback.conf file contains three type of entries, along with comments. The comment lines begin with the ‘#’ character. First, change the following parameters to the appropriate value for your environment:

BINDIR: Set this to the directory where you installed syback.sh.
ADMIN: Set this to the user id that will run syback.sh.
SUCCESSMAIL: Set this to “yes” if you want to receive mail when syback.sh runs successfully.
FAILMAIL: Set this to “yes” if you want to receive mail when syback.sh fails.

You now need to edit the backup class, tape class, and disk class definitions.

The backup class lines define what type of backup should be run and when, along with any parameters required to run the backup. Here is the definition of a backup class line along with an explanation of each parameter. Review the comments in the syback.conf file to see examples of this entry.

-c MM:HH:DOM:MN:DOW:SERVER_NAME:DUMP_TYPE:USER:PASSWORD:SYBASE:INTERFACES:LOG:DATABASE(S)_TO_INCLUDE:DATABASE(S)_TO_EXCLUDE:DEVICE_TYPE:
DUMP_DEVICE(S):UNLOAD:RETAINDAYS:INIT

The MM, HH, DOM, MN, and DOW parameters are not yet used in this version of syback.sh specify when this particular dump should run. The appropriate value for each paramenter is listed below.

MM: Minute (0-59)
HH: Hour (0-23)
DOM: Day(s) of Month (1-31)
MN: Month (1-12)
DOW: Day of Week (0-6 with 0=Sunday)

SERVER_NAME: Sybase server name
DUMP_TYPE: Type of backup – Full (FULL) or Transaction (TRAN).
USER: Sybase User with backup ability
PASSWORD: Sybase User Password
SYBASE: Full path of Sybase product directory
INTERFACES: Full path of Sybase interfaces file
LOG: Log File for Backup
DATABASE(S)_TO_INCLUDE: List of databases to include in backup. If left blank, all databases except those in DATABASE_TO_EXCLUDE list will be backed up.
DATABASE(S)_TO_EXCLUDE: List of databases to exclude from backup.
DEVICE_TYPE: If TAPE, the DUMP_DEVICE entries are of tape device class defined in a ‘-t’ line. If DISK, the DUMP_DEVICE entries are of disk device class defined in a ‘-d’ line.
DUMP_DEVICE(S): The list of disk or tape devices to backup to. These must be defined in a ‘-t’ or a ‘-d’ line in configuration file.
UNLOAD: Causes tape(s) to be unloaded after backup. This has no affect on a disk device.
RETAINDAYS: Specifies number of days backups are protected from overwriting.
INIT: Causes tape(s) to be initialized and overwritten.

Now that you have defined what type of backups should be performed, the tape class definition line defines the output tape device where the backup can be placed. It contains fields that relate to the backup server that contains the tape device and parameters that define more about the tape device’s abilities. Again, review syback.conf for sample entries.
-t LOGICAL_NAME:SQL_SERVER:BACKUP_SERVER:DUMP_DEVICE:BLOCKSIZE:CAPACITY

LOGICAL_NAME: Logical name assigned to this tape.
SQL_SERVER: Sybase server associated with the named backup server. If not specified, value is taken from environmental variable DSQUERY.
BACKUP_SERVER: Sybase backup server associated with this tape. If not specified, backup_server is assumed to be associated with sqlserver taken from environmental variable DSQUERY.
DUMP_DEVICE: Physical name for this tape.
BLOCKSIZE: Overrides the default block size for a device.
CAPACITY: Maximum amount of data that the device can write to a single volume.

The final type of entry in the syback.conf file is the disk class. These entries define disk files on backup servers. Examples of this entry can also be found in syback.conf file.
-d LOGICAL_NAME:SQL_SERVER:BACKUP_SERVER:DIRECTORY_NAME

LOGICAL_NAME: Logical name assigned to this file.
SQL_SERVER: Sybase server associated with the named backup server. If not specified, value is taken from $DSQUERY.
BACKUP_SERVER: Sybase backup server associated with this tape. If not specified, backup_server is assumed to be associated with sqlserver taken from $DSQUERY.
DIRECTORY_NAME: Directory that will hold backup files.

Finally, with syback.conf file edited with the proper definitions, syback.sh is ready to run its first backup. To invoke syback.sh, run it from a shell prompt. It requires no command line options, and just needs to be invoked while the default directory is set to location of the syback.conf file.

Syback.sh will generate various messages as it runs. What you first will see is information about all the parameters that are set using the backup, tape and disk classes. Next, the output of each backup as it occurs will be displayed. Finally, when all the backups have been processed, if they backup was successful and a success email was selected in the backup class entry, then a success email containing the backup log will be sent administrator email address. If the backup was unsuccessful and failure email was selected, then a failure email containing the backup log will be sent to the administrator email address.

Crontab entries

Syback.sh works slightly different than oraback.sh; syback.sh does not schedule itself to run. Instead, the user must either invoke syback.sh interactively, or set it up to run non-interactively with cron.

Syback.sh tries to match the current time to a time entry in syback.conf. It then does the backup that is defined for that time.

Here is an example of an entry using crontab:

0 2 * * * /opt/syback/syback.sh 2>&1 > /var/adm/syback/syback.last

This entry says run syback.sh at 2:00am every day and put all output into the file syback.last. Refer to your operating systems manuals to find out how to schedule the automatic running of syback.sh.