First of all, I really enjoy reading your digest. It's become a monday morning ritual for me and I thank you for that ! It's a pleasure and a great example for others in the industry to follow.
Every now and then a thing comes up in your digest, regarding the use of SMB share targets and/or using inexpensive NAS boxes in general. We all know how you feel about that, and I understand that your "feeling" is not merely a feeling, but something that was learned through Veeam support incidents. You're doing a great job of keeping us aware that this is risky. But you're never really explaining the why of it, or the things behind it.
I highly value and respect your opinions, as they come from real experience. But, like you, I'm an engineer-type of person. So on one hand, we don't just go for authority, we also want/need/are programmed to understand the reasoning for something and the details underneath, before we accept and go with it. So that's one part. On the other hand, many of us still have no choice but to use the "cheap NAS" solution for backups + SMB targets.
Yes, iSCSI is available but it comes with it's own set of issues:
- a share is "shareable", while iSCSI target is not (technically, the target itself is shareable if you also you use a special file system, but we're talking small business customers here, that ones that use a cheap NAS in the first place)
- many setups have more than 1 host to protect, so we have 1 proxy on each host. Means we have many proxies. Which asks for careful LUN capacity planning on the NAS, as you can't just share a LUN between proxies, so we get a problem with space efficiency. With SMB there is just one share and all space is shared between proxies. It's a network file protocol, after all, and this seems like a use case that it was designed for. From a higher point of view, it seems much more logical to use a network file protocol than iSCSI here.
- last, but not least, when we have 1 proxy on each host and one host dies, the recovery process includes connecting that LUN to different proxy on another host - leading to a risk of connecting to a LUN from more than 1 location, due to human mishap. For those that don't know what this means: it's kind of like connecting a SATA cable from one disk to two computers in parallel. In practice, it means instant corruption of your backup repository, precisely the one you need right now to perform a restore. That's risky ! With SMB that simply can't happen. And backup is all about lowering risks, so this reason alone is enough to scare people away from iSCSI.
Besides telling us that it's "risky" to use SMB and cheap NAS devices and that is "not recommended", that it's the "no.1 case of failed restores in our support", it would also be great if you could provide some more details and/or some statistics as to why this is bad. What exactly are the risks with using SMB (without CA) ? Some of us won't be able to get rid of cheap NAS + SMB anytime soon, and we need to be able to gauge that risk and understand it more properly as we have to live with it.
Also, Veeam has a thing called "Storage-level corruption guard". Is our data on SMB-connected repository 100% safe, after backup files health check has been performed on it ? Or not. And if not, why not. The devil is always in the details. But you didn't really provide much (or any) details around this, that would help us better understand and gauge this risk that we have to live with. You also noted that more than a fourth of your customers use that combination, proving what other community members are saying - that this setup is quite common. It would benefit everyone to better understand, in much more details, why using cheap NAS + SMB is a bad idea. Where are the problems. And how bad it really is. I personally didn't hit a failed restore, I just have your information that I'm "risking it" but I have no idea how much of a risk this is.
When time comes for a backup subsystem upgrade at each of our customers, I'll try to push for a normal server with Linux or Windows on it and use that as a backup repository. It has other advantages, besides making me feel safer as per your suggestions. But you have to understand that for some customers it's simply not going to happen, so this problem is not going away for many of us. I understand also that Veeam v10 will support NFS and that's going to be safe. I'd also like to know more details about why NFS will be safe and SMB is not safe, as they are basically doing the same thing. Don't get me wrong, I'm far from being an MS fan - I just happen to notice that MS says it's ok to host VM disks over SMB share (granted, it needs to be highly available) but it implies the protocol itself is safe. So where exactly is the problem with SMB, why is it not ok for backup. Is it only in "cheap NAS" implementation of it ? Is that where the main issue is ?
With kind regards,