I've got a linux host that need to mount a data share located on a NAS. The choice is between NFS v3 (NAS limitation) and iSCSI. The initial idea was to have a NFS mount to the file server that provide the samba mount points to the rest of the network, and also an NFS mount to the backup server that obviously backs up the data. (This idea does not apply to iSCSI, I'm aware that you can't / shouldn't have multiple initiators to the same iSCSI target.)
Data Server - + - (SMB) - User 1 / | - (SMB) - User (..) (NFS) + - (SMB) - User (n) SAN / \ (NFS) \ Backup Server
POSSIBLE FLAWED UNDERSTANDING - The problem I perceive is that since NFS v3 is stateless, it has no idea which server has access to the file and for that matter what the user is doing with it. So if a user is writing to the file via the SMB share, and the backup server is trying to backup the file, it's possible that the server will backup an intermediate / corrupt file? If this is indeed the case, and if the configuration is changed such that the NFS share is mounted only on the data server, then the backup script ssh in to do it's work, will this concurrent behavior still be a problem over NFS? (I imagine if it uses lock files, everything will be well, but are there other kernel land locking methods that will be broken due to the stateless NFS v3?)
It seems that if I use an iSCSI share mounted only by the data server, and the backup server having to SSH in to do it's thing, all the problems will go away. This is based on iSCSI presenting as a block level device, meaning the higher level logic for file access control is performed on the OS level.
Lastly, if the last method of using iSCSI is used and Oplocks are enable on Samba, to resolve concurrent file access between users connected via samba, will this also impose access restrictions on processes trying to access the same files not via samba, i.e. a samba user writing a file while the backup daemon is trying to read the file?