Can you put a SQL DB on a NAS? [closed]

Question

Closed. This question is off-topic. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Database Administrators Stack Exchange.

Closed 6 years ago.

Improve this question

Can you put a SQL DB on a NAS drive? For example can I put the PostgreSQL DB "files" on a Sinology NAS or am I better to leave everything on a "real" PC? (like, say, a regular PC server running Linux)

I'm asking this question because something weird happened: some accounting app written in WinDev (a RAD tool kinda famous in some countries, like many french-speaking countries), using a HyperfileSQL DB stored on a NAS, just screwed up big times.

wikipedia HyperFileSQL (in french)

wikipedia WinDev (in french)

The entire DB got corrupted, many files had a size of zero and the developer of the application tell my clients: "It's your fault, you shouldn't have put the HyperfileSQL DB files on a NAS, NAS haven't got a CPU powerful enough, so corruption can happen".

I don't get this: HyperfileSQL is supposed to be ACID. I can understand delays and/or poor perfomances but complete corruption?

Heck, I should even be able to yank the "UPS cord" (I mean: the "power cord", but everything is on UPSes) from the NAS and a true SQL DB should be fine no!?

So can I put a SQL DB on a NAS?

Should I expect poor performance? (it's for tiny databases and I never noticed any perf issue)

Are complete DB corruption to be expected?

Answer 1

Databases require certain guarantees from the storage it runs on to implement ACID. Unfortunately, it is not always possible for the database to determine if those guarantees are met.

Here are some requirements that the storage (no matter if it is NAS, direct attached or SAN) must meet:

Write Ordering: Writes my happen in the order they are confirmed to the operating system. For example, if the database submits a write request for block A and B to the LUN, you can't have a situation where B is confirmed than A, but where the write happened in the opposite order.

Write through: When the storage says that something is written, it must be on permanent storage that will survive power failure. Unfortunately, a lot of operating systems and storage systems will cache the writes in DRAM unless you are careful. This means that if you lose connectivity to the NAS, you may lose data.

No Torn I/O When you submit a block of I/O and the I/O system confirms the receipt of that block, the entire block must be on stable media (for example, it is not allowed that a 8K page be split into 2 x 4K and the 8K write confirmed before both 4K blocks are written).

Atomic writes: Depending on the media, there is a minimum write size that is required to be atomic (typically 512B or 4K). Writes of this size either happen or they don't. There is no intermediate state that can be represented on the media. Note that this is not (quite) the same as torn pages protection. For example, with a torn page, you could be a situation where 4K of the 8K gets written but the 8K is not confirmed, you then crash and get corruption (which is detectable and typically fixable by the database after restart). With atomics, the write either happens or it does not.

Designing storage that is suitable for a database is no simple matter. Often, people get it wrong - especially if they did not test the storage before deploying. It is little comfort, but your situation is not that uncommon and NAS might have nothing at all to do with this (people get this wrong on direct attached storage and SAN too).

Databases can generally run fine on NAS if the storage is designed correctly and the NAS has the right guarantees.

Saying that the CPU of the NAS is not powerful enough is completely irrelevant to this discussion. So I think you can safely disregard the opinion of that developer.