![]()
Testing Your Tape Drive With BaculaThis chapter is concerned with testing and configuring your tape drive to make sure that it will work properly with Bacula using the btape program.Specifying the Configuration FileStarting with version 1.27, each of the btape program requires a valid Storage daemon configuration file (actually, the only part of the configuration file that btape needs is the Device resource definitions). This permits btape to find the configuration parameters for your archive device (generally a tape drive). By default, it reads bacula-sd.conf in the current directory, but you may specify a different configuration file using the -c option.Specifying a Device Name For a Tapebtape device-name where the Volume can be found. In the case of a tape, this is the physical device name such as /dev/nst0 or /dev/rmt/0ubn depending on your system. For the program to work, it must find the identical name in the Device resource of the configuration file. See below for specifying Volume names.Specifying a Device Name For a FileIf you are attempting to read or write an archive file rather than a tape, the device-name should be the full path to the archive location including the filename. The filename (last part of the specification) will be stripped and used as the Volume name, and the path (first part before the filename) must have the same entry in the configuration file. So, the path is equivalent to the archive device name, and the filename is equivalent to the volume name.btapeThis program permits a number of elementary tape operations via a tty command interface. The test command, described below, can be very useful for testing older tape drive compatibility problems. Aside from initial testing of tape drive compatibility with Bacula, btape will be mostly used by developers writing new tape drivers.btape can be dangerous to use with existing Bacula tapes because it will relabel a tape or write on the tape if so requested regardless that the tape may contain valuable data, so please be careful and use it only on blank tapes. To work properly, btape needs to read the Storage daemon's configuration file. As a default, it will look for bacula-sd.conf in the current directory. If your configuration file is elsewhere, please use the -c option to specify where. The physical device name must be specified on the command line, and that this same device name must be present in the Storage daemon's configuration file read by btape Usage: btape [-c config_file] [-d debug_level] [device_name] -c <file> set configuration file to file -dnn set debug level to nn -s turn off signals -t open the default tape device -? print this message. Using btape to Verify your Tape DriveAn important reason for this program is to ensure that a Storage daemon configuration file is defined so that Bacula will correctly read and write tapes. It is highly recommended that you run the test command before running your first Bacula job to ensure that the parameters you have defined for your storage device (tape drive) will permit Bacula to function properly. You only need to mount a blank tape, enter the command, and the output should be reasonably self explanatory. For example: (ensure that Bacula is not running) ./btape -c /usr/bin/bacula/bacula-sd.conf /dev/nst0The output will be: Tape block granularity is 1024 bytes. btape: btape.c:376 Using device: /dev/nst0 *Enter the test command: testThe output produced should be something similar to the following: === Append files test === This test is essential to Bacula. I'm going to write one record in file 0, two records in file 1, and three records in file 2 btape: btape.c:387 Rewound /dev/nst0 btape: btape.c:855 Wrote one record of 64412 bytes. btape: btape.c:857 Wrote block to device. btape: btape.c:410 Wrote EOF to /dev/nst0 btape: btape.c:855 Wrote one record of 64412 bytes. btape: btape.c:857 Wrote block to device. btape: btape.c:855 Wrote one record of 64412 bytes. btape: btape.c:857 Wrote block to device. btape: btape.c:410 Wrote EOF to /dev/nst0 btape: btape.c:855 Wrote one record of 64412 bytes. btape: btape.c:857 Wrote block to device. btape: btape.c:855 Wrote one record of 64412 bytes. btape: btape.c:857 Wrote block to device. btape: btape.c:855 Wrote one record of 64412 bytes. btape: btape.c:857 Wrote block to device. btape: btape.c:410 Wrote EOF to /dev/nst0 btape: btape.c:387 Rewound /dev/nst0 btape: btape.c:693 Now moving to end of media. btape: btape.c:427 Moved to end of media We should be in file 3. I am at file 3. This is correct! Now the important part, I am going to attempt to append to the tape. btape: btape.c:855 Wrote one record of 64412 bytes. btape: btape.c:857 Wrote block to device. btape: btape.c:410 Wrote EOF to /dev/nst0 btape: btape.c:387 Rewound /dev/nst0 Done appending, there should be no I/O errors Doing Bacula scan of blocks: 1 block of 64448 bytes in file 1 End of File mark. 2 blocks of 64448 bytes in file 2 End of File mark. 3 blocks of 64448 bytes in file 3 End of File mark. 1 block of 64448 bytes in file 4 End of File mark. Total files=4, blocks=7, bytes = 451136 End scanning the tape. We should be in file 4. I am at file 4. This is correct! The above Bacula scan should have output identical to what follows. Please double check it ... === Sample correct output === 1 block of 64448 bytes in file 1 End of File mark. 2 blocks of 64448 bytes in file 2 End of File mark. 3 blocks of 64448 bytes in file 3 End of File mark. 1 block of 64448 bytes in file 4 End of File mark. Total files=4, blocks=7, bytes = 451136 === End sample correct output === If the above scan output is not identical to the sample output, you MUST correct the problem or Bacula will not be able to write multiple Jobs to the tape. === Write, backup, and re-read test === I'm going to write three records and two eof's then backup over the eof's and re-read the last record. Bacula does this after writing the last block on the tape to verify that the block was written correctly. It is not an *essential* feature ... btape: btape.c:387 Rewound /dev/nst0 btape: btape.c:597 Wrote first record of 64412 bytes. btape: btape.c:608 Wrote second record of 64412 bytes. btape: btape.c:619 Wrote third record of 64412 bytes. btape: btape.c:410 Wrote EOF to /dev/nst0 btape: btape.c:410 Wrote EOF to /dev/nst0 btape: btape.c:631 Backspaced over two EOFs OK. btape: btape.c:636 Backspace record OK. btape: btape.c:658 Block re-read correct. Test succeeded! === End Write, backup, and re-read test === === End Append files test ===If you do not successfully complete the above test, please resolve the problem(s) before attempting to use Bacula. Depending on your tape drive, the test may recommend that you add certain records to your configuration. We strongly recommend that you do so and then re-run the above test to insure it works the first time. Tips for Resolving ProblemsIncorrect File NumberWhen Bacula moves to the end of the medium, it normally uses the ioctl(MTEOM) function. Then Bacula uses the ioctl(MTIOCGET) function to retrieve the current file position from the mt_fileno field. Some SCSI tape drivers will use a fast means of seeking to the end of the medium and in doing so, they will not know the current file position and hence return a -1. As a consequence, if you get "This is NOT correct!" in the positioning tests, this may be the cause. You must correct this condition in order for Bacula to work.There are two possible solutions to the above problem of incorrect file number:
Incorrect Number of BlocksBacula's preferred method of working with tape drives (sequential devices) is to run in variable block mode. All modern tape drives support this mode, but some older drives (in particular the QIC drives) as well as the ATAPI ide-scsi driver run only in fixed block mode.Even in variable block mode, with the exception of the first record on the second or subsequent volume of a multi-volume backup, Bacula will write blocks of a fixed size. However, in reading a tape, Bacula will assume that for each read request, exactly one block from the tape will be transferred. This the most common way that tape drives work and is well supported by Bacula. Drives that run in fixed block mode can cause serious problems for Bacula if the drive's block size does not correspond exactly to Bacula's block size. In fixed block size mode, drivers may transmit a partial block or multiple blocks for a single read request. From Bacula's point of view, this destroys the concept of tape blocks. In order for Bacula to run in fixed block mode, you must include the following records in the Storage daemon's Device resource definition: Minimum Block Size = nnn Maximum Block Size = nnnwhere nnn must be the same for both records and must be identical to the driver's fixed block size. We recommend that you avoid this configuration if at all possible. In any case, as of version 1.27, it is not at all clear that Bacula's handling of these fixed block drivers really works. Ensuring that the Tape Modes Are Properly Set -- Linux OnlyIf you have a modern SCSI tape drive and you are having problems with the test command as noted above, it may be that some program has set one or more of the your SCSI driver's options to non-default values. For example, if your driver is set to work in SysV manner, Bacula will not work correctly because it expects BSD behavior. To reset your tape drive to the default values, you can try the following, but ONLY if you have a SCSI tape drive on a Linux system:become super user mt -f /dev/nst0 rewind mt -f /dev/nst0 stoptions buffer-writes async-writes read-aheadThe above commands will clear all options and then set those specified. None of the specified options are required by Bacula, but a number of other options such as SysV behavior must not be set. On systems other than Linux, you will need to consult your mt man pages or documentation to figure out how to do the same thing. This should not really be necessary though -- for example, on both Linux and Solaris systems, the default tape driver options are compatible with Bacula. Checking and Setting Tape Hardware CompressionAs far as I can tell, there is no way with the mt program to check if your tape hardware compression is turned on or off. You can, however, turn it on by using (on Linux):become super user mt -f /dev/nst0 defcompression 1and of course, if you use a zero instead of the one at the end, you will turn it off. You may also want to ensure that no prior program has set the default block size, as happened to Stev Allam, by explicitly turning it off with: mt -f /dev/nst0 defblksize 0 If you have built the mtx program in the depkgs package, you can use tapeinfo to get quite a bit of information about your tape drive even if it is not an autochanger. For example on my DDS-4 drive, I get the following: ./tapeinfo -f /dev/sg0 Product Type: Tape Drive Vendor ID: 'HP ' Product ID: 'C5713A ' Revision: 'H107' Attached Changer: No MinBlock:1 MaxBlock:16777215 SCSI ID: 5 SCSI LUN: 0 Ready: yes BufferedMode: yes Medium Type: Not Loaded Density Code: 0x26 BlockSize: 0 DataCompEnabled: yes DataCompCapable: yes DataDeCompEnabled: yes CompType: 0x20 DeCompType: 0x0 Block Position: 1141where the DataCompEnabled: yes means that tape hardware compression is turned on. You can see it turn on and off (yes/no) by using the mt commands given above. Also, this output will tell you if the MinBlock and MaxBlock are set for a particular block size. Note, Bacula will normally attempt to write blocks of 64,512 bytes, except the last block of the job which will generally be shorter. If your tape drive requires fixed block sizes (very unusual), you can use the following records: Minimum Block Size = nnn Maximum Block Size = nnnin your Storage daemon's Device resource to force Bacula to write fixed size blocks (where you sent nnn to be the same for both of the above records) Tape Modes on FreeBSDNormally Bacula should run with: mt -f /dev/nsa0 seteotmodel 2, and then according to what the btape test command returns, you will probably need to set the following:Hardware End of Medium = no BSF at EOM = yesbut you should start the test command without these records and then add them if it requests you to do so. Normally, you will also want mt -f /dev/nsa0 comp on to be set. Using btape to Simulate Bacula Filling a TapeBecause there are often problems with certain tape drives or systems when end of tape conditions occur, btape has a special command fill that causes it to write random data to a tape until the tape fills. It then writes at least one more Bacula block to a second tape. Finally, it reads back both tapes to ensure that the data has been written in a way that Bacula can recover it.This can be an extremely time consuming process (here is is about 6 hours), and you must have two blank tapes available. As this command is completely new, it is not well tested, and has considerable room for improvement, especially during the error checking in the read-back phase. To begin this test, you enter the fill command and follow the instructions. Tape Blocking ModesSCSI tapes may either be written in variable or fixed block sizes. Newer drives support both modes, but some drives such as the QIC devices always use fixed block sizes. Bacula attempts to fill and write complete blocks (default 65K), so that in normal mode (variable block size), Bacula will always write blocks of the same size except the last block of a Job. If Bacula is configured to write fixed block sizes, it will pad the last block of the Job to the correct size. Bacula expects variable tape block size drives to behave as follows: Each write to the drive results in a single record being written to the tape. Each read returns a single record. If you request less byte than are in the record, only those number of bytes will be returned, but the entire logical record will have been read (the next read will retrieve the next record). Thus data from a single write is always returned in a single read, and sequentially written records are returned by sequential reads.Bacula expects fixed block size tape drives to behave as follows: If a write length is greater than the physical block size of the drive, the write will be written as two blocks each of the fixed physical size. This a single write may become multiple physical records on the tape. (This is not a good situation). According to the documentation, one may never write an amount of data that is not the exact multiple of the blocksize (it is not specified if an error occurs or if the the last record is padded). When reading, it is my understanding that each read request reads one physical record from the tape. Due to the complications of fixed block size tape drives, you should avoid them if possible with Bacula, or you must be ABSOLUTELY certain that you use fixed block sizes within Bacula that correspond to the physical block size of the tape drive. This will ensure that Bacula has a one to one correspondence between what it writes and the physical record on the tape. Please note that Bacula will not function correctly if it writes a block and that block is split into two or more physical records on the tape. Bacula assumes that each write causes a single record to be written, and that it can sequentially recover each of the blocks it has written by using the same number of sequential reads as it had written.
|