@scottalanmiller said:

SATA SSDs often make sense because they are cheaper and the protocol benefits of SAS really are not there in the same ways for SSDs.

So this brings up @DustinB3403 question of best practice or more aptly as you @scottalanmiller said implementation patterns - which ones as generically as you can be would go which way. I suppose it might be easier to say 'in these set of circumstances (list 1-4) you do this, generally in the rest you do that.'

@Dashrender said:

@scottalanmiller said:

@Dashrender said:

I can see doing RAID 6 if you can afford the performance penalty.

Which you would assume that you can if you can wait for a distant node to write as well.

By distant, you mean local, as in the same rack?

Yes, distant meaning outside of the chassis connected over a slow Ethernet link.

@scottalanmiller I think of Snapshots as a quick point-in-time view... if something breaks, I can restore that snapshot in mere seconds, and I'm good to go.

If I have to pull a full image from a backup, it could take minutes - hours to restore that backup...

I would recommend looking at StarWind SA for example.
That solution fits your requirements perfectly, it will also provide you with HA storage that will ensure the business continuity.
As for support, they offer a single point of contact no matter what issue you face, plus the system will be shipped to your site fully preconfigured and pretested.

@DustinB3403 said in SAM-SD Hardware Server Vendors:

@scottalanmiller is there a ballpark entry price for SAM-SD hardware? Are you approving all of all the systems designed? Or did you simply license the term (like Trump) licenses his name?

Prices will be available soon. It's full support, real support unlike SMB devices. So not super cheap 🙂

Sounds like a win.

Thanks!

Yup, our security guy is a big believer in "Linus' law": "many eyeballs make all bugs shallow" or something like that 😄

Literally just got off of the phone with someone who had a FreeNAS bug cause a system to become useless, just like the one case that happened today. But instead of it being the JPE encouraging a mistake, the same problem happened through a GUI bug. One of the big risks that the JPE introduces is that the GUI is all "extra" points of failure and has nowhere near the testing of the standard OS tools. So a little big can cause a lot of damage, as it did. The entire SAN had to be replaced due to a small bug in the FreeNAS interface.

I thought that screen looked familiar, lol.

@scottalanmiller said in What is FakeRAID?:

@Dashrender said in What is FakeRAID?:

Did this pop up again at SW?

Again today, too. Apparently Lenovo is selling FakeRAID on their "servers" now along with all of the other problems. Of course, if a machine has FakeRAID, it's not a server by any normal definition.

WOW... just wow - as if they couldn't fall any further, and they find a way...

@Dashrender said:

@MattSpeller said:

@Dashrender exactly, there are much better ways to set that kinda thing up - I think we're still looking for a scenario where dude-buddy-guy from SW forums would be right. He may just be 100% wrong.

well, again, my friends suggested reason, lack of personnel resources in times of emergency, could be a reason.

No, it makes investment in spares make sense but still doesn't justify preemptive, it would do the opposite. Having spares is what you do when you don't have available labour, not burning them up and throwing them out.

The idea that causing a system to fail would be routine maintenance is just.... I have no idea. Imagine crashing a car, just a little, to cause the airbags to deploy so that you get fresh ones installed once every 50,000 miles. That just doesn't make sense.

i have done this process for one server ya

How long has the RAID been sitting? RAID 1 should not take very long, even with large drives, to sync up.

Exactly - two 6 TB HDD's may be a lot less expensive, but the performance compared to SSD would be insanely different.

How many HDDs would you need to reach your IOPS requirements?