Data centre decommissioning checklist
Decommissioning isn't one wipe — it's hundreds, under time pressure, with an auditor waiting at the end. Here's the process that keeps it sane.
Data-centre decommissioning is where erasure becomes a logistics problem: many machines, many drives (often SAS), tight timelines, and a compliance requirement for a record of every single one.
The checklist
- Plan the boot method — PXE boot over the network is the standard for fleets; USB per machine doesn't scale.
- Pre-set Chain of Custody IDs — one per rack, asset range, or client, so every machine's report rolls up correctly.
- Run unattended — for a fleet wipe, you want no prompts: a pre-set COCID and auto-continue on frozen drives.
- Upload automatically — push reports to a central dashboard rather than collecting USB sticks.
- Verify coverage — reconcile the report list against your asset inventory so no drive is missed.
- File certificates — generate a certificate per job and store it with the source reports.
How tScrub supports fleet wipes
- PXE boot — the appliance image boots from the network, no media handling.
- Unattended mode — a pre-set COCID skips the prompts and runs to completion.
- Automatic upload — reports push to your dashboard over HTTPS, or upload via FTP/SFTP.
- Per-machine records — every drive is serial-numbered in the report, so reconciliation is mechanical rather than manual.
Handling SAS drives at scale
Decommissioned servers are full of SAS drives, which often lack firmware erasure and fall back to software overwrite — slow, but the standard path. tScrub handles them in the same unattended run, recording the method per drive.
FAQ
How do I avoid missing a drive?
Reconcile. The report lists every drive tScrub touched, by serial number. Diff that against your asset inventory before you sign off the decommission.
Can I wipe a whole rack at once?
Yes — PXE-boot every machine in the rack, each runs tScrub independently and uploads its own report, all tied to the same Chain of Custody ID.