Structured log file: there are three choices:
a) you don't have it (most likely nowadays),
b) you have it,
c) you don't know.
Ad a) - it was already discussed.
Ad b) - follow the procedures specific to this array
Ad c) - hire specialist who will know.
> Whether or not you consult an expert depends on how sure you need to
> be that the every last bit of your data has been completely and
> throughly erased or made unreadable.
Who is the expert? Can he walk on the water? You should be the expert,
because it is your dasd box. You are paid for that. (I mean generic
"you", just a person who works as stroage admin).
Of course if you work for CIA then you have more strict rules and more
rich set of tools.
Last but not least - regardless of logical and physical volumes, array
guts - when you throw it into the vulcano (most preferrably this one in
Mordor), then your data are safely and surely destroyd.
But I think we are talking about non-destructive, "good enough" methods.
Oh, regarding bad tracks - 1. There are no bad tracks on logical
volumes. 2. bad tracks/sectors/areas on physical disk are ...bad and in
most cases cannot be neither read nor overwritten successfully. Even
worse with failed whole disk modules. In such cases the only 100% sure
method is throwing into flames of Mordor.
Regards
--
Radoslaw Skorupka
Lodz, Poland
W dniu 2012-12-13 05:59, Don Williams pisze:
I mostly agree. I've been in shops with 10+ year old DASD, so they
might still customers using structured log file DASD. You need to how
your DASD works, in order to develop a reliable erasure plan.
However, I had a teammate delete the virtual volumes on old shark
prior to erasing the data. Would simply reallocating the volumes
(assuming it would put them back in the same spot) and erasing them,
reliably remove all of the data? I'm not smart enough to know for
sure. Then you have to know how the DASD handles bad tracks/sectors.
There could be residual data in bad tracks/sectors that have been
replaced. How do you erase the no longer used bad tracks? I know that
most DASD has spare sectors on each track, so erasing the track
probably erases the bad sectors as well. But I'm not smart enough to
know for sure.
Whether or not you consult an expert depends on how sure you need to
be that the every last bit of your data has been completely and
throughly erased or made unreadable.
Where I currently work, I don't have to worry about erasing DASD.
They require that all of the old DASD be crushed and shreaded.
-----Original Message----- From: IBM Mainframe Discussion List
[mailto:[email protected]] On Behalf Of R.S. Sent: Wednesday,
December 12, 2012 5:25 PM To: [email protected] Subject: Re:
dsf to write over entire volume
W dniu 2012-12-12 18:04, Don Williams pisze:
ICKDSF is not intended to erase volumes.
But it can erase the volumes, can't it?
Now days, DASD volumes tend to be "virtual".
Virtual volume still contain real data. Excluding passing away
"structured log file" technology (RVA, SVA), when you erase the
logical (virtual) volume, you overwrite the real data.
Only the DASD controller may know on which real hard drives your
logical volumes are actually located and spread across.
Not only controller. Sometimes smart folks also know that. I'm not so
smart, but I can tell you what is the relationship between physical
discs and logical volumes in my array. I have it documented, and it
can be checked/confirmed.
To be sure that your data is actually erased, you may need to
consult with the vendor or other expert of your particular type of
DASD.
It need not to be an expert. Last but not least: when you are going
to dispose whole array, the choice is obvious: erase all logical
volumes, isn't it?
If the DASD is encrypted, you may be able to "erase" the encryption
keys making the DASD effectively unreadable.
Good assumption, unfortunately bad implementation. There are errors
in "secure erase" implementation, at least for some disks, AFAIK.
There nothing worse than false certainty in such area.
My €0.02 -- Radoslaw Skorupka Lodz, Poland
--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.
This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.
BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax
+48 (22) 829 00 33, www.brebank.pl, e-mail: [email protected]
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88.
Według stanu na dzień 01.01.2012 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.410.984 złotych.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
