DLT & LTO tape initialization

[Brad Marks]

Hi. I have a bunch of old backups on DLT & LTO tapes that I want to avail to different departments at my company.
I need to be very certain that there is NO WAY for anyone to retrieve data from these tapes.
I ran a DLT and an LTO through our degasser and now neither tape will load. Why is that?

Is there a unix (I'm running HP-UX 11.i) command that will erase all existing data from a tape? At first I thought of simply backing up /dev/null, but realized that, just because I couldn't see it, the data was still on the tape.

Any help would be greatly appreciated.
Brad

[A. Clay Stephenson]

Generally because the degausser does not generate a sufficiently strong B field.


https://selfservice.talisma.com/display/2/index.asp?c=18&cpc=TJVN0Y442nJq41250384h8TsoO3RuDHpbReVI&cid=11&cat=&catURL=&r=0.7927667

[James A. Donovan · Accepted solution]

Just backup /dev/zero to your tape drive

If you don't have it...
# mknod /dev/zero c 3 0x000004
# chown bin:bin /dev/zero
# chmod 666 /dev/zero

This will write the null character (\000) over and over again onto your tapes, effectively erasing whatever used to be there.

[A. Clay Stephenson]

There's only one thing wrong with writing /dev/zero. How much compression do you get with an infinite stream of 0's? Reading from /dev/random or /dev/urandom would make much more sense. However, if the tape will not load, how are you planning to write anything to it.

[Brad Marks]

A.Clay, I only gegaused one of about 70 tapes, so I've about 69 to initialize.

I did find /dev/zero on my system, but neither /dev/random or /dev/urandom. What are they?

Thanks!
Brad

[A. Clay Stephenson]

You install the strong random number generator (free):

http://h20293.www2.hp.com/portal/swdepot/displayProductInfo.
do?productNumber=KRNG11I

For your purposes /dev/urandom will be better. It's not as random but it will be faster.

[Bill Hassell]

There are several answers to the desired result. The first is: NEVER DEGAUSS MODERN TAPES!!! This was common practice with 1/2" reel tapes 20 years ago, but today, DDS, DLT, LTO, AIT, etc tapes may contain preformatted information at the front of the tape. Degaussing the tape detroys the data, or only partially neutralizes the tape and it becomes worthless (as you have seen).

The second is that modern tape drives have a hardware-enforced end-of-data feature. Once you record anything on the tape, when you rewind or pop-out the tape, a special marker for the end of data is written and cannot be bypassed. So, simply cat'ing a short file to the beginning of the tape renders all old data unreadable. Now having said that, there are (expensive) companies that can recover data past this marker. They have specially engineered drives to perform this task. All you need is lots of cash.

However, as many companies have discovered, backup tapes are a SEVERE security risk in that most are not encrypted. Using classic Unix tools for critical data is just asking for problems. Even fbackup is risky because it has no encryption option. Most commercial backup programs have encrytption as an option and this should be the required protection level. In that way, a misplaced, lost or stolen tape has no value. And even if all the operators promise to run the data overwrite script on every tape, somone will forget.

[Brad Marks]

I executed the command "dd if=/dev/zero bs=8000k of=/dev/rmt/2m" and it took > 24 hours to complete!

Is there a means to limit the amount of data that is written to the tape instead of waiting for EOT to occur? I need to overwrite a backup of only 75 GB of data.

I have downloaded KRNG11i, and plan to install it this weekend.

Thanks,
Brad

[A. Clay Stephenson]

Well, when you send a stream of zeroes to a device that does compression, what do you expect? I am going to guess that a big bunch of 0's compresses very well so that very little data are written to tape per unit time. The random device will help.

Here's one method leveraging Perl to generate random numbers (not as fast as /dev/urandom but a damn sight faster than an infinite stream of compressible 0's):

perl -e 'while (1) { print rand(255); }' | dd ibs=16k obs=1024k count=4915200 of=/dev/rmt/1m

If I've done my ciphering correctly then 4915200 16k chunks = 75GB. Now that does not mean that your entire backup will be overwritten because the compression likely is quite different so you may wish to write more to be sure. Man dd for details.

[Brad Marks]

Once I have the strong random number generator installed, should the dd command look like this? "dd if=/dev/random of=/dev/rmt/1m" using the default ibs/obs of 512, or should I still include the "ibs=16 obs=1024" portion? I admit that even after reading the man page, dd remains somewhat mysterious to me.

[Brad Marks]

I forgot to inlcude 'count=146484'. Is 146484 (75000000/512) about right?

[A. Clay Stephenson]

If you do a man 7 random, you will find 2 important things: 1) You should be using /dev/urandom because while quite so random as /dev/random, it does not block. 2) The maximum read size is defined by RNG_READMAX (256) so that limits your input block size.

dd if=/dev/urandom ibs=256 obs=1024k of=/dev/rmt/1m

[A. Clay Stephenson]

The dd argument "count" is always specfied in ibs (input block size) quanta; the default is 512 bytes unless overriden by the ibs=xxx or bs=yyy arguments.