Before you begin a disaster recovery, make sure to perform the following:
Perform frequent backups of your Sybase server and the latest file system.
Make sure that the Originating host and destination host have the same
Sybase version.
Use the File System iDataAgent to backup the Sybase Home and dataserver
configuration files.
Managing Backups
As a best practice, it is recommended that you group databases into multiple
subclients as follows:
Add larger databases into separate subclients.
Add small databases together into one or more subclients. This is
important for the following reasons:
During Disaster recovery, when you have to quickly rebuild the
entire instance, you can concurrently restore all the subclients
together.
During Backup failures, the backup will restart from the beginning
of the database instead of from the beginning of the entire instance.
Similarly, this will ensure that large database backups are not affected
by restarts from a smaller database.
Once the subclients are created, schedule frequent backups for
dynamic data and regular backup schedules for static data in the Sybase Server.
In the case of disaster recovery, where a full system restore is required, you
must first rebuild the system to exactly the state as it existed before the problem.
Use the following steps to rebuild the operating system:
Rebuild the hardware if needed.
Install the same version of the operating system with the same patches
that were previously installed.
Edit the host file of the client to include the CommServe name.
Install the File System iDataAgent
on the client.
Perform a full system restore of the File System iDataAgent.
This will restore the Sybase application files and all of the
iDataAgent
software. If there are any problems with the Sybase
iDataAgent, we recommend
that you un-install and re-install the software in the same drive as it was
previously installed. Use the same installation parameters, passwords, and
backup type settings as were previously used. In addition to restoring your
operating system, this operation will restore the Sybase application files
and the Sybase iDataAgent.
Reboot the computer.
Create a Sybase server on the destination host. Ensure that you are including the
parameters that were used for the Sybase server before the system
failure.
On the destination host, start up the Sybase server and then shut down the
server.
When the Sybase server is corrupted or lost, you can restore and recover it from
the latest full backup.
Make sure that the physical devices of the database exist physically on the
server before performing a full system restore. If they do not exist on the
server or you do not know the device list, perform the following to retrieve the list
of devices existing on the server:
1.
From the CommCell Browser, navigate to Client Computers |
<Client>
| Sybase.
Right-click the <Instance>, point to All Tasks, and then
click Browse
Backup Data.
2.
Click OK.
3.
In the right pane of the Browse window, click the <Instance>and select all the entities.
Click Recover All Selected.
4.
Click Advanced.
5.
Click Options tab. You will see the list of all
the devices and their sizes. You can create devices needed for restore
based on this list.
Run the following query on CommServe database to find the max page
size of your sybase server:
select * from APP_InstanceProp where
componentNameId in (select id from APP_InstanceName where name = '<your
sybase server name>') and attrName = 'SYBASE Max page size'
Example:
To get max page size for S155dbs12 Sybase server:
select * from APP_InstanceProp where componentNameId in (select id
from APP_InstanceName where name = 'S155dbs12') and attrName = 'SYBASE
Max page size'
Verify the that the physical devices required for full system
restore are existing under the specified locations as informed in
steps 1 to 5.
Step-6 informs you to create a master
device which can be used by master, model and tempdb databases.
If you have lost the devices due a corruption or hardware issue, you
have to manually create them. Use the following command to manually
create a device:
For 15.x and above:
# isql –Usa –P –S<Sybase Instance Name>
1> disk init name = “<device name>” , physname =
“device physical path>” , vstart=0,
size = “<device size>M”
go
For 12.5 and above:
# isql –Usa –P –S<Sybase Instance Name>
1> disk init name = “<device name>” , physname = “device physical path>”
, vstart=0,vdevno= <devId>, size = “<device size *1024 *1024/pagesize>”
go
Please note that the devId is unique for each device and should be >0
Example:
1> disk init name='sysprocsdev',
2> physname='/Sybase/sybase15.0.3/data/S155dbs12/sysprocs.dat',
3> size='512M'
4> go
1> disk init name='TEST',
2> physname='/Sybase/sybase15.0.3/data/S155dbs12/test.dat',
3> size='1228M'
4> go
1> disk init name='TEST_LOG',
2> physname='/Sybase/sybase15.0.3/data/S155dbs12/test_log.dat',
3> size='500M'
4> go
9
Use the following command to shutdown the dataserver
after creating the devices:
isql –Usa –P –S<Sybase
Instance Name>
shutdown with no wait
exit
Perform a full restore to restore an entire Sybase server.
When restoring an entire server, make sure that the
server is offline. Use the following steps to restore the Sybase server from
CommCell browser:
1.
From the CommCell Browser, navigate to Client Computers |
<Client>
| Sybase.
Right-click the <Instance>, point to All Tasks, and then
click Browse
Backup Data.
2.
Click OK.
3.
In the right pane of the Browse window, click the <Instance>and select all the entities.
Click Recover All Selected.
4.
Click OK.
5.
Once the database is restored, verify that the restored database and log
files are available in the original location.
A full Sybase restore may fail if one or more database devices are defective
or have been physically deleted and the corresponding databases have therefore
been marked as suspected. In such a case, all the databases marked
as suspected and the corresponding devices whose files have been
lost must be dropped and re-created.
Use the following steps to resolve and restore defective devices and
suspected datbases:
1.
Issue the following command to determine whether the database is
suspected:
sp_marksuspect (<database name>)
Example:
sp_marksuspect (<sybdb1>)
2.
Drop the suspected database using the following command:
dbcc
dbrepair (<database name>, dropdb)
Example:
dbcc
dbrepair (<sybdb1>, dropdb)
3.
If the database to be recovered is "sybsystemprocs"(system
database),
use the following command to drop the corresponding device (since stored
procedures are not available at this point):
disk release name = <device
name>
Example
disk release name = <tempdbdev>
4.
If any of the data device files do not exist but the device entry exists
in sysdevices, drop those devices using the
following command:
sp_dropdevice <device name>
Example:
sp_dropdevice <tempdbdev>
5.
Repeat the above procedure for each suspected database.
6.
Resume the restore starting with the first database that was deemed
suspected.
