#AFF A800 (NAF-1704) Disk Sanitization Disk Read Error

1 messages · Page 1 of 1 (latest)

mental light
#

Good day, everyone! I work as an Enterprise Technician/Auditor for an asset retrieval & recycling company. My department recently received (x4) AFF A800 storage controllers from a client. Each of these units came with (x48) X4013A 7.6TB NVME 2.5IN U.2 PCIE 2x2 Gen3 SSD. Our two erasure software that we use failed to detect - or perhaps refuses - the drives. One of the other techs assume it's because of the bus interface of these drives. Which is odd, because both software never had problems reading NVMe before.
Since these units and the total drives are worth a lot of money, upper management requested we try and see if we can wipe the drives within the controllers. I'm familiar with disk sanitization using Ontap. However, I've ran into an issue I can't seem to get around.
To give an overview of the steps I've performed. I first booted ontap using the loader prompt and entered the boot menu. I performed the "wipeconfig" command in the boot menu to clear any client configuration in the node. Once rebooted, I entered option 9 (Configure Advance Drive Partitioning) and performed 9a, then 9f (for extra measures), and then 9c. I then entered maintenance mode and performed the disk show -n and storage show disk -a commands to view the disks ownership info and seems everything has been cleared (provided screen caps).
I moved forward with performing the storage encrypt disk sanitize command (screen cap provided and it completed successfully. But, then I tried performing the command disk sanitize start -v and receive a reply "Failed to recognize disk. No disks to read." I tried the other disk sanitize options, but I keep getting the same response. I'm confused on this, because the disks are clearly listed in the show commands I performed earlier.
Would anyone have any insight on this scenario? And if there is a way to get around this?

vast vale
#

The proper steps for this

  1. boot both controllers to Maintenance mode
  2. Boot option 9 on both
  3. Run option 9a on node 1. WAIT for it to finish
  4. Run option 9a on node 2. WAIT for it to finish
  5. Run option 9e on both (return to boot menu)
  6. On BOTH NODES, boot option 5 (maint mode)
  7. at the prompt: disk remove_ownership all
  8. ON ONE NODE ONLY: disk encrypt sanitize -all
  9. You should very quickly see a message similar to this: Disk encrypt sanitize all complete: Sanitized 24 of 24 encrypting disks; 0 partner disks and 0 other disks not sanitized
  10. Note: there is a bug that if you try to run "disk encrypt show" on either node, the node will hang and you will need to power cycle.
  11. Instead: after the message appears, halt both nodes. "boot_ontap maint" -> then run " disk encrypt show.
mental light
#

Thank you for the information! I will do just that.
Are there further steps regarding the disk sanitization?

vast vale
#

Nope. the disks are cyrpographically shredded at this point.

mental light
#

Thank you for shedding light on this!

#

A follow up question regarding the SED's. The disk sanitization commands would have done nothing even if we don't perform the encryption sanitization first, correct?

vast vale
#

I do not think the "disk sanitize" does anything for SEDs. That is why there is a "disk encrypt sanitize"

mental light
#

Understood.

#

Thank you again for all your help

vast vale
#

looking at your photos, it looks like you sanitized all 48 disks. You just need to do "disk encrypt show" and the MSID should be "open 0x0"

mental light
#

Since these drives were previously owned by a client, could we have avoided cryptographically shredding these drives if they could clear their encryption on them prior to handing them over to us?

vast vale
#

I would not take the chance. The SED drives sanitization is basically immediate/easy to do. no need to take the chance.

mental light
#

I thought so. Thank you for confirming that.

fickle cairn
#

it's strange that your external sanitization tool/software can't handle encrypted disks 🤔

#

with the PID printed on the disk it is pretty easy to sanitize them even if you don't have the key

vast vale
#

That is potentially a lot if extra work to punch in all those PID keys

fickle cairn
#

true, but if you don't happen to have the correct ONTAP system with the keys still in its TPM (or if the disks are set to auto-unlock by chance), there's no other way around. And for a generic "sanitizing" tool I think this should be a standard feature

mental light
#

Yes, we've actually done the individual PID for a previous project sometime back. It was for a load of OPAL encrypted drives. The problem with the drives in this current project is that they're not being detected by both our tools.

vast vale
#

Pretty sure you get around that:

#

The drives could come from another system. Using maintenance mode will get around it

fickle cairn
#

ah, not detected at all? that might be because they're formatted with a different sector size, Linux for example doesn't like 520bps or 4160bps drives (which I believe those are)

vast vale
#

I agree with that

mental light
#

I see. That's good to know

#

Upper management isn't going to be happy to know the drives are essentially useless. But, not much we can do on our end. Besides sanitizing their encryption per protocol.

mental light
#

Apologies for reinitiating this thread. The client has agreed with our compliance team regarding the disk encryption sanitization. However, they are requiring a log to be provided. I've entered the nodeshell using the system node run -node local command, and elevating privileges to advance via priv -level advanced command. I've tried running the rdfile command with the file path /mroot/etc/log/sanitization.log. But the system replies with No file or directory found. Am I performing this correcty? Or is the file path different?

vast vale
#

Try just capturing all output to a text file.
I know with secure sanitize, I’ll do all disks just about as immediate as the command is run there is output indicating all disks are sanitized.

With standard disks I think it still outputs to the console as they finish…hours later

mental light
#

I figured that maybe the course of action regarding the log. Would you think this would suffice as proof for the sanitization?

#

Of course the entire output is saved to a text file, that is

vast vale
#

I would hope so but it might be relevant to include the before shot of the “disk show encrypt” which shows the disk have a key attached to them.