TR Forums

Opened this one up from a businesses server this morning when it failed to boot anymore....




I see a lot of these failures in the Seagates since the 7200.11+ era.

"Now featuring automatic secure data erasure at product EOL."

Gives "data scrubbing" a whole new meaning.

Looks fine - It will polish out...

I wonder how many "bad sectors" are there on the HDD now?

I've got a bottle of Meguiar's...

diesavagenation wrote:

Hopefully that bad boy was in a RAID array?

Lol, nope. That was the OS/App drive on the server. Thankfully it imaged daily.

I recall years ago when my high school had roll back data to a 2 months old backup.

Which meant anyone that had projects, documents, and etc on the school network were screwed.

I'm not sure if the IT department lost any employees in the aftermath.

Poor Seagate. They really are terrible these days.

You don't have to be stuck with Seagate.
http://www.newegg.com/Product/Product.a ... 6822145912

What model was it?

How long did that HDD last?

I would be surprised if the unit operated beyond a week if the platters were experiencing that level of wear and tear. In any case, it looks like a simple QA failure (that unit shouldn't have never left the factory). Nothing new here and all vendors succumb to it.

JustAnEngineer wrote:

You don't have to be stuck with Seagate.
http://www.newegg.com/Product/Product.a ... 6822145912

Oh trust me, I wouldn't put any data on a seagate drive that I would like to keep since the 7200.9 series. Seen waaaaay to many spectacular failures (like this one) with them since that series. I've used WD Blacks or RE4's or Hitachi exclusively since then which have proven to be robust.

My last Seagate was in 2002. It has been WD ever since.

continuum wrote:

What model was it?

1 TB 7200.14, manufactured in Oct 2013. The system ran 24/7 as a pbx recorder server with next to no usage since brought online (a total of two recordings on it). The heaviest use it got was from applying windows updates since November. 99.999% of the time it just sat there idle and only rebooted when windows updates were applied.

Krogoth wrote:

How long did that HDD last?

I would be surprised if the unit operated beyond a week if the platters were experiencing that level of wear and tear. In any case, it looks like a simple QA failure (that unit shouldn't have never left the factory). Nothing new here and all vendors succumb to it.

See above.

Pretty sure my last Seagate was an ST-506.

Are their SSDs as disaster prone as their HDDs? I took a gamble on a cheap 256 GB 600 a while back. 7 month later, nothing obviously wrong with it...yet.

weaktoss wrote:

Are their SSDs as disaster prone as their HDDs? I took a gamble on a cheap 256 GB 600 a while back. 7 month later, nothing obviously wrong with it...yet.

Time will tell but Seagate hasn't had a strong firmware history with their mechanical drives for a while and that could carry over to the SSD's I suppose.

ClickClick5 wrote:

My last Seagate was in 2002. It has been WD ever since.

The Hitachis/Toshibas are pretty excellent drives too.

ClickClick5 wrote:

My last Seagate was in 2002. It has been WD ever since.

2003 for me (Athlon XP 1800+... those were the days....). Had 4 blow up in a period of 4 months after having them replaced.

Never again!

Sounds like the HDD was defective from the start, but it was idle for almost all of time until the recent Windows Updates and this what killed it.

Krogoth wrote:

Sounds like the HDD was defective from the start, but it was idle for almost all of time until the recent Windows Updates and this what killed it.

Keep in mind that, yes, most of its writing came from windows updates, however it was still regularly rebooted for those updated and a full drive image was done daily. So it was working fine without so much as a smart failure for roughly 9 months.

As I said in the first post, this particular failure I have seen a lot over the last few years on Seagates (although this one did one doozy on the platter, usually it is a much smaller area of damage.

Does there seem to be any pattern to the failures you've been seeing, with regards to the series of drive? I agree that the 7200.11s were a cluster**** (had several of them fail myself), but my 7200.12s have been fine. Two RAID-1 arrays (4 drives), the older pair are pushing 30,000 hours of uptime and the newer pair are at around 14,000.

(Of course I've probably jinxed them now, just by saying that...)

Deanjo wrote:

weaktoss wrote:

Are their SSDs as disaster prone as their HDDs? I took a gamble on a cheap 256 GB 600 a while back. 7 month later, nothing obviously wrong with it...yet.

Time will tell but Seagate hasn't had a strong firmware history with their mechanical drives for a while and that could carry over to the SSD's I suppose.

Remember back in 2009 when Seagate was releasing firmware to fix factory bricked drives, and the fix bricked them even more? Or when they were flashing 16MB cache drives with the firmware for 8MB firmware, or the time...

just brew it! wrote:

Does there seem to be any pattern to the failures you've been seeing, with regards to the series of drive? I agree that the 7200.11s were a cluster**** (had several of them fail myself), but my 7200.12s have been fine. Two RAID-1 arrays (4 drives), the older pair are pushing 30,000 hours of uptime and the newer pair are at around 14,000.

(Of course I've probably jinxed them now, just by saying that...)

Out of the dozen or so seagates that have had platter damage it seems to be mostly in the 7200.12 and 7200.13's (and it doesn't seem to matter which factory or month of assembly). I only recall seeing platters scraped like this once in 7200.11. Most of the 7200.11 failures develop the click of death but no physical damage visible to the eye on the platters.

Deanjo wrote:

diesavagenation wrote:

Hopefully that bad boy was in a RAID array?

Lol, nope. That was the OS/App drive on the server. Thankfully it imaged daily.

All of my servers get a RAID1 array for the OS, at a minimum. All of our servers are now connected to our SAN for data volumes, so I generally do a RAID10 array for the OS drive.


I've got my own stories with Seagate drive failures. Our SAN vendor just replaced 37 out of 48 drives on our non-production SAN. Those drives were all Seagate drives and they replaced them with HGST drives. The arrays in this SAN (3 x 16-drive arrays) used to be our production SAN. It was put in place in July 2009...the first drive failed in August 2009. It just went downhill from there. We replaced those arrays with new equipment two years ago and reconfigured the old arrays as a replication target. We finally pushed the issue on the drive failures (after having three or four more with the I/O being VERY low) and I'm grateful that they agreed to replace all of the remaining drives (and even a handful that had already been replaced).

Weird. I've got tons of data on Seagates, no problems. I might reconsider that going forward, just find it weird that it took so long for me to hear about these failure rates.

ClickClick5 wrote:

Deanjo wrote:

weaktoss wrote:

Are their SSDs as disaster prone as their HDDs? I took a gamble on a cheap 256 GB 600 a while back. 7 month later, nothing obviously wrong with it...yet.

Time will tell but Seagate hasn't had a strong firmware history with their mechanical drives for a while and that could carry over to the SSD's I suppose.

Remember back in 2009 when Seagate was releasing firmware to fix factory bricked drives, and the fix bricked them even more? Or when they were flashing 16MB cache drives with the firmware for 8MB firmware, or the time...

lol...'bricked them even more'. Is that even possible? Double brick all the way?

Anyway, the 7200.11s are the (somewhat) modern day Deathstar. I don't think that any other recent Seagate series has had such widespread issues, and anecdotal evidence otherwise is anecdotal. (Perhaps I am a bit hopeful because I have two 4TB HDD.15 drives in RAID 1 for mass storage and would be annoyed by a failure.)

From what I read over the years. Large-scale HDD failures aren't really vendor specific and they are just a bad batch that managed to get through QA/QC and get out onto the market.