![]() |
![]() |
![]() |
![]() |
CHAPTER 9 Troubleshooting
This section describes how to troubleshoot problems with Backup Professional. The first section discusses troubleshooting different categories of problems and the remedies that can be applied. There are many ways that a backup and restore can fail due to the long path the data must traverse in going from the client machine to the tape media. In general, the errors can be divided into one of the following categories: database, network, device system, configuration, human error, software bugs, licensing, jukebox, or problems on the client. Each of the above categories will be discussed in further detail.
9.1 Calling For Support
After reading this troubleshooting guide, and as a last resort you should contact technical support to help you alleviate the problem. The most popular method is by fax or e-mail using the Technical Support sheet. This is usually the most expedient method because the Technical Support sheet contains the information to quickly solve the majority of problems.
To generate the Technical Support sheet, select the [Help->Generate Tech Support Info] menu from the Administration utility. This gathers information about your BP installation and allows you to specify the problem. From the Tech Support dialog, you can add information about failed tasks by choosing the [Problem->Backup/Restore Problem] menu. You can add log files using the [Problem->Add Log File] menu.
Enter the specifics of your problem into the middle section of the dialog. Fill out your contact information in the top-left section and choose the [File->Save Contact Info] menu. When you have completed the form, select either [File->Email To Vendor] or [File->Print] and fax the sheet to the vendor contact at the top.
You will be contacted shortly by a technician via e-mail or phone depending on the difficulty of the solution.
9.2 BP Process is Consuming All System Resources
You might notice that after a large master backup, the database update procedure is consuming excess resources. You see the offending process is updatedb. Never use a kill -9 on this process as it leaves the database in a corrupt state. Instead use [Misc->BP Processes] to kill the process. Later, when the system is less heavily used, tasker will restart this process. Until that time, you cannot view files from that backup.
9.3 Database
The most common database problem is when an attempt to write a record fails because of a duplicate key. In general, this means that there is some sort of problem with the database and/or the indexes. This can be quickly remedied. The first step to solve a potential database problem is to stop tasker and restart it. When tasker starts, it checks the integrity of every database file and if there is a problem the file is rebuilt. This cures about 80 percent of database problems. Keep in mind, you can start and stop tasker even if a previous backup is in progress as they are independent of each other. However, if the backup in progress is in the phase of doing a database update it is doubtful that you will make much progress in repairing the database by simply starting and stopping tasker.
Also, you should exit from all applications that are running Backup Professional including both the character and the X-interface. Then go back into a single application using either the character or the X-interface, then stop and restart tasker. In the character interface, this is under the [Tasks] menu and is entitled "Start Tasker" and "Stop Tasker". Then repeat the original step where you expected a database problem.
If the above remedies fail you should go into the database utilities and first check the integrity of the database and then rebuild it. You can rebuild the entire database or only a particular section. Sometimes a complete database rebuild can take some time as you may have a large number of files, tapes, and backups in the database.
If the above fail to correct a database problem you can run the script $BPDIR/util/reset_db.sh. This completely resets the database and eliminates all history of backups, tapes and files. It preserves your clients, configuration options, and tape devices. After this is complete, you then need to re-import all your tapes.
A large number of database problems result from administrators killing BP processes using kill -9. Never use this since it does not allow the process to clean up after itself. Any database files the process was working on are left in a corrupt state. Instead, use [Misc->BP Processes] to kill a process. Alternatively, use kill or kill -15 to kill a process. Please wait a minute or two for the process to clean up after itself and mark the database as intact. If you inadvertently use kill -9, stop and start tasker so that it can check and rebuild if necessary any database files that are corrupt. Keep in mind, tasker re-launches any database update processes after about 10 minutes of restarting.
9.4 Network
Following is an illustration to help you understand the network connection directions taken by various Backup Professional tasks. Each connection operates on two IP ports. One being the bpd service (from /etc/services on Unix) and the other port being dynamic by default. The first port is the control port, while the second is referred to as the data port. See "Firewalls" on page 128 for more information on how to specify a static data port.
FIGURE 42. Request to Backup or Restore![]()
Figure 42 illustrates a backup or restore request. The client (this may be any computer with Backup Professional installed) makes a request to the tape server to queue the request. When resources (tape drive, etc.) are available, the queued task becomes active and the network connection in Figure 43 is performed.
FIGURE 43. Initiate a Backup or Restore![]()
To initiate a backup, the tape server connects to the client and makes it known that the client should perform a backup or restore. At this point the connection is broken and the client takes over to drive the data to the server.
FIGURE 44. Put/Get Data to/from Tape Server![]()
The final connection phase of a backup or restore is for the client to re-connect to the tape server to send data on a backup, or read data on a restore. This portion of the connection protocol is very interesting on a network where the client and tape server are separated by a firewall. Actually, the other connections can have firewall repercussions depending on how the firewall is configured. Initially, the client connects to the server on the control port, and the server connects to the client on the data port. When connecting through a firewall, you will want to allow both control and data connections. Also, both server and client must know these static ports. See "Firewalls" on page 128 for more information.
Network problems in most all cases stem from a configuration problem on your internal network. Some people have tried to use a direct IP number in the past with Backup Professional and this is simply not supported. Backup Professional ensures that the client computer is who they say they are because of security concerns in restoring data. Obviously, you would not want someone to emulate a particular client and take all data for that client from the server without any verification or validation.
Because of this, Backup Professional does what is called a reverse name lookup. This means it confirms that the IP address of the client's request matches the IP address that it gets when it queries the system. Furthermore, if it asks the system for the name of the client given the IP address, it is the same name that the client says it is. This is very similar to the authentication protocol used with rlogin. If you are having trouble either with the backup or verify of a client first be sure that you can rlogin from the client to the server (See "Firewalls" on page 128).
Most commonly, the problem is in the host file (/etc/hosts on Unix machines) or with Domain Name Services (DNS). Another common problem is uppercase and lowercase issues involving the host name. Also it is possible that on the PC the name has an underscore(_) where as on the Unix system it has a hyphen(-). Therefore, if you do have problems recognizing a particular client, add an alias in the /etc/host file or on the domain name services on the server. As well do not use space in names.
The quickest way to determine if a connection which is properly authenticated can remain between a Backup Professional server and a client is to go to the client section of the setup. This is through [Setup->Clients] in the Administration utility. First select the client which is giving you problems and then click the [Save] button. When you do this, the server connects to the client and requests some information such as the type of the client and the CPU type. Full authentication is done at this time and, if there is a problem, it is reported to you in plain English. For example, if the server cannot ping the client it is stated. Also, if the server is able to ping the client but cannot connect with the BP server agent of the client this is also stated.
A common problem on clients is that the services have not started. In most cases, the services are started during the installation phase of Backup Professional client. However, in some case this fails and you must reboot the client in order for the services to start. Either way clicking [Save] in the client tells you if you can properly connect to a client. In the character interface this done by going into the setup section of the menu system and editing a client record but not making any changes but the subsequently making this permanent. Any problems connecting to the client are reported in plain English.
In addition to the above there is another way to test for effective networking connectivity. You can use the X interface and go into backup facility and select your client, then select files to include and/or exclude. Choose selective backup and select the files to include. You should the message Connecting to client and should be able to view the files on the to client. If you cannot do this then there is definitely a problem connecting to the client. It is more than likely a network problem or the BP agent is not running on the client.
9.4.1 Firewalls
You may have connection problems performing a backup or restore if the BP server and client are separated by a firewall or router. This error is most commonly recognized by the Task Monitor message "No response from client". In this instance, a backup record is not generated and you only see this message on the Task Monitor or in a schedule summary.
The firewall must allow the server to connect to the client on the control and data ports and visa-versa. It also has to allow the client to connect to the server on the control port. By default, the control port is 1743, and the data port is dynamic.
When separated by a firewall, you will want to use a fixed data port so that you can easily build rules to allow BP connections. Select an unused port on the server by looking at /etc/services (on Unix). A good guess would be 1745. For historical reasons, 1744 causes the client to use a dynamic port. Add this value to the data item of the Configuration section in $BPDIR/bpinit/master.ini on the server and on the client.
You then need to build firewall/router rules to allow connections to the fixed data and control ports. Once completed, and you have ensured the previous networking solutions in this section have been performed, it should be possible to make a backup or restore connection.
9.4.2 NAT Support
Backup Professional version 1.5.2 and higher supports Network Address Translation (NAT). This is quite useful if you have a client machine outside of the firewall. Typically, the server has an internal IP address in the 192.168.x.x, 172.16.x.x class and yet when it connects to the client, the address is changed by NAT to a true Internet address.
NAT support is automatically detected for internal addresses starting with 192.168.x.x, 172.16.x.x, 169.254.x.x and 10.x.x.x. For other addresses, you can force NAT use by setting the ForceNAT=Yes in the [Configuration Options] section of the master.ini file.
9.4.3 Slow Network Connection
You might see one client that has a much slower network connection to the server that other clients. First you should check the TCP/IP receive buffer size on the BP server. You can check the man pages for ifconfig and inconfig for further information. Second, you can tune the packet size BP uses to send data across the network. This is the NetPacket setting in the Configuration Options sections of the Initialization file
For backups, this setting must be adjusted on the client machine. This sets the amount of data in bytes that the BP agent sends at one time through the network. The default value for this setting depends on the operating system type. You should try both lower and higher values as the optimum setting is dependant upon many factors such as CPU speed, network card type, timing issues, version of the operating systems, type of drivers, etc. Generally the optimum value is between 512 and 32768.
For restores, you can set the same option in the initialization file (master.ini) on the server. Keep in mind, server changes can have profound effects and could affect other clients. So testing with other clients should be done if server changes are made.
9.5 Tape Device
Tape problems can be caused by anything from bad connections, dirty tape heads, worn out tapes, to SCSI bus problems. By far the most difficult of these is SCSI bus problems. These don't occur often, but when they do they pose a considerable effort to track down. If you try the solutions proposed in the following sections with no success, try reading our SCSI white paper. You can find the document on our web site at http://www.unitrends.com.
9.5.1 Device Busy
You may see backups failing because the device is busy. You may not see any activity on the device and know that the device is not really busy. In this case, the Backup Professional database understanding of the device's busy status is different from its true status. This can happen from aborted processes or system panics while backups are running. The first step is to get out of all possible menus that involve Backup Professional, reenter these menus, then shut down tasker and restart it. When tasker starts up, see if there is truly a process using the device. If not, it resets the device status and backups can proceed.
If this fails, you should go into the device's section of the menu and click the option that says reset the device. This resets the device status and at this point Backup Professional starts performing backups and/or schedules to this device.
The next step is to test the tape. The test tape performs a variety of options of the device including writing tape labels, file set labels, and sample data-streams. It then positions to each of these to be sure that everything is intact. If there is a configuration problem with your device it is usually be detected in this phase.
9.5.2 Tape Media Errors
Tape devices can experience problems with writing. We suggest that if you see tape write error in the log messages please clean the tape device with a fresh cleaning tape. Keep in mind that cleaning tapes are designed to be used only a limited number of times and must be changed periodically. Additionally, we have seen on some of the 4mm and 8mm drives where the cleaning tape needs to be used two or three times in a row to fully clean the heads. Also, we suggest trying a new tape to get better results.
If a tape encounters a media error while writing data, the tape is marked full. Subsequent backups cannot be appended to this tape. Thus, if you have a single tape, all subsequent backup queued to this tape device will fail unless the tape is changed and a new one inserted.
9.5.3 Error Writing a Tape Label
Most often this happens because of a timing problem in the tape drives firmware. Backup Professional performs a fast seek to the very last dataset and feels the tape has arrived before it really has. In order to fix this, set AdvancedTapePositioning in the Initialization file for the tapes section to False.
9.5.4 Tape Drive is very Slow
It is possible that the default block size was set to a much lower value. Check the setting using [Setup->Configure->Devices]. A block size of 120 offers excellent performance. You must not exceed this value on Solaris if you want to use the Solaris Sun Solar Shield as the bootable system does not allow values beyond this. Otherwise, this value can be increased to 240 or even 480. On the RS6000 machines running AIX, values of 1024 offer optimum performance.
There are two types of block sizes. One is the high level block size which is what this section is referring to. It represents the number of 512 byte blocks sent to the tape drive in one write operation. The second is the low level SCSI block size which only applies if you have a SCSI tape drive. It represents the number of bytes the tape drive head uses. This should be 512 for quarter inch tape drives, 1024 for DAT drives, and 0 (variable) for every other type of tape drive.
Of course after any change in block size, you should test the tape. If it detects a problem with the specified block size, it suggests the proper block size to use.
9.6 Disk-To-Disk (D2D) Device
9.6.1 Not Enough Space To Create Device
You may not have enough space on your disk to create the D2D device you have specified. Make sure you are not putting in a capacity amount greater than the disk space available.
Verify the D2D=x setting in your license feature string (see "How Is It Licensed?" on page 91) to confirm that you have disk device support for the aggregate capacity of disk devices you are attempting to create.
Finally, when creating the D2D device, make sure you use the trailing slash (/) when inputting the path name to the D2D directory (see "Setting Up Disk-to-Disk Devices" on page 66).
9.6.2 Backups Failing Because D2D Device is out of Space
Your D2D device may not be large enough. By default, the software will not purge a last master or last incremental. If your D2D device is not large enough to hold two masters and their associated incrementals, the backup will fail because the purging will not be able to free up enough space for additional master backups.
You may require the device to hold many master backups and their associated incrementals. This will be determined by the number of versions required to be on-line at any one time. Your D2D device should be sized accordingly.
You can view your purge history by looking at the .purge_log located in the disk device directory. This is a hidden file, please note that the file name is .purge_log.
9.7 Operating System/Filesystem Errors
9.7.1 Out of Filesystem Space
Operating System/Filesystem errors are one of the most difficult problems to diagnose. The reason is, is there is no specific reproducible system that these generate. Probably the most common cause of failure is running out of disk space on the system. Backup Professional attempts to detect this problem by assuring there is at least 30 MB of free space on the filesystem that contains Backup Professional before the backup is run. This can be a reason why a backup fails. It is not tasker who makes this determination but is the actual backup.
Operating system problems can include missing system files and/or a corrupt filesystem. Some of these problems can be detected by generating a technical support fax sheet. During the generation of the fax sheet all system files that were utilities that Backup Professional uses are checked for their existence, if there is a problem this is reported. Having the BP database on a NFS partition on a slow NFS server or slow network connection can cause a variety of spurious errors and even sporadic out of space error messages.
9.7.2 Locked Files Errors
By default Backup Professional will not backup files that are locked by the system or by other applications. Please review the instructions on how to suppress files in use warnings for specific files in the section titled "Skip In Use" on page 218.
9.7.3 Setting the Debug Level
The general approach to detect system problems is to increase the debugging level of the Backup Professional utilities involved. You can do this through the [Setup->Configuration] section of the Administration utility and go into debugging and set the debug level from 0 to 3. The highest debug level is 5 but usually this produces a large volume of information. Only use this in extreme case as this can fill up the disk rapidly. Usually level 3 this gives the information that is needed.
Once you set the debugging level (which is the same as the log level) repeat the backup or restore request that failed. The most common log files can be viewed direct from the user interface. These include the tasker log and the last server log. Other logs can be viewed by changing directories to $BPDIR/logs.dir and viewing bpserverd_xx.logfile or pertinent log file.
It may also be possible that you have a configuration error with the BP settings. Depending on the setting this can produce a variety of symptoms. All configuration settings are kept in the Initialization file $BPDIR/master.ini. The possible values for these settings are discussed in the appendixes. When you upgrade from one version to the other your previous settings are merged into the new settings.
The most common problem is a user makes a change to the settings for a particular tape drive. However, because each tape drive has its own settings and there are also a set of general tape settings which is a default for any newly created tape drive. Changes are often made to the general tape settings as opposed to these specific settings.
Therefore, it is suggested that you use the menu system to make changes to the configuration files rather than editing them directly with a system editor such as vi. If you do make changes using a system editor or vi be sure that you are in the section for the actual tape name as opposed to the section that says [tape commands]. The section that says [tape commands] are the general settings that are used as the default for any newly created tape device.
Also, it is possible that the system configuration settings for a profile and/or a default profile have been messed up. The profiles are kept in the directory $BPDIR/profiles.dir. Reviewing the actual profile for the client involved sometimes can be fruitful.
9.8 Human Error
Human error or human misunderstanding is often a source of problems. The most common problem is failure to read the messages in the Task Monitor. The classic situation is for whatever reason the tasker stops running, in the tasker menu message box there is a message that says "you must start tasker from the routines menu". This means that the tasker program which schedules all backup and restore activities is simply not running. Therefore, you might have a task queued in the table that will not start until tasker starts. At times, another user with root power may have stopped tasker for some other purpose. Either way, you must use the Routines menu to start tasker and then proceed.
Another human error is failure to properly see the error messages on a backup or verify that failed. If a backup or verify fails there are several ways you can determine the reason. If you are in the X interface, go into the Backup/Restore history and select the particular backup or verify from the calendar. This shows a large display with summary information such as the number of files backed up and so forth. In the X interface there is a window in the middle which sometimes can be smaller than it should be, depending on the display. It may show one or two lines of log messages. In this case, enlarge this window and scroll down to the bottom of the window and you see the exact reason for the failure.
9.9 Avoiding Possible Database Problems
One other problem with databases is the usage of multiple instances with the user interface. For example, you may be running the character interface and the X interface at the same time. Or you may have several instances of the X interface running at the same time. Although this should be supported without problems, not a lot of testing has been done in terms of every possible combination. Each interface has certain database files open for reading and/or writing and it is possible that some combination could create or exacerbate an existing problem. Therefore, it is suggested that if you suspect a database problem get out of all instances of Backup Professional programs and then re-enter the one you need to reproduce and/or troubleshoot the problem.
9.10 Error in Software
This can be suspected if you see the word PROC ABORT in the task table. PROC ABORT means that a backup or restore process was running but did not have a clean exit or even any type of exit at all. This could happen if some other user killed the process and/or if there was a system problem and it generated a core file. You can detect this by looking for a file called $BPDIR/core. If you see this file please contact our technical support staff.
9.11 Licensing
If you do not have the proper license to handle different features you can experience problems. See "License Management" on page 90 for information on viewing your license. The following products/modules require special licensing features enabled:
· Jukebox Slots
· Sun Solar Shield Server
· Sun Solar Shield Clients
· SCO UnixWare/OpenUnix 8 Air-Bag
· Enhanced Open File Module
· PC ParaChute
· ParaChute 2000 Server
· BP DataSweep
· Oracle Module
· Microsoft Exchange/Informix/Sybase/SQL Module
For example, the use of a jukebox requires a jukebox module and license for the proper number of slots. Also usage of the Sun Solar Shield for Solaris and other systems requires a proper entry in the license table. The PC ParaChute also requires proper entries in the license table.
Select the [Misc->License Management] menu from the Administration utility. From there, you can view the license and if there is a major problem it is stated in plain English. If there is a minor problem, such as you not having the proper license string for the particular module you wish to use, this can be determined by looking at the feature string of the license. Please refer to the license section of this manual to determine the proper feature string that must be present in order to use certain modules.
9.12 Scheduling Issues
Sometimes there are problems with a schedule starting or a schedule is run that is different than you expect. Other times the scheduler does not switch jukeboxes in a way that may be desired. Most all of these instances are a case of misunderstanding between the user and Backup Professional. The first step is to generate a schedule report. This reports shows you exactly when each client will run, what slots are used (if using a juke box) and the device used as well as reporting options that are used for that schedule. Second, be sure that the device status is not busy and then review the schedule in the scheduling section of the menu. Be sure to check all the profiles that are run for each of the clients to be sure these are what is desired. Following this, you can launch the schedule immediately instead of waiting the desired time to actually test a schedule and be sure it is running while you are there watching. This can be done from the setup and configure section of the schedule by pressing the [Start] button. Keep in mind, if you launch a schedule for testing purposes and then cancel it, you should reset the schedule using [Reset] so the scheduler will launch the schedule again at the proper time.
There is a report that can be run which generates a list of all the clients in a given schedule and which clients are backed up to which slot in the jukebox. This is available from the reports section of the menu system. Please generate this report and read it carefully to be sure that it corresponds to what the desired actions are.
Keep in mind, that the current version of Backup Professional enforces that a backup for one client be contained in full on a tape. This is because if tapes are recycled with different intervals and retention periods you do not end up splitting a backup across two different tapes. Because of the this, the scheduler, when it encounters a given client, needs to switch to the next slot in the jukebox. This is determined by a check box in X interface and in the character interface by a yes/no answer. If you select this option, when this particular client is run in the schedule the jukebox switches to the next slot. The next slot that it will switch to is determined by your configuration file. For example, if the name of the drive is juke1 the configuration file is found in $BPDIR/bpinit/juke1_slots.cfg From this file you can determine which clients are backed up to which tapes.
If you need want to switch tapes on a server backup (either with or without a jukebox), you use the $BP_BINDIR/span_tapes utility. This launches a full master backup of the server and uses the designated slots of the jukebox for the backup. It automatically switches tapes and will split files across tapes if necessary.
9.13 Client Side Problems
Client sided problems can be further elucidated by reviewing the log files on the client. These are kept in $BPDIR/logs.dir on Unix systems and C:/PCBP/LOGS.DIR on windows systems. You will see a file called client.stderr which contains the output from the last client session. Additionally, it is useful to run the protocol test of the client. This tests the connectivity to the server and does a series of protocol requests including transferring data.
9.14 Task Queue Problems
Most task problems involve network or database solutions. Please review "Database" on page 124 and "Network" on page 125.
9.14.1 Cannot Submit Task to Server
This is a network connectivity or naming problem. First, try the solutions proposed in "Network" on page 125. Make sure the client and server names are correct for the request. Check the names from the Backup/Restore utilities or from the scheduler configuration depending on how the task was started. A naming problem can also exist when the server cannot authenticate the request for a client. This can happen when the client is configured into BP using an alias name and DNS will not return aliases for an IP address. To solve this, simply reconfigure the client from the Administration utility using its full hostname.
You must also make sure the client is enabled in the BP configuration. You notice this and other types of errors when carefully reading the backup messages for the failed task. Other types of errors include running out of disk space when creating log files in $BPDIR/logs.dir. If the above suggestions fail to solve the problem, consider rebuilding the jobs table from the Administration utility.
9.14.2 Task Sits in Queue - Nothing Happens
The most common cause of this is the user stops tasker and forgets to restart tasker. You should stop tasker and restart tasker. Sometimes, there was an error on the tape device and BP is trying to recover. If a user killed a BP process themselves, BP still feels the device is busy and cannot run other tasks. After a short interval (within 20 minutes) it realizes what happened and mark the device as not busy. Either way, stopping and starting tasker solves the problem immediately.
9.15 Backup Problems
9.15.1 Backup Times-Out
This is most likely some form of network problem such as the network is down or the client cannot start the BP client service. First, check the network. Make sure the client can be reached from the server and visa-versa. You can use ping as a minimum. You can also try to save the client configuration from the Administration utility.
This problem can also occur when the client drops the connection because the client service was interrupted or the client shutdown while servicing a BP task. Make sure permissions on the client service utility ($BPDIR/bin/bpclientd or bpserverd) are executable and try the task again.
9.15.2 Backup is Cancelled
This is due to the BP service on the client ($BPDIR/bin/bpclientd) or server ($BPDIR/bin/bpserverd) failing to start. Make sure the permissions are executable and try again if not. Otherwise, check the task detail for more error messages.
Other reasons include network related problems and those encountered under the next three headings.
9.15.3 Backup Encounters Media Error on the Tape
This is due to a read/write error on the tape drive. This can be caused by dirty tape heads, worn-out tapes, reaching the end of tape, or SCSI bus problems. If you believe it to be a problem with the tape, try cleaning the tape drive with a cleaning cartridge (if applicable) or replacing the tape. We have seen tape drives require two consecutive cleanings before it is complete.
SCSI bus problems are harder to recognize. They are generally intermittent. It is pretty much the reason after all other solutions have failed. We see these problems mainly on PCs.
For this type of error during a backup, the tape is marked FULL. If you think that cleaning the tape solved the problem, you need to mark the tape APPENDABLE before you can add another backup to it. This can be performed from the Tape Knowledgebase in the Administration utility.
9.15.4 Backup encounters Full Tape
The tape had been marked FULL during a previous backup. This can happen when a tape media error is encountered ("Backup Encounters Media Error on the Tape" on page 138), or when the tape is actually full. If the tape is really full, insert a new tape and try again.
9.15.5 Backup Runs out of Space on the Tape
BP versions up to 1.2z when performing a backup and the end of tape is reached, the backup will complete and its status set to FAILED. Files backed up to this point are valid for future restores.
9.15.6 Backup Not Progressing
This is most likely due to a Level-2 lock. The backup must wait on a locked file when the Level-2 locking option is set. Cancel the task and try again with Level-1 locking.
9.16 Restore Problems
Restore tasks can encounter the same network connectivity errors as backup tasks. See "Backup Problems" on page 137 for reasons and solutions.
9.16.1 Cannot See the Files I Want
When selectively restoring from a backup, make sure the backup has actually completed and that you are not trying to restore files before the database has been updated. Make sure that you are viewing the backup for the proper client. Also, scroll the files list to the right to see the full name of the files. Finally, if the backup you are viewing was in progress during a system crash that you later restored, only the backup record exists in the database and no files are listed.
If these solutions did not solve or explain the problem, consider rebuilding the database.
9.16.2 No Files were Restored
This can happen when Fast seek does not work because it over-calculated the position in the backup. Try setting TrimBlocks in the tape section of the initialization file to a larger value and try again. In the initialization file for BP, each configured tape has a section specified by the tape's nickname. See "Modify Initialization Files" on page 88. Alternatively, you can set the QuickSeek option from YES to NO in the same section.
9.16.3 Files Restore Slow Using D2D Device
When a Disk-to-disk device is created a device properties section is placed in the server master.ini file (see "Disk-to-Disk" on page 342). This file can be edited via admin->setup->settings->disk device name. To improve the performance of the restore you can increase the size of the TrimBlocks setting. By default this number is set to 10. Increase this number to a much higher number, for example 3000.
In some cases, restore speeds can be increased by turning off the QuickSeek option in the same settings area. Do this by changing Yes to No. Test this setting to assure improved performance.
9.17 Bare Metal Plus Problems
9.17.1 Hard Disk not detected
The first thing to do is to go to the Utilities Menu and select Test PC Parachute. Check to see whether the test for the hard drive is a success. This might fail when a you are trying to do a Bare Metal backup of a hard drive that is attached to a SCSI controller and whose ID is less greater than that of another SCSI device attached to the same controller. For example,. you might have a Zip drive and a Hard drive attached to the same SCSI controller. If the Zip drive is of a lower ID then the zip drive is considered to be the main drive to backup. In this situation you might want to reconnect the Zip drive to have an ID greater than that of the hard drive that is being backed up. If you have a SCSI RAID controller and the Bare Metal backup/restore is having a problem in detecting the drive, then when the client is booted into the Main Menu go to the Utilities Menu and get to the Invoke Shell option. Check the contents in the /proc/scsi/scsi file to see if the SCSI controller was detected. If the contents denote that there are no SCSI devices attached then you could contact the Support Group for additional help.
![]() |
![]() |
![]() |
![]() |