Problem with tar piping through openssl to tape

[Andrew Kaplan]

A colleague and I wrote a perl script that is designed to change to a specific directory that contains upwards to seventy subdirectories, and once there proceed one at a time to tar the subdirectory, encrypt the newly created tar file, and then tar to tape media the encrypted tar file. Once that was done, the script would go back to the source directory, remove the tar and encrypted tar files, and repeat the process on all additional subdirectories in the same location.

The command syntax that is used to accomplish this is the following:

###############################################
$cmd= "(cd $path; tar -cvf - $_|openssl des3 -salt -k $password > $_.des3)";
print `$cmd`;
if ($first){
$cmd= "(cd $path; tar -cvf $device $_.des3)";
} else{
$cmd= "(cd $path; tar -rvf $device $_.des3)";
}
$RC=$?;
print `$cmd`;
$cmd= "(cd $path; rm $_.des3)";
print `$cmd`;
$first=0;
}
###############################################

During a testing of the script, indications were the above process completed successfully. There was write activity on the tape drive, and no errors appeared on-screen.

After the session was completed, the tape media was rewound, and the tar -tvf command was ran to list the contents of the tape. The output indicated that the first directory was backed up successfully, but there was no indication of any additional directories being backed up to tape. The mt -f fsf 1 command was used to go to the end of the archive, and the tar -tvf command was reran to see if there were additional archives to the initial one on the tape, but there was no indication of any.

One thought that came to mind was to remove, or initially comment out, from the script the tar -rvf command, and rerun the script along with the follow-up tvf command. However, this did not appear to make any difference.

Does anyone have any ideas or suggestions? Thanks.

[Steven Schweda · Accepted solution]

What's "$device"? Is it rewinding or
non-rewinding?

[Andrew Kaplan]

Hi there --

Thanks for your reply. The item $device refers to a non-rewinding tape drive be it a dlt, superdlt, or LTO-4 device.

I did not include it in the initial posting, but the script prompts the administrator for the device path of the drive in question. One example would be:

/dev/rmt/5mn.

If people need to see the script in its entirety, I can attach it to a future response.

[Steven Schweda]

Looking at it again, "tar -r"?

http://docs.hp.com/en/B2355-60130/tar.1.html

says:

[...]
r

Add the named file to the end of the archive. The same blocking factor used to create
the archive must be used to append to it. This option cannot be used if the archive is a tape.
[...]


You're writing to a tape, right?

[Steven Schweda]

Is there anything in your script which
notices if a command fails? (Failure is not
an option?)

[Steven E. Protter]

Shalom,

I feel your methodology is overly complex.

Write to a simple file.

Use PGP (availabel at http://software.hp.com Internet Express) to encrypt the file.

Then transfer it to tape.

SEP

[Andrew Kaplan]

Hi there --

The writing is to tape, so right off the bat the -rvf command will have to be removed. One test that I ran had my commenting out the lines within the script that immediately follow the initial $cmd line to see if that made a difference, but it did not seem to do so.

I have a failure check later in the script that determine if the script completed successfully. It came back with an error code of 0.

As far as writing everything to a file, and then sending the file to tape, I can go that route if necessary, but that would require a separate directory in which to write the file. My hope is to avoid having to do that.

[Steven Schweda]

> I have a failure check later in the script
> that determine if the script completed
> successfully. It came back with an error
> code of 0.

Apparently, either your definition of success
differs from mine, or else that "failure
check" is ineffective.

[OldSchool]

as noted above...you can't use the "-r". you can write additional archives to the tape, provided that you did indeed use the non-rewind device. each archive will be a separate file on the tape.

The downside of that is that since each archive is a separate file on the tape, so you have to know its location and skip the appropriate number of file marks forward to access it, which can be messy to put it mildly.

[Andrew Kaplan]

Hi there --

It looks like I am going to have to go with the scratch directory approach where the encrypted files are initially created, and subsequently copied to tape. Although it isn't my first choice, at this point it looks like that will probably be the best avenue for success.