recovery of files

[maros]

Hello

I need to recover files from an 8GB DDS2 data cartridge. The data on the tape is structured according to project directories. While I am able to recover some of the project directories I am not able to recover all of them despite the fact that when I list all files and directories on the tape - I can see in /var/tmp/index all project directories and files. I have used SAM to back-up (device: /dev/rmt/c2t3d0DDS) and also to recover. SAM does not report any problems - it just "pretends" that the directories are not there and prompts me for another volume.

Thanks.

Marian

[Paula J Frazer-Campbell]

Hi

The Index tells you what was backed up during that backup session and can cover multiple tapes. If sam is asking for another tape then the backup covered at least two tapes.

Paula

[maros]

Paula

That's absolutely okay. I used 2 tapes to back-up. The problem is that I know that a file that I am absolutely positive that is on the first tape is not recovered. Despite this, I even tried to supply the second tape - SAM did not find the file on the second tape either plus it prompted me for next tape although I used only 2 of them durinmg the back-up. The back-up operation was completed successfully (I did it manually via SAM - not as a scheduled job).

Best regards

Marian

[Bill Hassell]

frecover -I /var/tmp/index -f /dev/rmt/c2t3d0DDS

will make a complete copy of the index from the first tape. If the file you need is shown in the index file then it was attempted to be saved during the backup. However, it vitally important to look at the SAM logfile to see if there were errors during the backup. If the file was locked during the backup, the filename would be listed but not backed up and an error generated in the fbackup logfile. The index file is created before the backup takes place so there is no way remove or mark entries in the index at the front of the tape. In a multi-tape backup, the entire index is copied to each tape and then markers are created that indicate which files are contained on previous tapes. If you put the last tape in the drive and then restore the specific file, frecover will ask for a previous tape (volume) if the file was saved on a previous tape. However, if the backup required 3 tapes and you only have 2, frecover will search to the end of the last tape you have and ask for another. This means that the backup was not completed correctly. Again, this would be shown in the backup logfile.

[maros]

Bill,

Thank you but there were no errors during the back-up and I actually managed to recover everything from the tape. The problem seemed to be that I was trying to recover the files to a different machine than to which the tape driver was physically connected. After attempting to recover the directories and files to the machine to which the driver was physically connected I had no problems to recover all the data. Allow me to ask you a question. I have been using 8GB DDS2 tapes. However, for backup and recovery I have been using the /dev/rmt/c2t3d0DDS device file, while I have available also /dev/rmt/0m and /dev/rmt/c2t3d0BEST. I know that I can create my own device file - but is there any preference which of the three above mentioned device files I should use for the back-up and consequently for the recovery? Thanks

[Bill Hassell · Accepted solution]

It's important to note that there are no 8Gb DDS2 tapes. This is a rather pervasive stretch of marketing information. A DDS2 tape is 4Gb, also known as native capacity. That's all that will fit on the tape, period. Now if the data is compressed, either before storage to tape or by using compression inside the tape drive, *SOME* data may not occupy as much space. For example, if you use the prealloc command to create a 16Gb file (it will take a long time) you can then save it to the 4Gb tape using a compression device file ('best' density) and have a large amount of tape unused. The reason is that prealloc creates a file full of zeros which has enormous compressability. For instance, a 10Mbyte file compresses to only 6Kbytes! That is a compression ratio of 1500:1 so your 4Gb DDS2 tape could hold 3,000 Gbytes of this type of file. And if the file was 4.1Gbytes of truly random data (therefore uncompressable), your tape would not have enough capacity. But with 'average' data, the compression ratio is approximately 2:1 which is where tape manufacturers get their numbers. I never assume I'll get more than about 1.5:1 ratio (or 6Gb) for typical Unix opsystem data. Databases will have wildly varying compressability--an almost empty database could compress to 100:1, but an almost full database may not compress at all.

AS far as the device files, the actual name is unimportant. What you want is the 'best density'. Now DDS (and DLT) drives have only one density but they do have ability to turn on/off the compression feature in the drive. To decode whether the device file enables this feature, use lssf as in:

lssf /dev/rmt/*

The lssf command knows all about the minor number bits in the device file (which controls compression, rewind, etc). You'll see that about half of the device files are 'best density' so use one of those device files for your backup. The other options such as rewind, at&t/berkeley are chosen based on how you create your backups. For fbackup, rewind options are not important as the tape is explicitly rewound at the beginning of the job.