New SQL-BackTrack Frequently Asked Questions (FAQ) -- text version
Jackie Taylor
also a formatted postscript version of this file.]
SQL-BackTrack for Sybase
Frequently Asked Questions (FAQ)
Send questions or comments to faq_sug...@datatools.com
This is revision 2.0, last modified on 8/29/94
Database administrators who are responsible for planning backup and
recovery strategies need more functionality than just backing up and
recovering entire databases. SQL-BackTrack for Sybase is a product
from DataTools that provides extended Sybase physical dump
capabilities with object-level extraction, as well as logical backup,
incremental backup, compression, encryption, and online media tracking
and history information.
CONTENTS
Introduction
General Questions
Backup
Recovery
Data Migration
Security
Backup Devices
Technical Notes
Contacting DataTools
Introduction
The questions in this publication relate to SQL-BackTrack for Sybase,
a comprehensive backup and recovery product from DataTools. Due to the
nature of the product, the questions come primarily from database
administrators and the answers assume a knowledge of general Sybase
administration issues.
A PostScript-format version of this FAQ is archived at
ftp.datatools.com as /pub/faq/backtrack-faq.ps and is available via
anonymous ftp over the Internet.
Comments, suggestions and questions are all welcome. Direct comments
to faq_sug...@datatools.com, or call DataTools. Our telephone
numbers are listed at the end of this document.
------------------------------------------------------------------------------
General Questions
Why do I need `database-aware' backup -- why not just use
operating system utilities?
Some database administrators use UNIX utilities to back up the raw
disk partitions on which the Sybase server data resides. This
procedure involves shutting down the database and then copying the
database's raw disk partition to tape or a second UNIX disk
partition. Although this may seem to be the simplest and cheapest way
to go, it is in fact costly in terms of backup /recovery time and
storage media.
Some of the major drawbacks to this approach are:
[] You must shut down the SQL Server to perform the backup. This is
not acceptable for mission-critical applications, and it also severely
limits the number and frequency of backups possible.
[] The entire allocated database is backed up, even if only a portion
of the allocation space is being used. This wastes permanent storage
space as well as backup time and network bandwidth.
[] You need to double the allocated disk space of the Sybase database if
you copy the raw partition to a second UNIX disk partition.
[] Backup files are not easy to track or audit.
[] The backed up raw partition data is `opaque.' There is no way
to look inside the potentially huge raw backup partition to see what
you have backed up or recover a single object.
[] Recovery is difficult. If you lose a single table, you will need
to shut down the SQL Server and restore the entire disk partition. You
cannot integrate off-line raw partition dumps with online transaction
log dumps. (There is no way to clear the transaction log after an
off-line dump.)
A database-aware backup utility can record more than the physical
representation of the data on the disk; it also understands the
structure of the database data it is backing up. Because SQL-BackTrack
understands this structure, it can back up only the data that has
changed since the last backup (incremental backups). It can recover an
individual object, even from a full database backup, and it can
recover the database with the same or new segment allocation
information.
Why not just use the Sybase DUMP/LOAD DATABASE facility?
SQL-BackTrack extends the functionality of the Sybase dump/load
database facilities, and provides new `logical' capabilities. It
includes a number of features that save significant time and
resources.
Some of the important features of SQL-BackTrack are as follows:
[] Automated, unattended backups and remote backups
[] Data compression and encryption on backup
[] Incremental backups
[] Improved tape support: backups over 2 GB, multiple backups
per tape, backups can span tapes
[] Object-level recovery
[] Logical backups (data archiving, object-level backups, data
manipulation, etc.)
[] Data migration (moving data between different versions of
Sybase, or hardware/software platforms)
[] Integration with file system backup products (optional OBSI
modules required)
Why would I want to use the SQL-BackTrack `logical' backup capability?
Logical backups provide capabilities previously unavailable to Sybase
DBAs. A logical backup, either of an entire database or just specific
objects within it, records the database's or object's data and logical
structure, not just the physical, block-by-block representation of the
partition.
For example, a logical backup of a table saves not only the table data
but the table's definition, including index definition, dependencies,
triggers, rules, etc. A logical backup of an entire database saves the
full set of information about the database's structure and
interdependencies. This means that you can recover this database to
another server with a different configuration.
Logical backups are particularly useful for data manipulation and
migration tasks, including:
[] Migration of data to another hardware platform, operating system,
or version of Sybase
[] Long-term archival of databases or groups of objects, which can
later be recovered to a computer with a different hardware platform,
operating system, or version of Sybase.
[] Recovery of a database to a smaller size or different
segment/device allocations
What platforms does SQL-BackTrack support?
SQL-BackTrack for Sybase works on Sybase version 4.x or System 10. It
is currently released on the following platforms:
[] Sun SPARC running SunOS 4.1.3
[] Sun SPARC running Solaris 2.2 or higher
[] IBM RS/6000 running AIX 3.2 or higher
[] HP 9000 series 700 or 800 running HP/UX 9.0 or higher
If you have another platform you'd like to see supported, send mail to
sup...@datatools.com.
How can I try out SQL-BackTrack?
To try out SQL-BackTrack yourself, telnet to the DataTools
demonstration server:
telnet demo.datatools.com
The server has the complete functioning product and a SQL Server.
Licensing
If I have Sybase servers on several computers linked with a network
(LAN or WAN), how many SQL-BackTrack licenses must I purchase?
SQL-BackTrack is licensed on a per-machine basis. You must have a
separate SQL-BackTrack license for each machine you want to back up
and restore.
If you have several Sybase servers on a single computer, you can back
up and restore all of them with a single SQL-BackTrack license.
------------------------------------------------------------------------------
Backup
Physical Backups
How is a SQL-BackTrack physical backup different from a DUMP DATABASE?
SQL-BackTrack actually takes the DUMP DATABASE stream as part of its
physical backup, and it adds other information. It adds an
object-level header, so that individual objects can be recovered from
a physical backup. SQL-BackTrack also can perform a number of optional
functions on the data stream, including incremental backups, data
compression and data encryption.
Note: SQL-BackTrack physical backups require that the Sybase dump
device be defined.
Logical Backups
How is SQL-BackTrack's logical backup facility different from bcp?
The Sybase bcp utility is useful for importing or exporting data from
Sybase. When exporting, it writes a flat file containing delimited
data describing the contents of a table. When importing, it copies
data into an existing table.
A SQL-BackTrack logical backup contains much more than just table
data; it records the table structure and the definitions of other
types of objects, such as rules, triggers, stored procedures, views,
logins, and grants. It also records the dependencies between database
objects. Optionally, a logical backup can lock tables (making them
read-only) on backup to maintain referential integrity (RI), ensuring
a consistent view of interdependent data.
A logical backup also records segment allocation information, so that
it recovers with the same segment allocations unless you specifically
request a different allocation.
When you recover a table with SQL-BackTrack, you recover more than
just the table's data - you recover the table's definition, including
dependencies, indexes, etc. For example, to archive all the
information about a table without SQL-BackTrack so that it could be
recovered to the same or a different configuration, you'd need to
extract grants/revokes, bind information, indexes, definitions, data,
and keys.
How do logical backups compare in speed to physical backups?
When you back up an entire database, a physical backup is considerably
faster than a logical backup. This is because logical backups require
additional processing. On average, a full logical backup takes three
to four times as long as a full physical backup.
If you only need to back up a single table of a large database, an
object-level backup of that table only may be significantly faster
than a full physical backup.
If you need to recover an entire database, a physical recovery will be
faster than a logical recovery. If you need to recover a small table
from a large database, an object recovery of just that table will
generally be faster. (However, if you need to recover a very large
table, an object-level recovery may actually be slower than a physical
recovery.)
In general, logical backups are recommended for archival and data
migration purposes, and physical backups for fast disaster
recovery. Many SQL-BackTrack users make weekly logical backups and
regular physical backups.
Can I do an incremental backup of a single table or of the master
database?
No, incremental dumps are only implemented for physical database
backups. You can only perform a full physical backup of the master
database.
File System Backups
How can I integrate database backups with file system backups?
DataTools provides modules that integrate SQL-BackTrack's database
backups with file system backup products. These modules take advantage
of SQL-BackTrack's Open Backup Stream Interface (OBSI) to send backups
to media managed by file system backup products. They also allow the
file system backup scheduling facilities to schedule database
backups. With the SQL-BackTrack file system backup modules, you can
either integrate database backups with filesystem backups (in terms of
both scheduling and backup volumes), or keep them separate but still
use the volume management and backup hardware support provided by the
file system product vendors.
Modules are currently available for the following file system backup
products:
[] Legato NetWorker
[] Epoch System's EpochBackup
[] IBM ADSM (currently in development)
[] AT&T Backup (currently in development)
Can I use SQL-BackTrack with Legato NetWorker?
Yes. The SQL-BackTrack NetWorker Module links SQL-BackTrack's database
backups with Legato NetWorker's backup capabilities.
The main component of the SQL-BackTrack NetWorker Module is an OBSI
program for NetWorker, which sends the database backup stream to
NetWorker. The module also includes NetWorker Application Specific
Modules (ASMs) that use a Legato-defined interface that allows
SQL-BackTrack and NetWorker to communicate.
Database backups can either be invoked by NetWorker (using its save
command, its graphical user interface, or its automatically scheduled
backups) or from SQL-BackTrack (using the dtbackup command, either
interactively or from cron). This means that the responsibility for
performing database backups can either be integrated with or
independent of the file system backups.
Notes:
[] Backup errors appear in the Messages display of the Networker main
window. Action requests go to the Pending display.
[] You can identify tape volumes by noting the file temp/# in the
control file and using BROWSE to locate the file in the index.
[] SQL-BackTrack does not automatically overwrite tapes you want to
re-use. If you want to re-use a tape, you must re-initialize it first
using the dttape utility.
[] If the datatools directory is not /usr/datatools, enter the line
dthome=<directory name> in the dtasm.config file in the networker
directory. (Substitute your datatools directory name for <directory
name>; do not actually type the angle brackets.)
[] If you have more than one Networker server on your network, you can
specify the server SQL-BackTrack uses by entering the following lines
in the SQL-BackTrack backup pool definition:
begin backup_pool=default
obsi=networker
save_options=-s<servername>
recover_options=s<servername>
end backup_pool
Can I use SQL-BackTrack with Epoch's EpochBackup?
Yes. The SQL-BackTrack EpochBackup Module integrates SQL-BackTrack's
database backups with Epoch's enterprise-wide backup facilities. By
installing the EpochBackup module and making a few modifications to
Epoch work groups and configuration files, you can send Sybase
database backups to Epoch-managed media.
You can either initiate database backups from SQL-BackTrack (using the
dtbackup command) or initiate them from EpochBackup using a special
work item defined for that purpose. You can either schedule your
database backups as part of the file system backups or schedule
database backups independently through cron. In either case, the
database backups are written to Epoch-managed media and take advantage
of EpochBackup's volume and robotic library management.
What if my file system backup product is not currently supported by
SQL-BackTrack?
DataTools provides an Application Programming Interface (API) for file
system backup vendors to develop their own integration modules for
SQL-BackTrack. If your file system backup product currently does not
have a SQL-BackTrack integration module, contact your file system
backup vendor or DataTools Sales to find out if it is in development
or if there are plans to support it. If your organization is
interested in developing an integration module, please contact
DataTools for your Open Backup Stream Interface (OBSI) Software
Developer's Kit.
General Backup
Is SQL-BackTrack based on the Sybase transaction log?
No, SQL-BackTrack is not based on the Sybase transaction log. However,
you can back up the transaction log with SQL-BackTrack. The physical
backup process uses the Sybase dump database command to dump
databases. In addition, SQL-BackTrack dumps logical information about
database objects to facilitate object-level recovery from a full
physical dump.
SQL-BackTrack logical backups do not depend on Sybase dump-load
commands.
I want to make a transaction dump only if a full dump completes
successfully. How do I do this?
Enter the commands for performing a full dump and a transaction dump
as follows:
<full dump> && <transaction dump>
The transaction dump is executed if and only if the full dump returns
status 0. This works in both the Bourne and C shells.
Compression
Using SQL-BackTrack compression, how much data can I expect to put on
a standard Exabyte 8mm tape?
Remember that even without compression, SQL-BackTrack only writes the
part of the database that is actually used (plus some general
structure information about the database). A database may be allocated
as one gigabyte, but only contain 700 megabytes of data. The
uncompressed physical backup would then be around 700 megabytes.
When you make a full physical backup using SQL-BackTrack compression,
you can expect the compressed backup to occupy approximately 30-40% of
the space of the uncompressed data. The actual percentage will vary
according to the size of the database.
Should I still use SQL-BackTrack compression if I have a tape drive
with hardware compression (such as the Exabyte 8500c or 8505)?
This depends on whether you are backing up to a local tape drive that
is connected directly to the machine on which the SQL Server is
running, or to a remote tape drive that is connected to another
machine.
You should not use SQL-BackTrack's software compression if you are
backing up to a local tape drive with hardware compression. If you use
the SQL-BackTrack compression in addition to the hardware compression,
the time required to write the backup to tape will not be reduced, and
the CPU time required to process the data will increase.
You should use SQL-BackTrack's compression when you back up to a
remote tape device (whether or not it provides hardware compression),
to reduce the amount of data sent across the network.
Network Backups
Can I back up remote servers?
Yes, SQL-BackTrack uses the Sybase Open Client DB-Library to
communicate with remote servers over the network. One workstation
running SQL-BackTrack can back up multiple remote SQL Servers. (You
must have a separate SQL-BackTrack license for each machine you want
to back up.)
How can I configure SQL-BackTrack to compress data before sending it
to a remote backup device?
The compression takes place on the system where you run dtbackup. To
compress data before sending it across the network, you must run
dtbackup on the same system running the Sybase SQL Server.
Can I configure SQL-BackTrack to back up to a remote workstation that
has a tape drive attached?
Yes, there are two ways to do this. If the remote workstation is a
supported SQL-BackTrack platform, run the dtbackup on that system.
You can also use the rmt support (in version 1.1 or later of
SQL-BackTrack) to back up to a remote tape device. If you choose to do
this, the requirements on the remote workstation are as follows:
[] The remote workstation must run the rmt program. (This is a
standard program on most UNIX systems.)
[] You must have authorization to run programs on the remote system
using rsh.
There are some limitations due to compatibility between rmt
servers. Refer to the SQL-BackTrack for Sybase User's Guide for
details on how to set up remote tape backups.
How can I monitor remote backups?
Use the dtwatch facility to monitor remote backups. Run dtwatch on the
system from which the dtbackup command is being run. This shows a
continuously updating status display.
------------------------------------------------------------------------------
Recovery
How can I recover my database with different segment information?
1. Use SQL-BackTrack to make a logical format backup of the database.
(You may want to make a second copy of the backup for additional
safety.)
2. Drop the database from the server.
3. Create the new database with the desired device and segment
allocation.
4. Load the database using the on_segment options on the dtload (or
dtrecover) command to designate segments on reload. Use the merge
option to merge the data with the newly created database.
For example, if you are using the dtload command:
dtload database pubs from /dev/rst1 on_segment default
on_index_segment fastdisk merge
If you are using the dtrecover command, use the -options parameter to
pass the option string, in quotes, to dtload:
dtrecover /usr/datatools/backups/SYBASE/pubs -merge -options
'on_segment default on_index_segment fastdisk'
The SQL-BackTrack for Sybase User's Guide provides a detailed
description of the -options parameters.
How do I recover a database to a different size (smaller) database?
Use SQL-BackTrack to make a logical backup of the database, create a
new database with the appropriate device and segment allocation, and
merge the data from the backup into the new database. To do this:
1. Make a logical backup of the database. Either use dtcreate to
create a control directory for logical backups and back it up with the
dtbackup command, or use the dtdump utility:
dtdump logical server SYBASE database pubs2
2. Create a new database (e.g. pubs3) of the appropriate size.
3. Load the logical backup into the new database with the -merge
option, which merges the data with the existing database.
[] If you used dtbackup to backup, then use dtrecover to recover:
dtrecover cdir/SYBASE/pubs2 -database pubs3 -merge
[] If you used dtdump, then use dtload to recover:
dtload server SYBASE database pubs3 merge
If you are satisfied with the new database and want to replace the
original (in our example, pubs2) database, then drop the original
database and rename the new one with sp_renamedb.
How do I extract a single table out of a full physical dump?
On the dtrecover command, use the -objects option:
dtrecover cdir/SYBASE/pubs -objects dbo.authors
On the dtload command, use the objects option:
dtload from /tmp/backups/pubs objects dbo.authors
Note: You cannot extract any object with text or image data from a
physical backup. This is because data in such objects is in an ordered
linked list of pages which have to be stored differently from regular
data pages. However, you can extract objects containing text or image
data from a SQL-BackTrack logical backup.
What does a `dry-run' recovery guarantee me? Is it a dbcc?
A SQL-BackTrack dry-run recovery checks the validity of the backup
file to confirm that it is available and readable. This protects you
from discovering a tape error during recovery. For tape recoveries, a
dry-run recovery also provides a list of the tapes needed for the
recovery.
The dry-run recovery is also useful if you want to check the validity
of a particular recovery option. The dry-run recovery does not check
the internal consistency of the data being recovered.
What is the difference between the copyover option and the replace
option?
The copyover and replace options are both valid when recovering the
entire database from a physical backup. The replace option does the
following:
1. If the database already exists, dtload will drop it.
2. Next dtload creates the database, automatically using the same
database devices and segment allocations as the backed up database.
3. Finally, dtload loads the dumped database data.
Use the copyover option if the backed up database uses the same
database devices and segment allocation as the existing one and the
size of the devices is adequate for that database. The copyover option
is faster than replace, as it eliminates dropping and creating the
database.
On a logical recovery of the entire database, the copyover option
drops all objects from the existing database and recovers them from
the backed-up version.
What if I have to recover using a different tape drive than the one I
used to back up?
The name of the tape drive is stored in your control directory. You
can recover from a different tape drive of the same type by adding a
line to the dtrecover command:
dtrecover from <backup pool>:/<new device name>
How do I replace a bad disk on my Sybase server?
1. Obtain two copies of the full physical backup of the databases on
the bad disk.
In many cases, a failing disk produces hardware errors before it
becomes completely unreadable. If the disk is still readable, make two
full physical backups of the databases on that disk using
SQL-BackTrack. If the disk is not readable, make a copy of the last
full physical backup you took of the databases associated with this
disk.
2. Drop the databases associated with the bad disk from the Sybase
server.
3. Remove the bad disk and replace it with a disk of equal or greater
capacity.
4. On the new disk, create database partitions of the same size as the
original ones.
5. Use the Sybase disk init command to initialize the new disk with
the same dev name.
6. Use dtrecover to recover the databases from one of the full
physical backups you made in step 1.
------------------------------------------------------------------------------
Data Migration
How do I copy a database to a different server?
If the second server is the same hardware/software configuration as
the first server and runs the same version of SQL Server, you can do a
SQL-BackTrack physical recovery to the second server. If you used
dtbackup to back up the server, use the dtrecover -server option:
dtrecover /usr/datatools/backups/SYBASE/pubs -server TESTSERVER
Or, to copy the database from one server to another using dtdump and
dtload:
dtdump server SYBASE database pubs to /tmp/pubs
dtload server TESTSERVER from /tmp/pubs
If the second server is a different platform than the first, do a
logical backup and recovery. Either create a control directory for
logical backups and use dtbackup, or use the dtdump/dtload commands:
dtdump logical server SYBASE database pubs to /tmp/pubs
dtload server TESTSERVER from /tmp/pubs
I'm upgrading to a newer version of Sybase or a different
platform. How do I move my data?
Use SQL-BackTrack to make a logical backup of your databases. If you
are moving multiple or large databases, we suggest that you create a
control directory for logical backups. (This lets you use the tape
support provided by SQL-BackTrack.) Once you have created the control
directory, back up the databases with the dtbackup command.
On the new server, load the databases with the dtrecover command,
using the -server option to direct the recovery to the new server. The
new server must be licensed for SQL-BackTrack.
dtrecover logcdir/SYBASE -server NEWSYBASE
How do I move a database back to a previous version of Sybase?
The same procedure described above should work. Any objects that
contain data types not available in the earlier Sybase version cannot
be recovered. However, you can recover all objects that only contain
supported data types.
Note: To determine the Sybase version running on a particular server,
select @@version through ISQL.
Can I recover to a different platform (for example, Sun to IBM)? What
are the licensing issues?
SQL-BackTrack is licensed per machine. If you plan to use both
machines, you will need to buy an additional license for the new one.
SQL-BackTrack must be installed and licensed on the new platform
before you can begin.
If you plan to move your data from one platform to another, you should
take a logical format backup from the old platform and recover it to
the new platform:
dtdump logical server SYBASE database pubs to /tmp/pubs
dtload server NEWSERVER from /tmp/pubs
The logical format backup ensures that any machine incompatibilities
(such as byte ordering) do not interfere with the data.
------------------------------------------------------------------------------
Security
How can I have automated, unattended backups without compromising
security?
When dtbackup runs, it gets the user-id and password to connect to the
SQL Server from the control file (if it is set up for unattended
backups). The password is encrypted in the control file.
The first key to securing the data is to restrict access to the
control file to those accounts that require it. (If you are running
dtbackup from cron, make sure that cron is running under an account
with access.) The second key is to control access to the backup files
themselves (whether on tape or disk).
For physical backups, the backup file alone is not of any use unless
someone can recover it. By default, the control files do not include
the password for recovering the data. This means that when it is time
to recover, someone must provide the password for the account. You can
also specify a different account for recovery so, for example, only
the sa account can recover.
If you have highly sensitive data and are concerned about it being
recovered without authorization, you can encrypt your data. You
provide an encryption key without which the data cannot be recovered.
Because encryption does require additional processing time, you should
only encrypt sensitive databases.
What do I do if I change Sybase SQL Server passwords?
If you change the password for the user-ids used for unattended
backups, you need to update the control directory. To do this, run the
dtcheck command with the name of the control directory. It will prompt
you for the new password and put the new password (in encrypted
format) in the control files.
------------------------------------------------------------------------------
Backup Devices
What backup devices are supported?
SQL-BackTrack alone can back up directly to disk, optical disk, or
tape. The following tape devices are supported:
[] 8 mm Exabyte tape (8200, 8500, 8500c)
[] 4 mm DAT tape
[] 1/2 inch 9-track tape
Note that fixed block only tapes such as quarter-inch (`QIC')
tapes are not supported.
If you are using any of the SQL-BackTrack file system backup
integration modules (such as the SQL-BackTrack Legato Networker or
EpochBackup module), SQL-BackTrack supports any media managed by the
file system backup software. Note that when you use the file system
product's backup device support, you also use their utilities for
examining/labeling tapes, providing tape status, etc.
Will SQL-BackTrack read any ANSI-labeled tapes?
Yes, it will read or write to any ANSI labeled tapes. On backup,
dtbackup will write to any tape that is already labeled and contains
no other data. On recovery, dtrecover reads the tape label and
informs you if the tape is not the correct one.
How can I determine which tapes I would need if I wanted to recover a
database or object?
When you perform a recovery using dtrecover, it automatically prompts
you for the appropriate tapes:
dtrecover /usr/datatools/SYBASE/pubs
To check which tapes are required without actually recovering the
data, insert a tape in the drive and add the -dryrun option to
dtrecover:
dtrecover /usr/datatools/SYBASE/pubs -dryrun
This will provide a list of the tapes required for the recovery
without actually reloading the data.
Note: You must have a tape inserted in the drive for the -dryrun
option to work. (This tape does not have to be one of the tapes
required for the recovery.)
How can I tell what is on a given tape?
Use the dttape utility with the dir (for directory) option and the
name of the raw tape device. For example:
dttape dir /dev/nrst0
This displays the list of files on the tape.
The verbose option on that command displays information about the
creation time and size of each file:
dttape dir /dev/nrst0 -verbose
What is the OBSI interface?
The Open Backup Stream Interface (OBSI) is the interface through which
SQL-BackTrack controls input/output to backup devices. In the
stand-alone product, OBSI programs are provided for disk and
tape. Optional OBSI modules are also available for integrating your
database backups with your file system backup management.
------------------------------------------------------------------------------
Technical Notes
Installation
When SQL-BackTrack is installed, why must it generate a new
`dataserver' module?
The SQL-BackTrack driver routines must be linked to dataserver so that
the dump-load stream can be re-directed to the dump-load device
/@@/dev/dl/port_number. This is required for physical backup/recovery
but not for logical backup/recovery.
The process of generating a new dataserver is automated in the
installation script. A module called dataserver.datatools is created
using the original dataserver module. The original dataserver module
is not modified. Then, the RUN file is modified to use the new
dataserver dataserver.datatools. Again, a copy of the original RUN
file is saved. You must shut down and restart the server to make the
changes take effect.
There are no known problems caused by this modification, which has
been approved by Sybase. In addition, it is easy to undo the
modification and revert back to the original environment.
When I installed SQL-BackTrack, an error message indicated that the
dataserver was not executable or incorrect.
Make sure the UNIX nm program is installed.
How can I be sure I'm installing the correct files from the
SQL-BackTrack distribution tape?
The SQL-BackTrack distribution tape contains a separate tape file for
each supported platform. To see the contents of the tape, use the
command cat <device_name>, where device_name is the name of your tape
drive. This command displays the table of contents. Then, rewind the
tape and use fsf to forward to the correct file.
License Updating
When I try to run dtbackup, an error message indicates that the
connection was refused or there is a named pipe write error.
Please see the Appendix, `Manually Updating System Files' in the
SQL-BackTrack Installation Notes for information on configuring the
system files for the SQL-BackTrack license manager.
Error Messages
If I run a backup using the UNIX cron facility, how do I know the
backup completed?
If you schedule a backup using cron, any SQL-BackTrack output or error
messages are mailed to the user id under which that cron job was run.
When I run dtbackup, an error message indicates that a lock failed.
This happens because SQL-BackTrack is unable to create the software
locks necessary for resources such as a tape device. By default, these
locks are created in the /tmp directory. If /tmp is a `tmpfs'
filesystem, the locks will fail. To fix this, declare an alternate
directory where the locks can be created using the environment
variable DTTEMPDIR. To do this, enter the following commands:
setenv DTTEMPDIR /<some_other_directory>
(in C shell)
DTTEMPDIR=/<some_other_directory>; export DTTEMPDIR
(in Bourne shell)
Then, run dtbackup.
When I try to run dtbackup, an error message indicates that the
descriptor cannot be found.
Increase the Sybase open objects descriptor definition. The following
example illustrates how to set the value of open objects to 1500:
sp_configure [open_objects, 1500]
Note for Solaris Users:
The SUNWbtool package, which is part of the Solaris system, must be
installed. If it is not installed, reinstall it with the pkgadd
command. To determine whether it is installed, enter the following
command:
pkginfo -I SUNWbtool
Tape Recycling
I want to recycle tapes using the same volume name. How can I do this?
Generally we don't recommend recycling tape with the same volume
name. However, if you want to do this, you can. To keep a finite
number of backup generations and recycle the tapes using the same
volume name, follow these steps when you want to re-use a tape:
1. Re-initialize the tape using the dttape utility.
2. Remove the old volume entry from the .dtoptions file.
General
How should file protection be set up?
To back up or recover with SQL-BackTrack, you need read and execute
permission on the /usr/datatools directory and the files under it.
You need write permission on the control directories you create; these
do not have to be in usr/datatools.
------------------------------------------------------------------------------
Contacting DataTools
To contact DataTools, send questions or comments to:
Phone: (415) 617-9100 Fax: (415) 617-9101
Sales: 1 (800) 721-8665 or (415) 617-9100
Support: 1 (800) 243-9670
DataTools, Inc.
750 Menlo Avenue
Menlo Park, CA 94025