NetBackup™ for Microsoft SQL Server Administrator's Guide
- About NetBackup for SQL Server
- Installation
- Host configuration and job settings
- Installing the Veritas VSS provider for vSphere
- Configuring RBAC for SQL Server administrators
- Managing SQL Server assets and their credentials
- About discovery of SQL Server objects
- About registering SQL Server instances and availability replicas
- Configuring backups with SQL Server Intelligent Policy
- Performance tuning and configuration options
- Protecting SQL Server availability groups
- Protecting SQL Server availability groups with intelligent policies
- Protecting SQL Server availibility groups with batch file-based policies
- About protecting the preferred replica in a SQL Server availability group (batch file-based policies)
- About protecting a specific node in a SQL Server availability group (batch file-based policies)
- About protecting the preferred replica in a SQL Server availability group (batch file-based policies)
- Protecting SQL Server with VMware backups
- About protecting an application database with VMware backups
- Create a protection plan to protect SQL Server data with a VMware backup
- Configuring backup policies with Snapshot Client
- Using copy-only snapshot backups to affect how differentials are based
- About SQL Server agent grouped snapshots
- Protecting SQL Server in a cluster environment
- Managing protection plans for SQL Server
- Restoring SQL Server with the NetBackup web UI
- Using instant access with SQL Server
- Prerequisites when you configure an instant access SQL Server database
- Configuring batch-file based policies for SQL Server backups
- Requirements to use batch files with NetBackup for SQL Server
- Schedule properties for SQL Server batch file-based policies
- Configure a batch file-based policy for a user-directed backup of read-only filegroups
- Performing backups and restores with the NetBackup MS SQL Client
- Redirect a SQL Server database to a different host (NetBackup MS SQL Client)
- Restoring multistreamed SQL Server backups
- Using NetBackup for SQL Server with multiple NICs
- Performance and troubleshooting
- About debug logging for SQL Server troubleshooting
- About disaster recovery of SQL Server
- Appendix A. Other configurations
- About SQL Server backups and restores in an SAP environment
- About NetBackup for SQL Server with database mirroring
- Appendix B. Register authorized locations
Restore the R/3 database after a disk crash
This topic describes how to restore the database when the R/3 database disk system is damaged or the transaction log disk system is damaged. This process is only applicable to a configuration with three disk systems: one system for the R/3 database, one for the R/3 transaction logs and one for all others.
Note:
The R3 database must not be in use when you are performing a restore operation. Make sure that all SAP services are stopped before you attempt a restore with NetBackup.
Warning:
If the disk system on which the R/3 database resides is damaged, it is vital to immediately back up the currently active transaction log. This log backup is done to prevent loss of data. Without a backup of the current log, the database can only be restored to the status at the time of the last transaction log backup. If work has been carried out on the R/3 system since then, this work is lost.
To restore the R/3 database after a disk crash
- Back up the current transaction log.
- Replace damaged disks.
Replacing damaged disks in a RAID disk system is normally a straightforward procedure. If you are uncertain how to proceed, see the documentation of your hardware vendor to learn how to handle the disks. The new disks must be formatted and assigned the same drive letter as the old disks.
- Restore the database logs and transaction logs.
The central phase of a restore operation is the reloading of the database backup and the application of the available transaction logs. When the database backup is reloaded, the database files are automatically recreated. The data is copied from the backup device to the newly created files. Once this copy has been done, the transaction logs are applied in the same sequence as they were originally made. In a final step, open transactions that were not completed at the time of the database failure are rolled back.