Bought a used enterprise SSD? How to check its health and decide whether to keep it

1. 1.Before reading any health figure, print the controller's identity and hold it against the listing and the printed label. Vendor ID, serial and model together form a globally unique identifier, so a serial or model that disagrees with the label is a return reason by itself.

   nvme id-ctrl -H /dev/nvme0

   Readingmn: model number. sn: serial number. fr: the currently active firmware revision. vid: the PCI-SIG vendor ID. ssvid: the PCI-SIG vendor ID for the subsystem; it can differ from vid, and we read no document saying what a difference means, so record both. Write down mn: the rated TBW or DWPD and the warranty years come from the data sheet for that exact model.
2. 2.In the same decoded output, note what the controller supports, because two later paths depend on it: Device Self-test (OACS bit 4), Format NVM (OACS bit 1), whether a format or secure erase of one namespace applies to all of them (FNA bits 0 and 1), cryptographic erase as part of a format (FNA bit 2), and the crypto-erase, block-erase and overwrite sanitize actions under SANICAP.
   ReadingNo Device Self-test bit: the extended self-test will be rejected. No crypto-erase bit and no SANICAP action: pick an erase method the drive does list.

1. 1.Print the SMART/Health Information log. The controller keeps it over its whole life and across power cycles, so it describes everything the drive recorded, not only the days since it shipped to you. The labels below are the ones nvme-cli 2.x prints.

   nvme smart-log /dev/nvme0

   Readingcritical_warning should be 0. Bits 0x01 (spare below threshold), 0x04 (reliability degraded), 0x08 (media read-only) and 0x10 (volatile memory backup failed) are return reasons; 0x02 means the drive is outside a temperature threshold right now, so check its cooling and read the log again before judging it. These bits show the present state and are not kept, so a 0 on arrival says nothing about the drive's past. available_spare against available_spare_threshold (avail_spare and spare_thresh on older nvme-cli): the threshold belongs to the drive, so read it instead of assuming a number, and treat spare at or near it as a return reason. percentage_used is the vendor's estimate of rated life consumed; the Percentage Used page linked below covers high readings. media_errors counts unrecovered data integrity errors over the drive's life and should be 0 on a drive you keep; the error information log entry count covers the same life.
2. 2.Next, read the counters that describe how the previous owner ran the drive. The sources behind this page give no vendor threshold for any of them, so record each one and compare it with what the listing claimed.
   ReadingData Units Written (data_units_written on older nvme-cli): host writes in thousands of 512-byte units, rounded up, without metadata, so TB written = Data Units Written x 512,000 / 10^12. power_on_hours: leaves out time the controller sat powered in a low-power state, so it can understate how long the drive was installed. unsafe_shutdowns: power losses that arrived with no shutdown notice from the host. Warning Temperature Time (warning_temp_time on older nvme-cli): minutes at or above the drive's warning composite temperature (WCTEMP) and below its critical one (CCTEMP). Critical Composite Temperature Time (critical_comp_time on older nvme-cli): minutes at or above CCTEMP. Solidigm's data center warranty also ends when the reported temperature reaches the limit in its addendum.
3. 3.Cross-check with smartctl, which decodes the same log and converts the write count to bytes.

   smartctl -x /dev/nvme0

   Reading'Data Units Written: N [X TB]' is already converted at 1000 x 512 bytes per unit. 'SMART overall-health self-assessment test result' is derived from the Critical Warning byte alone: a failing result would mean the device has failed or predicts failure within 24 hours, and PASSED tells you nothing about endurance left. The vendor IDs print as one 'PCI Vendor/Subsystem ID' line when the two are equal, otherwise as separate 'PCI Vendor ID' and 'PCI Vendor Subsystem ID' lines; either way they repeat vid and ssvid from the identity check.
4. 4.If the history looks too clean for the drive's age, treat it as unproven either way. In one forum thread, a buyer of a used Intel SATA drive found about 28 power-on hours on a unit a warranty lookup dated to 2017 and asked whether SMART had been reset. In another, a used Intel SATA drive read zero power-on hours while its Workload_Minutes counter implied about eight years, and its NAND writes rose overnight with no host writes. Some replies in both threads put it down to an unused datacenter spare, and neither thread settled it. We found no vendor document stating whether or how these counters can be reset. A 2016 ServeTheHome fleet report also noted some Dell OEM drives that did not report power-on hours at all.
   ReadingJudge the drive on the checks you can run and on the seller's return window, not on the hour count alone.

1. 1.Read a SAS SSD as a raw SCSI device. A forum arrival-testing guide puts SAS drives behind an IT-mode HBA so each shows up on its own; -d scsi stops smartctl sending ATA commands to it. Use -x, or add -l ssd to -a, because the endurance figure comes from the Solid State Media page that -l ssd prints.

   smartctl -x -d scsi /dev/sgN

   Reading'Percentage used endurance indicator: N%': 0 is new, 100 is the end of the maker-projected life. 'Elements in grown defect list: N'. 'Accumulated power on time, hours:minutes'. 'Manufactured in week W of year Y': hold it against the listing's description. 'Error counter log': the uncorrected errors column should read 0. 'SMART Health Status' comes from the Informational Exceptions ASC/ASCQ, not from the endurance figure.
2. 2.If the drive does not return the Solid State Media page to smartctl -l ssd, read log page 0x11 raw.

   sg_logs --page=0x11 /dev/sgN

   ReadingThis is the page smartctl decodes as the percentage-used indicator. sg_logs --all /dev/sgN dumps every log page the drive supports.
3. 3.Record the grown defect count now and again after the long self-test. Use --grown: with it the tool is passive and reassigns nothing; without it, sg_reassign reassigns the blocks at whatever addresses you give it.

   sg_reassign --grown /dev/sgN

   ReadingEach reassigned block adds an entry to the list. sg3_utils calls an empty list the best kind and a quickly growing one an ominous sign; its page speaks of disks and does not mention SSDs, so we give no SSD threshold. Growth between your two readings is the signal.

1. 1.SATA SSDs report wear through vendor-specific attributes, and smartctl names them from its drive database. Print them.

   smartctl -A /dev/sdX

   ReadingDefault names: 177 Wear_Leveling_Count and 233 Media_Wearout_Indicator for wear, 241 Total_LBAs_Written for writes, 9 Power_On_Hours, 5 Reallocated_Sector_Ct. Intel DC S35x0/3610/3700 drives report Host_Writes_32MiB, Available_Reservd_Space and Unsafe_Shutdown_Count. Micron 5100/52x0/5300/5400 drives report Percent_Lifetime_Remain and Total_LBAs_Written. Raw write units differ by vendor, so do not turn a raw count into bytes until you have that vendor's unit.
2. 2.Print the ATA Device Statistics log, which carries a standard endurance figure on drives that support it.

   smartctl -l devstat /dev/sdX

   ReadingPage 7 holds the Percentage Used Endurance Indicator where the drive supports the log.
3. 3.Read SATA drives on a direct SATA port where you can. In one thread about a used Intel SATA drive reading 0 power-on hours, replies suggested re-reading SMART on a direct SATA connection instead of through a USB enclosure and testing the real capacity before trusting the drive.

1. 1.Start the extended self-test; -t short gives a quicker first pass. For a SAS drive use -d scsi /dev/sgN; for a SATA drive use /dev/sdX.

   smartctl -t long /dev/nvme0

   ReadingThis runs the NVMe extended self-test, the SCSI background long test or the ATA extended test. An NVMe drive without Device Self-test support (OACS bit 4) rejects the command.
2. 2.When it finishes, print the self-test log and re-read the counters you recorded on arrival.

   smartctl -l selftest /dev/nvme0

   ReadingA failed entry, or one aborted by an error, is a return reason. Compare media_errors (NVMe), and the grown defect list and uncorrected errors (SAS), with your arrival readings.

1. 1.Find the rating for the exact model number the identity check printed. TBW is the JEDEC JESD218 endurance rating in terabytes written by the host. DWPD is full-capacity writes per day under a specified workload for a specified lifetime.
2. 2.Subtract what the drive has already written from the rating, using your own figures.

   TB written = Data Units Written x 512,000 / 10^12;  rated TB = data-sheet TBW, or capacity_TB x DWPD x 365 x rated_years (the lifetime the DWPD figure is stated over);  remaining rated TB = rated TB - TB written

   ReadingIf the remaining rated TB, at the write rate you expect, does not last the service you want, the drive does not fit the job even with every health field clean. Our catalogue holds no Percentage Used or remaining-endurance figure for any listing, so this number exists only for the unit on your bench. Used stock varies: one buyer of eight used 15.36TB drives reported seven still at 99% or more of life.

1. 1.Finish every reading above first. Then confirm the target by its serial number from the identity check, not by its device number: the nvme-cli documentation warns that the number in /dev/nvme0 does not say which namespaces belong to it. Use only a method the identity output lists under FNA or SANICAP.
2. 2.This permanently destroys all user data on the namespace, and on every namespace on the drive if the identity output shows FNA bit 0 or bit 1 set; it cannot be undone. Secure erase setting 2 performs a cryptographic erase by deleting the encryption key; setting 1 is a user data erase. nvme-cli warns that guessing from the device numbering can irrevocably erase the wrong device.
   Destructive. This command destroys what is on the device and cannot be undone. Confirm the device path twice and have a backup of anything you still need before running it.

   nvme format /dev/nvme0n1 --ses=2

   ReadingUse --ses=1 where the identity output lists no cryptographic erase.
3. 3.Sanitize also destroys all data, irreversibly. Start only an action that SANICAP lists.
   Destructive. This command destroys what is on the device and cannot be undone. Confirm the device path twice and have a backup of anything you still need before running it.

   nvme sanitize /dev/nvme0 --sanact=start-crypto-erase

   Reading0x02 is block erase and 0x03 overwrite. Check progress with nvme sanitize-log /dev/nvme0: status 0x0002 means in progress, 0x0001 completed successfully, 0x0003 failed, and Sanitize Progress gives the percentage complete.
4. 4.On SAS, sg_sanitize erases all data and the operation cannot be reversed. Even if the drive is power cycled, the sanitize continues after power returns until it is complete. It pauses 15 seconds before starting so you can reconsider; do not add --quick, which skips that pause.
   Destructive. This command destroys what is on the device and cannot be undone. Confirm the device path twice and have a backup of anything you still need before running it.

   sg_sanitize --crypto /dev/sgN

   Reading--block and --overwrite select the other methods. Watch progress with sg_requests --num=9999 --progress /dev/sgN. sg3_utils notes that finding out whether a disk supports SANITIZE can be a challenge.
5. 5.On SATA, an ATA security erase permanently destroys all data. hdparm first locks the drive with a password, then erases it; hdparm marks both switches DANGEROUS, says they might not work with some kernels, and permits no other options on the command line with --security-set-pass. Record the password you set.
   Destructive. This command destroys what is on the device and cannot be undone. Confirm the device path twice and have a backup of anything you still need before running it.

   hdparm --security-set-pass PWD /dev/sdX; hdparm --security-erase PWD /dev/sdX

   Reading--security-erase-enhanced is the enhanced form. The special password NULL stands for an empty password.

We found no vendor document stating whether or how SSD health counters can be reset. Buyers in two Level1Techs threads suspected resets on used Intel drives with near-zero power-on hours, and neither thread proved or ruled one out. The NVMe health log is defined as kept over the controller's life and across power cycles.

Micron's returns page sends anyone who bought from a reseller, authorized distributor or contract manufacturer to that seller for returns; we found no Micron SSD warranty document stating transfer or endurance terms. The Western Digital Ultrastar SSD warranty page we opened rendered no warranty terms, so we state none. We found no Samsung data-center (PM/SM-series) warranty document; the Samsung SSD Limited Warranty we read lists retail models in its table.

Not on their own: wear shows in Percentage Used and in Data Units Written against the rating. One forum poster's Intel DC P3700 had 44,627 power-on hours with Percentage Used at 1% and about 21.6TB written.

On this site the enterprise SSD set is defined by stored form factor (U.2, U.3, E1.S, E3.S) or a SAS interface. No stored field separates an enterprise SATA SSD from a consumer one, so the single SATA SSD row is excluded rather than guessed.