Error:-

0xe00084f4 - An unknown error has occurred.

Solution:-

The following errors may occur when backing up to tape if the latest tape device drivers are not
installed: (Figures 1 and 2)

Figure 1

Figure 2

To install the latest tape device drivers go to:

http://support.veritas.com/rd/bews-downloads.htm

Source:-
http://support.veritas.com/docs/283866
Error:-

"Remote calls are not allowed for this process"

Solution:-

Figure 1

This error occurs when the remote computer does not have Distributed COM (DCOM) enabled.
To resolve this problem, enable DCOM on the remote computer. To do this, follow the instructions
given below.

For Windows Server 2003, Windows 2000, or Windows XP:

1. Click Start | Control Panel

2. Double-click Administrative Tools, and then double-click Component Services to open the
Component Services Microsoft Management Console (MMC)

3. Expand Component Services, and then expand Computers

4. Right-click on My Computer, and then click Properties

5. On the Default Properties tab, select the Enable Distributed COM on this computer check
box, then click OK

6. Close the Component Services MMC

7. Restart the computer

For Windows NT:

1. Click Start | Run

2. In the Run dialog box, type dcomcnfg, then click OK

3. In the Distributed COM Configuration Properties dialog box, on the Default Properties tab,
select the Enable Distributed COM on this computer check box, and then click OK

4. Restart the computer

Source:- http://support.veritas.com/docs/257194
Error:-

The Advanced Open File Option cache file is not removed after a successful backup.

AOFO: Initialization failure on: "C:". Advanced Open File Option used: Symantec Volume
Snapshot Provider (VSP).
AOFO: Unable to get minimum quiet time for physical volumes. Reduce the activity on these
volumes, or wait and run the backup when there is less activity on the volumes.
AOFO: Initialization failure on: "D:". Advanced Open File Option used: Symantec Volume
Snapshot Provider (VSP).
AOFO: Unable to get minimum quiet time for physical volumes. Reduce the activity on these
volumes, or wait and run the backup when there is less activity on the volumes.

Solution:-
To troubleshoot the cause of the Open File Option (OFO) quiet time message, follow these steps:

1. Create a backup job of only the drive that reported the OFO message and select Use Open
File Option if available from the backup job's Advanced tab (Figure 1)

Figure 1
2. Run the backup job. When the job starts, it will appear to hang. In reality, OFO is trying to
establish a "quiet time" for the drive being backed up. By default, OFO will try for 2000 seconds
(33.3 minutes) to establish 5 seconds of quiet time.

3. On the computer being backed up, stop each third party service (one service at a time). After
stopping each third party service, wait 30 seconds before stopping the next third party service.
During each 30 seconds, examine Backup Exec to determine if the job is still hung or if the
backup job started to back up data. If the backup job starts backing up data, then the last third
party service that was stopped caused the OFO quiet time message.

Warning: Before stopping any Windows service, verify what the service does and what the
consequences are of stopping the service. In order to minimize Windows service downtime,
schedule server downtime to perform the steps above .

After determining the cause of the OFO quiet time message, try to decrease the quiet time
required by OFO. After changing the registry keys listed below, follow the troubleshooting steps
listed below. If OFO is able to establish a minimum quiet time, Backup Exec will not appear to
hang.

On the Backup Exec computer:

Version 9.x and 10.x:

1. Go to Tools | Wizards | Advanced Open File Option Wizard

2. Click Next, proceed through the wizard, enter in login information which has administrative
permissions to the machine running Advanced Open File Option (AOFO)
3. Click Next, proceed through the Static Volume Location settings, click Next again
4. Enter the new Minimum Quiet Time setting (Figure 2)

Figure 2
5. Click Next, and observe the warning message (Figure 3)

Figure 3

6. Click OK and then click Finish

Why can't the minimum quiet time be set below 2 seconds?

By default, the minimum quiet time is set to 5. In almost all circumstances, 5 seconds is long
enough for any application to commit all transactions and to be in a synchronized state. Lowering
the quiet time may cause problems. For example, application X updates a database and then
updates its index 3 seconds later. Since the minimum quiet time for OFO is 5 seconds, OFO will
create a snapshot of the logical drive 5 seconds after the index is updated. If the OFO minimum
quiet time is lowered to 2, the snapshot will occur after the database has been updated but before
the index has been updated. The backup operation and restore operation will proceed without an
error. Only when the user tries to use the application will the user find out that the index does not
match the information in the index. While lowering the minimum quiet time may resolve this issue,
there is an increased chance that an application's files will be backed up out-of-synchronization.

On the remote computer where OFO is installed:

1. If using Backup Exec 7.x for Windows NT, stop the OFO service VncSnapshot in Control
Panel | Services
2. Start Regedt32.exe
3. Locate and double-click the following registry key:
• Registry Key (Backup Exec 8.x):
/HKEY_Local_Machine/Software/VERITAS/Open File
Option/Config/MinQuietTime
• Registry Key (Backup Exec 7.3):
/HKEY_Local_Machine/Software/Vinca/Snapshot/Config/MinQuietTime
• Registry Key (Backup Exec 7.2): /HKEY_Local_Machine/Software/Seagate
Software/Backup Exec/Engine/Backup/OFO Minimum Quiet Time
• 4. Change the Radix to Decimal
5. Decrease the value to the number of seconds that Open File Option (OFO) should wait for
disk inactivity
6. Click OK
7. Exit Regedt32.exe
8. If using Backup Exec 7.x for Windows NT, start the OFO service VncSnapshot in Control
Panel | Services

Warning: Incorrect use of the Windows registry editor may prevent the operating system from
functioning properly. Great care should be taken when making changes to a Windows registry.
Registry modifications should only be carried-out by persons experienced in the use of the
registry editor application. It is recommended that a complete backup of the registry and
workstation be made prior to making any registry changes.

Source:-
http://support.veritas.com/docs/194940
 Error:-
e00081d9 - The Backup Exec job engine system service is not
responding.

Document ID: 278472

Job Error "e00081d9 - The Backup Exec job engine system service is not responding."
reported in History Log when running Backup Jobs submitted from a CASO to a MMS
server.
Exact Error Message
Error : e00081d9 - The Backup Exec job engine system service is not responding.
For additional information regarding this error refer to link V-79-57344-33241

Details:
Jobs created on a Central Admin Server (CASO) that are due to run on a managed Media Server
(MMS) initially run correctly, but now fail with error "e00081d9 - The Backup Exec job engine
system service is not responding."

This issue has been seen once in a live environment, and in that environment appears to have
been caused by the Job Engine on the MMS terminating unexpectedly during the previous
attempt to run the same job.

From attempts to replicate this issue under test conditions, the CASO server should recover the
original job from the MMS once the Backup Exec services on the MMS are restarted. This
recover process should remove the job from the Job Monitor on the MMS ensuring that this issue
does not occur. The solution provided is intended to provide a method of recovery should the
usual process fail.

Solution:
• On the Media Server configured to run as a CASO, open the Backup Exec Console
• Select the Job Monitor Screen and make a note of the name of the job that
generates the error and fails to submit correctly to the MMS
• On the Media Server configured as the MMS, open the Backup Exec Console
• Select the Job Monitor Screen and remove the job from the 'Current Jobs' List with
the same name.

Additionally this error may also occur if more than one jobs start simultaneously. In this case
restarting the Backup Exec Job Engine Service will resolve this error.

Source:- http://support.veritas.com/docs/278472

Error:-
 When adding a Media Server to the Exec View Console, we get the error “Server not
responding”.

Solution:-
"The Backup Server is not Responding" error is reported when attempting to add a
clustered media server to the VERITAS ExecView console to monitor.
Exact Error Message
The Backup Server is not Responding

Details:
After successfully installing the ExecView Communication Module (ECM) on each node of a
clustered Backup Exec media server, the media server cannot be added to the ExecView console
to be monitored.

"The Backup Server is not Responding" error will be reported: (Figure 1)

Figure 1

The reason for this problem is that ExecView 3.x does not support "cluster aware" installations of
Backup Exec.

It is not possible to add clustered media servers to the ExecView console at this time.
Source:- http://support.veritas.com/docs/254466

Error:-
V-79-57344-34036 - An unknown error has occurred.
Solution:-
How to troubleshoot issues with a Robotic Library or Tape Drive in Backup Exec 9.x and
10.x
Details:

Backup Exec (tm) 9.x for Windows Servers includes support for a wide array of robotic libraries
(also referred to as an autoloader) and tape drives. Occasionally, the hardware may be displayed,
appear offline, does not function correctly, or may report specific errors in the job log. This
document has several suggestions on how to resolve these issues.

The first step in troubleshooting a robotic library and tape drive in Backup Exec is to verify that
the device is listed on the Hardware Compatibility List
( http://entsupport.symantec.com/carveout_PID_15047_view_CL.htm ). If the device is not on the
Hardware Compatibility list, contact the hardware manufacturer to get the device supported with
Backup Exec. Symantec Corporation is always certifying new devices, and updates to this list are
made frequently.

The next step is to ensure that Robotic Library Support is enabled within Backup Exec. To check
if Robotic Library Support is enabled; in the Backup Exec console click on Tools then select the
Serial Numbers and Installation menu item. On the installation wizard go past the serial numbers
screen and verify that Enable Robotic Library Support option is selected and installed. If the
option is not selected, select the option and proceed with the installation. See Figure 1 for more
details.

Figure 1

Ensure that the latest drivers and firmware have been installed for the tape drive, robotic library,
and for the SCSI controller. Symantec drivers should be loaded to the tape drive for best
performance. Symantec does not test performance or compatibility with Original Equipment
Manufacturer (OEM) drivers, unless noted on the Hardware Compatibility List. Backup Exec tape
drivers and robotic library drivers can be downloaded from the Symantec Support Web site at
http://support.veritas.com/rd/bews-downloads.htm . Select the appropriate Backup Exec version
number in the Product Version drop-down box, and select Driver as the File Type. Contact the
hardware manufacturer for the latest firmware for the robotic library, tape drive, and SCSI
controller.
To verify that the Symantec tape drivers are installed, do the following:

On Windows NT 4.0:

1. Open Control Panel

2. Double-click Tape Devices

3. Make sure that a driver is loaded for the tape drive. This will be indicated as (Driver Loaded)
next to the tape device (Figure 2).

Figure 2

4. Select the Drivers tab. If there appears to be no driver loaded for the tape device, this signifies
that Symantec drivers are loaded (Figure 3).

Figure 3
On Windows 2000 and Windows 2003:

1. Right-click My Computer, and click Properties

2. In the Hardware tab, click Device Manager (Figure 4)

Figure 4

3. Under the Tape Drives heading, select the tape drive, and click Properties

4. In the Drivers tab, the provider should be VERITAS Software Inc. (Figure 5)

Figure 5
Note: If the robotic library or tape drive is attached to a RAID controller, it is strongly
recommended that the device be moved to a standard SCSI controller. Robotic libraries and tape
drives may not function correctly when attached to RAID controllers.

It may be possible that the SCSI ID's for the robotic library are at a higher SCSI ID than the tape
drives that are in the robotic library. It is recommended that the tape library be at SCSI ID 2, and
that the drives that are part of the library start at SCSI ID 3, and continue upward. Please refer to
your hardware documentation on changing these SCSI IDs.

It may also be possible that the hardware is experiencing problems. Examine the system log in
the Windows Event Viewer to verify the problems. To do this, click Start | Programs |
Administrative Tools | Event Viewer. Now, check for any Event ID 5s, 7s, 9s, 11s, and 15s that
may occur on system startup, or during backup.

• Event ID 5s signify parity errors. If the Event Viewer has any of these, contact the
hardware manufacturer to resolve these events.
• Event ID 7s signify bad blocks. This could be the result of a driver issue, media that
is becoming faulty, or dirty read/write heads on the tape drive. Cleaning the
tape drive and loading the latest tape drivers from Symantec usually helps resolve
these issues.
·
Event ID 9s signify SCSI bus timeouts. These errors usually occur when the SCSI bus resets
itself, or the tape drive does not respond in a timely fashion. Sometimes slowing the SCSI bus
down can help resolve these issues. Also, loading the latest SCSI drivers and firmware can help
resolve these issues. In certain high end servers, moving the SCSI card to a different Peripheral
Component Interconnect (PCI) slot, one that does not share the same bus as a RAID controller,
has been known to fix these errors. If neither of these help resolve the issue, please contact the
hardware manufacturer.

• Event ID 11s signify controller errors. These errors are generally caused by
hardware that is not functioning correctly. Attempting to slow the SCSI bus down
and verifying that the latest SCSI drivers and firmware are loaded sometimes helps
resolve these issues. If these errors still occur, please contact the hardware
manufacturer.
• Event ID 15s signify the device is not ready for access. These errors usually occur
when the tape drive or tape library is having problems communicating with the
server. These errors are usually generated because incorrect drivers are loaded, or
the drivers are not up to date. It may also be caused by not having the latest
firmware for the SCSI controller or tape drive.
·
If, after checking the drivers and Event Viewer, the robotic library still does not show up, or it
shows up offline, checking the inquiry string of the robotic library and comparing it to the list that
Backup Exec uses will help determine if the library is reporting itself correctly. To check this,
perform the following:

1. Open Windows Explorer

2. Browse to C:\Program Files\VERITAS\Backup Exec\NT\Logs (or the folder where Backup

Exec has been installed)

3. Open the file ADAMM.LOG with NOTEPAD.EXE

4. Scroll to the end of the log file, until the last section of the device discovery is listed. Take note
of the primary inquiry string (spacing is critical to this string). The string will appear as shown in
Figure 6, but may have a different name depending on the library. The first 24 characters of the
string will be the primary inquiry string. Anything after the first 24 characters will be the firmware
version.

Figure 6
5. Open REGEDT32.EXE
(Note: REGEDT32.EXE must be used if running Windows NT 4.0 or Windows 2000.)

6. Browse to HKey_Local_Machine | System | CurrentControlSet | Control | SCSIChanger

7. Under SCSIChanger, double-click VSDLoadTable

8. When the VSDLoadTable opens, all entries will be selected. Press <CTRL + C> to copy the
data. (Note: If the data is accidentally deleted, pressing Cancel will revert the changes. If the
information inside this value is deleted, Backup Exec will not recognize the library ever, and a
reinstallation of the product may be necessary. Please refer to the last steps in this TechNote on
how to get a functioning SCSIChanger key back into the registry.)

9. Open NOTEPAD.EXE

10. Click Edit | Paste or <CTRL + V> to paste the data from the VSDLoadTable into this session
of Notepad

11. There will be two columns listed in Notepad. The first column is the name of the virtual device
driver (VXD) that Backup Exec 9.x will load to communicate with the robotic library. The second
column (it will appear in some cases as two columns) will be the inquiry string. From Step 4,
search through this list and look for the exact inquiry string (spaces are critical in looking for the
inquiry string. If there are four spaces in the inquiry string from Step 4, but only three show up in
the VSDLoadTable, then this is a mismatch) (Figure 7). If the inquiry string is listed, write down
the virtual device driver from the first column, and proceed to the next step. If the inquiry string
does not show up, or does not show up exactly like the inquiry string in the VSDLoadTable, then
there might be two problems. The first problem is that the Robotic Library has a bad version of
firmware which is reporting an incorrect inquiry string, firmware which is brand new and has a
new inquiry string that Backup Exec does not recognize, or the robotic library is faulty. If the
firmware is brand new, downloading the latest version of the Backup Exec drivers may resolve
this issue, as newer drivers do contain a newer VSDLoadTable. The second problem may be that
the VSDLoadTable may be corrupt, and needs to be reinstalled. To perform this, please refer to
the last section of this document on how to delete SCSIChanger, and recreate it.

Figure 7

12. Click Start | Run, and type WINMSD. This opens up system information (Windows NT
Diagnostics for Windows NT 4.0) for the server.

13. In Windows NT 4.0, click the Services tab, and then click Devices. For Windows 2000,
Windows XP, and Windows 2003, click Software Environment, and then Drivers (System
Drivers for Windows XP and Windows 2003).

14. In this list, search for SCSIChanger. This service should be started. If it is not started, then
there is a problem with Backup Exec either trying to load the correct driver for the robotic library,
or there is a corrupt driver that cannot be loaded. Please refer to the last section of this document
on how to get a functioning SCSIChanger key.

15. If SCSIChanger is started, look in the list for the virtual device driver written down in step 11.
If that virtual device driver shows up, and is not started, there might be problems loading the
driver. This can be caused by faulty hardware, incorrect termination, or bent pins on the SCSI
cable. It may still be possible that the virtual device driver is corrupt. Follow the steps provided in
the last section of this document to help resolve this issue by creating the SCSIChanger key.
16. If all these steps check out, proceed with the next steps provided in this document to attempt
to bring the robotic library online

If the tape drive still appears offline after following these steps, do the following:
1. Right-click the Tape Drive, and select Properties

2. Click the Configuration tab, clear the Enable for Backup Exec check box, and click OK
(Figure 8). The device will now be disabled.

Figure 8

3. Right-click the Robotic Library, and click Properties

4. Click the Configuration tab, clear the Enable for Backup Exec check box, and click OK. The
device will be disabled now.

5. Right-click the tape drive, and click Delete

6. Right-click the robotic library, and click Delete

7. Quit Backup Exec

8. Start BEUtility
Note: By default, it is located in the C:\Program Files\VERITAS\Backup Exec\NT directory.

9. From the right pane, select the Backup Exec Media Server
Note: If it is not listed here, right-click All Media Servers, and select New Media Server.

10. Under the Services Task, click Stop Services. Once all the services are stopped, click Start
Services.

11. Start Backup Exec, and click Devices. The device should appear online, and function
correctly.

If the tape drive still appears offline, it may be possible that the Backup Exec hardware database
is corrupt.

To repair the database, do the following:

1. Quit Backup Exec

2. Start BEUtility, and select the Backup Exec Media Server

3. Under the Services Task, click Stop Services

4. Under Database Tasks, click Repair Database (Figure 9)

Figure 9

5. Under the Services Task, click Start Services

6. Start Backup Exec, and click Devices. The device should appear online and function correctly.

If the tape drive still appears offline, it may be possible that the Backup Exec database is corrupt
beyond repair. If this is so, it may be possible to load the database from backup, or replace the
database altogether.

Note: It is strongly recommended that a backup of the database be performed, in the case that
restoring or replacing the Backup Exec database does not resolve the issue. To do so, please
follow these steps:

1. Quit Backup Exec

2. Start BEUtility, and select the Backup Exec media server

3. Under the Services Task, click Stop Services

4. Open Windows Explorer

5. Browse to the Backup Exec Data folder (by default it is located in C:\Program
Files\VERITAS\Backup Exec\NT\Data)

6. Create two new folders inside the Data folder. Name the first folder OriginalBackup and the
second folder NewBackup.

7. Copy the file BEDB.BAK into the OriginalBackup folder

8. In BEUtility, under Database Tasks, select Dump Database

9. In Windows Explorer, under the Data folder, copy the newly created BEDB.BAK file into the
NewBackup folder. (Do not delete this folder after copying the file, as this is the most recent copy
of the Backup Exec database containing all jobs created, schedules, alerts, media sets since the
last time Backup Exec internally backed up the database.)

10. In the OriginalBackup folder, copy the BEDB.BAK file back into the Data folder, overwriting
the existing file

To restore a backup copy of the Backup Exec database:

1. Quit Backup Exec

2. Start BEUtility, and select the Backup Exec media server

3. Under Services Tasks, click Stop Services

4. Under Database Tasks, click Recover Database

5. Select the option to Drop existing database and reload from backup. Click OK (Figure 10).

Figure 10
6. Under Services Task, click Start Services

7. Start Backup Exec, and click Devices. The device should appear online and function correctly.

To install a new Backup Exec database, do the following:

Caution: Doing this will result in all backup jobs and selection lists, schedules, media sets,
partitions, passwords, alerts, alert history, and notifications being deleted.

1. Quit Backup Exec

2. Open BEUtility, and select the Backup Exec Media Server

3. Under Services Tasks, click Stop Services

4. Under Database Tasks, click Recover Database

5. Select the Drop existing database and reload from base check box and click OK (Figure 11)

Figure 11

6. Under Services Tasks, select Start Services

7. Start Backup Exec, and click Devices. The device should appear online and function correctly.
If either of these two options do not work (restoring or replacing the database), the original
database can be reverted back to.

1. Quit Backup Exec

2. Open BEUtility, and select the Backup Exec media server

3. Under Services Tasks, click Stop Services

4. Open Windows Explorer

5. Browse to the Backup Exec Data folder (by default it is located in C:\Program
Files\VERITAS\Backup Exec\NT\Data)

6. In the NewBackup folder that was created earlier, copy the file BEDB.BAK back into the Data
folder, overwriting the existing file

7. In BEUtility, under Database Tasks, click Recover Database

8. Select the option Drop existing database and reload from backup. Click OK.

9. Backup Exec is now back to the original database

If the robotic library still appears offline, sometimes a powercycle of both the server and the
library helps resolve the communication failure. It is recommended that the following steps be
performed when doing so.

1. Shut down the Backup Exec media server by clicking Start | Shut down | Shut Down

2. Shut down the robotic library or tape drive

3. Start the robotic library or tape drive. Verify that the devices initialize properly and do not report
any errors.

4. Start the server. Verify that the device posts correctly during SCSI startup.

It may be possible that the robotic library does not show up inside Backup Exec or it does not
show up correctly. Following the steps above to repair the database, or replacing the database
with either a backup copy or a fresh copy sometimes will help resolve the issue.

If those steps do not, do the following:

1. Quit Backup Exec

2. Start BEUtility, and connect to the Backup Exec media server
3. Select the option to stop the Backup Exec services
4. Click Start | Run, and type REGEDT32. Click OK.
5. Browse to HKey_Local_Machine | System | CurrentControlSet | Services. Delete the
SCSIChanger key.
6. Browse to HKey_Local_Machine | System | CurrentControlSet | Control. Delete the
SCSIChanger key.
7. Close REGEDT32
8. Shut down the Backup Exec media server and the robotic library
9. Start the robotic library, and verify that the device initializes correctly
10. Start the Backup Exec media server. Verify that the robotic library posts correctly on SCSI
startup.
11. After the server starts, click Start | Settings | Control Panel
12. Double-click Add/Remove Programs
13. Select Backup Exec for Windows Servers, and click Change
14. Click Next when the Welcome screen displays. Under Local Selections, select the Repair
option (Figure 12).

Figure 12

15. Once completed, restart the server

16. Download the latest drivers from Symantec, and install them (a reboot may be necessary for
this). The robotic library should now be displayed correctly in Backup Exec.

Source:- http://support.veritas.com/docs/255501
Error:-
e000810b - Physical Volume Library Drive not found.

This issue can occur if the targeted Backup to Disk Folder (B2D) or tape drive is not available or if
the Backup Exec Services Logon Credentials are not properly configured.

SOLUTION:

1. Confirm the destination backup device that the backup job is targeted to is online and
accessible on the Backup Exec Devices Tab.

2. Confirm that the Backup Exec Job Engine Service and Backup Exec Server Service are
logging as the same service logon account in the Windows Services Snap-in (i.e.: Computer
Management). All of the Backup Exec Services should be running under the same account by
default, with the exception of the Backup Exec Remote Agent Service (RAWS), which runs under
the Local System Account. If all the services (except for the Remote Agent) are not running
under the same account, perform the steps in the following Technote to reset the services so that
the backup jobs can complete successfully:

Source:- V-79-57344-33035
Error:-
(0xE000FED1): A failure occurred querying the Writer status

Solution:-

Exact Error Message

Backup- SERVERAOFO: Initialization failure on: "Shadow?Copy?Components". Advanced Open
File Option used: Microsoft Volume Shadow Copy Service (VSS).
Snapshot provider error (0xE000FED1): A failure occurred querying the Writer status.
Check the Windows Event Viewer for details.
Writer Name: Removable Storage Manager, Writer ID: {5D3C3E01-0297-445B-AA81-
A48D7151E235}, Last error: 0x80042319, State: Failed during freeze operation (9). Consult your
Microsoft documentation for details. Check the Windows Event Viewer for corresponding
application or system errors.

Details :
The backup of a Windows 2003 server fails with the above-mentioned error (Figure 1).

Figure 1

This error usually occurs if the Volume Shadow Copy Service fails to initialize Removable Storage
Service.
The application log shows the following error: Application log error (Figure2):
Volume shadow copy service error: Writer Removable storage manager did not respond to a
GatherWriterStatus call.

Figure 2
The system log shows Event ID 15. System log error (Figure 3).

Figure 3
Cause:
This issue can occur if the internal Removable Storage Manager (RSM) database is corrupted.

Resolution:
To resolve this issue, please refer to the technote given in the Related Documents section along
with the Microsoft articles given below.

Microsoft KB article:
http://support.microsoft.com/?id=235032
http://support.microsoft.com/?id=288856

Exact Error Message

An error occurred while exporting the RSM Database files. The RSM Database could not be
backed up. ^ ^ ^ ^ ^

Details:
This issue may be related to the Removable Storage database being damaged or corrupted, and
the following error message is reported in Windows NT Event Viewer (Figure 1):

Figure 1
To resolve this issue, perform the following:
1. In Computer Management, expand the Services and Applications node, double-click
Services and locate the Removable Storage Service (Figure 2)

Figure 2
2. Stop the Removable Storage Service (Figure 3)

Figure 3

3. Use Windows NT Explorer and browse to the following location:

%SystemRoot%\System32\NtmsData. Rename the existing files in this folder to a .old file
extension, or copy them to a different folder (Figure 4).

Figure 4
4. In Computer Management, expand the Services and Applications node, and
double-click Services
5. Locate the Removable Storage Service, and start the service

Note: This should import the database from the Export folder, build a new index file, and
be consistent from when the last %Systemroot% backup was performed.

To manually back up and restore the Removable Storage database, please read
Microsoft Knowledge Base Article 235032 "Problems with a Damaged Removable
Storage Manager Database."

Source:- http://support.veritas.com/docs/231941
 Error:- (0x45D) The request could not be performed because of an I/O device
error.

Solution:-

The error "The data being read from the media is inconsistent" (e00084ca
HEX or a00084ca HEX) occurs when running a backup.
Details:
Final Error Code: e00084ca HEX (0xe00084ca HEX) or a00084ca HEX (0xa00084ca HEX)
Final Error Description: The data being read from the media is inconsistent.
Final Error Category: Backup Media Errors
Error Text In Job Log: An inconsistency was encountered on the storage media in %s.
The error occurs when Backup Exec is reading a tape prior to backup and encounters "end of
data" marker unexpectedly. Various things can cause such an error, such as losing power to the
tape drive or server, a system or engine service crash, or a tape drive failure.

A. If this error is encountered repeatedly, perform any or all of the following to resolve issues with
the tape hardware:
1. Clean the tape drive.
2. Attempt to use another tape, or attempt to use the same tape in a different drive.
3. Perform a quick or long erase on the tape.
4. Check the Event Viewer for additional errors, and resolve any Event IDs related to the
hardware (tape drive or controller). Please refer to the Related Documents section of this article
for more details.
5. Make sure the hardware devices are at the latest firmware and driver level.
6. Contact the Original Equipment Manufacturer (OEM) for additional troubleshooting, particularly
if the same errors are encountered when using the native Windows Backup application.

B. To isolate issues with a specific tape:

1. Go to the Media tab in Backup Exec.
2. Right-click on the media that is causing the error.
3. Go to Properties and check statistics.
Multiple "hard" read or write errors indicate a problem with the tape and a new tape is
recommended.

C. If this error occurs on a backup-to-disk (B2D) folder:

1. Try backup on a new backup-to-disk folder.
2. Check the hard drive capacity.
3. Look for errors referencing the hard drive in the Windows Event Viewer.
4. Defragment the hard drive.
5. Run Scan-disk against the hard drive.

Source:-
 Error:-
e000846b - The resource could not be backed up because an error
occurred while connecting to the Backup Exec for Windows Servers
Remote Agent.
Make sure that the Remote Agent is installed on the target computer
and is running.
For additional information regarding this error refer to link V-79-
57344-33899

Solution:-

Figure 1

Also, if backing up a remote Windows 2003 server, the error "The resource could not be backed
up because an error occurred while connecting to the Backup Exec for Windows Servers Remote
Agent" may appear in the job log (Figure 2).

Figure 2
If the Windows 2003 Service Pack 1 has been installed, and the firewall feature has been
enabled, then the Backup Exec (tm) Remote Agent for Windows Servers needs to be added to
the list of exceptions, for backups and restores to function as well as for the server to be selected
during backup jobs.

To add the Backup Exec Remote Agent for Windows Servers to the list of exceptions in the
Windows firewall, perform the following:

1. Open the Windows firewall, inside the Control Panel.

2. Click on the Exceptions tab.
3. Click the Add Program... button.
4. Click the Browse... button.
5. Select C:\Program Files\VERITAS\Backup Exec\RANT\beremote.exe, and click
Open.
6. Click OK.
7. Select beremote.exe if it hasn't been selected yet.

Source:- http://seer.entsupport.symantec.com/docs/276250.htm
Error:-
e000fe30 - A communications failure has occurred.

Solution:-
In Backup Exec (tm) for Windows Servers, each remote server's selections are made to look like
the selections are local. Because of this, all drives that are present on the system are enumerated
and thus can be selected to be backed up.

Microsoft Exchange 2000/2003 uses the Installable File System (IFS). This technology lays out
mailboxes, mail messages, and public stores as files and folders, which show up as drive M:.
With this, third-party applications like Microsoft Word and Internet Explorer can use file system
application program interface (API) calls to request data, and interact with Microsoft Exchange
2000/2003.

This drive should not be selected under any circumstance, as backing up the data inside this
drive can corrupt the Microsoft Exchange Information Store.

To resolve the error, modify the backup job from the Backup Set tab, and deselect the M: drive
on all Exchange 2000/2003 servers for the environment (Figure 1).

Figure 1

Source:- http://support.veritas.com/docs/273360
Error:-
0xe0008492 - Database Query Failure. See the job log for details.
Final error category: Resource Errors

Solution:-
The error "Database Query Failure. See the job log for details" (e0008492 HEX or a0008492
HEX) is reported when backing up a Microsoft SQL database.
--------------------------------------------------------------------------------
Details:
Final Error Code: e0008492 HEX (0xe0008492 HEX) a0008492 HEX (0xa0008492 HEX) Final
Error Description: "Database Query Failure. See the job log for details."
Final Error Category: Resource Errors
Error Text In Job Log: "An error occurred on a query to database <database name>"

Cause:
1) Selection of the non existent database in the backup job.
2) MDAC mismatch DLL.
3) Restrict anonymous key is set to "0".
4) Both SQL Server 7.0 (default instance) and SQL Server 2000 (named instance) are installed
on the same computer.

Resolution:
1) Remove the selection of the non existent database in the backup job.
2) Run the MDAC component checker to check for MDAC mismatch DLLS. If mismatch is found,
please contact Microsoft for getting the expected DLL.
3) Enable the restrict anonymous key following the technote given in the related link.
4) If both SQL Server 7.0 (default instance) and SQL Server 2000 (named instance) are installed
on the same computer, an application that uses the SQL Server Virtual Device Interface (VDI)
may fail to back up a SQL Server 7.0 database , Please refer to the following Microsoft article.

Acknowledgement Microsoft:
http://support.microsoft.com/kb/q280759/

Source:-
http://seer.entsupport.symantec.com/docs/273360.htm
 Error:-

0x80042306 2147754758

0x80042306 - 0x80042306 (2147754758)

Final error category: Other Errors

Solution:-

1. Check the Volume Shadow Copy Service (VSS) writer status by running the
command VSSADMIN LIST WRITERS. For additional information refer to the
Related Documents section at the bottom of this document.
Review the output and ensure that the writers are all showing a State of "[1]
Stable" and that Last Error is showing "No error."

2. If the issue persists, attempt to reboot the server.

Note: In most cases rebooting the server resolves such issues, in case the issue
is unresolved and the writer continues to show failed status, please refer to the
Microsoft Q article mentioned below or contact Microsoft for assistance.
For more information regarding the information on causes why the Shadow Copy
Components fail, please refer to the Microsoft Q article 826936.