[Veritas-bu] To ensure overwrites
2000-11-15 12:42:42
It would work well especially if your partial write was of a random lenth of
time. Having it encrypted and having no accurate idea how far in you are
would render the info unrecoverable (IMHO). Add MPX, encryption and partial
overwrites and I don't think anyone would get anything off of it.
-----Original Message-----
From: Mark Smiles [mailto:msmiles AT lucent DOT com]
Sent: Wednesday, November 15, 2000 10:10 AM
To: KevinB AT paccessglobal DOT com
Cc: bbakh AT veritas DOT com; veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] To ensure overwrites
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
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [Veritas-bu] To ensure overwrites, (continued)
- [Veritas-bu] To ensure overwrites, W . Curtis Preston curtis
- [Veritas-bu] To ensure overwrites, Joshua Fielden jfielden
- [Veritas-bu] To ensure overwrites, John_Wang
- [Veritas-bu] To ensure overwrites, David A . Chapa david
- [Veritas-bu] To ensure overwrites, John_Wang
- [Veritas-bu] To ensure overwrites, KevinB
- [Veritas-bu] To ensure overwrites, Bob Bakh bbakh
- [Veritas-bu] To ensure overwrites, Blake , Delroy delroy . blake
- [Veritas-bu] To ensure overwrites, KevinB
- [Veritas-bu] To ensure overwrites, Mark Smiles msmiles
- [Veritas-bu] To ensure overwrites,
McMurphy , Tim Tim . McMurphy <=
- [Veritas-bu] To ensure overwrites, Jonathan Meyer jmeyer
- [Veritas-bu] To ensure overwrites, McMurphy , Tim Tim . McMurphy
- [Veritas-bu] To ensure overwrites, John_Wang
- [Veritas-bu] To ensure overwrites, Joshua Fielden jfielden
- [Veritas-bu] To ensure overwrites, John_Wang
|
|
|