Why not just encrypt the data in the first place, then partially write over?
Mark

KevinB AT paccessglobal DOT com wrote:

> Your comments are based on technical capability not on business procedure.
> In a business environment, business procedure drives IT, not the reverse (as
> it should be).  In an optimal situation IT should help with the business
> procedure where either IT is impacted or when IT can add value in the
> procedure.  If business procedure is to destroy the data versus render the
> data practically inaccessible then a procedure to erase or deguass the tapes
> is the only option.  If IT has some influence, they could present the case
> that if the tape is partially overwritten then there is only a 1 in 10**XXX
> chance of someone accessing the data and therefore for practical purposes
> (and cost savings) is valid and thus justify a change in the procedure.
>
> This does make it IT's responsibility to make sure that the intended level
> of security is met as technology changes.  Sometimes overkill is easier than
> being practical.
>
> -----Original Message-----
> From: Bob Bakh [mailto:bbakh AT veritas DOT com]
> Sent: Tuesday, November 14, 2000 8:20 AM
> To: KevinB AT paccessglobal DOT com; John_Wang AT enron DOT net
> Cc: curtis AT colltech DOT com; veritas-bu AT mailman.eng.auburn DOT edu
> Subject: RE: [Veritas-bu] To ensure overwrites
>
> Unless the FBI and the NSA have better technology than the Private sector,
> like all that alien stuff they have in Roswell.  There is no way to retrieve
> data off a DLT 7000 tape that has been partly written over, I know I've
> tried.
>
> AIT I think is in the same boat, no one has cracked the compression on it.
>
> As far as I know.  That is why in the first generation of DLT 7000 you had
> enough trouble reading a tape drive to drive.  AIT has been a little more
> reliable in that case, but I don't think getting passed a EOF mark will give
> you the keys to the kingdom.
>
> Bob
>
> -----Original Message-----
> From: KevinB AT paccessglobal DOT com [mailto:KevinB AT paccessglobal DOT com]
> Sent: Friday, November 10, 2000 1:14 PM
> To: John_Wang AT enron DOT net; KevinB AT paccessglobal DOT com
> Cc: curtis AT colltech DOT com; veritas-bu AT mailman.eng.auburn DOT edu
> Subject: RE: [Veritas-bu] To ensure overwrites
>
> I have not used the mt erase command but the assumption would be that it
> would be more efficient.  This is assuming that, like most of the mt
> commands, that mt is giving the tape drive the erase command.  The drive
> then performs the work.  At a minimum this would eliminate the server work
> and network traffic associated with a dd solution.  You also would not have
> to worry about streaming your bit pattern fast enough to keep the drive
> max.ed.  The Quantum manual for a 7000 DLT says the erase command can take
> well over an hour (this implies less than 2 hours).
>
> -----Original Message-----
> From: John_Wang AT enron DOT net [mailto:John_Wang AT enron DOT net]
> Sent: Friday, November 10, 2000 12:54 PM
> To: KevinB AT paccessglobal DOT com
> Cc: curtis AT colltech DOT com; veritas-bu AT mailman.eng.auburn DOT edu
> Subject: RE: [Veritas-bu] To ensure overwrites
>
> Hello
>
> OK, so we all agree, a bplabel still leaves the data accessible to whomever
> can
> forward over an eom mark.   dd'ing a pattern is relatively straightforward
> but
> can take some time depending on how much needs to be overwritten.   What
> about
> "mt erase", any comments?
>
> Regards,
> John I Wang
> Sr. Systems Engineer
> Steverson Information Professionals
>
> ---
> Enron Broadband Services
> Enron Building 1472c
> ph (713) 345-4291
> fax (713) 646-8063
>
> |--------+------------------------>
> |        |          KevinB@paccess|
> |        |          global.com    |
> |        |                        |
> |        |          11/09/00 10:27|
> |        |          AM            |
> |        |                        |
> |--------+------------------------>
>   >-------------------------------------------------------------------|
>   |                                                                   |
>   |       To:     curtis AT colltech DOT com, John Wang/Contractor/Enron     |
>   |       Communications@Enron Communications,                        |
>   |       veritas-bu AT mailman.eng.auburn DOT edu                           |
>   |       cc:                                                         |
>   |       Subject:     RE: [Veritas-bu] To ensure overwrites          |
>   >-------------------------------------------------------------------|
>
> I believe you would also want write a script that dd'ed a bit pattern over
> the tape.  The question is, which is going to be slower, the dd process or
> the degauss/relabel process.  From an automation perspective I think the
> relabel overwrite method would be easier to implement.  If the risk of data
> theft from backup tapes is that critical then perhaps the cost of several
> new drives for this would be justified.
>
> -----Original Message-----
> From: W. Curtis Preston [mailto:curtis AT colltech DOT com]
> Sent: Wednesday, November 08, 2000 4:49 PM
> To: John_Wang AT enron DOT net; veritas-bu AT mailman.eng.auburn DOT edu
> Subject: Re: [Veritas-bu] To ensure overwrites
>
> I would:
> 1. Create a pool just for those backups
> 2. Force those backups to that pool (class definition)
> 3. Relabel tapes older than a week.  (Relabeling them renders them
> unusable.)
>
> You DON'T want to degauss tapes if you plan on reusing them, depending on
> the drive.  A degaussed tape returned to a DLT drive will take about 2
> hours to get ready for use.  (It has to rewrite the headers on boths ends
> of the tape.)
>
> At 03:13 PM 11/8/00 -0600, John_Wang AT enron DOT net wrote:
>
> >Hello Everyone
> >
> >We have a political requirement to ensure that certain backup images do not
> >exist after a weeks time.   Any way to ensure that a tape gets overwritten
> as
> >soon as possible?   Can I prevent multiple images from being stored on
> >tapes in
> >a specific pool? i.e.: prevent multiple expiry dates on a given
> >tape.   Short of
> >removing expired tapes for degaussing, which will be done if that's the
> >solution, what can be done to meet this requirement?
> >
> >Comments, ideas?
> >
> >Regards,
> >John I Wang
> >Sr. Systems Engineer
> >Steverson Information Professionals
> >
> >---
> >Enron Broadband Services
> >Enron Building 1472c
> >ph (713) 345-4291
> >fax (713) 646-8063
> >
> >
> >_______________________________________________
> >Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> >http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
> ---
> W. Curtis Preston, Principal Consultant at Collective Technologies
> Email: curtis AT colltech DOT com                (Best way to contact me)
> Work : 408 452 5555                       (Leave a message.)
> Pager: 800 946 4646, pin#1436065        (If urgent.)
>
> Tap into the Collective Intellect (TM): http://www.colltech.com
> Backup & Restore resources:        http://www.backupcentral.com
>
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu