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-AA81A48D7151E235}, 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-7957344-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.

Sign up to vote on this title
UsefulNot useful