QNAP NAS TS-253D Set Up Query

[Cooldy14]

Hi
I am new to this forum and am a relative self taught novice with NAS os, computer os and Networking.

BACKGROUND INFO:
I have just bought the QNAP 253D NAS drive after giving up with my two WD MyCloud NAS single drives with them not working properly ever since I bought them some years back, set up as one to act as a server and the other as back up. The share points have never worked properly for me and always conflicted with Windows. After watching many hours of you tube, I decided to go for the QNAP over the Synology, mainly because of its hardware and flexible software and use options.

I have a gigabit hard wired network and wif-fi, netgear 24 port gigabit switch, windows 10 desktop pc with 500GB SDD, Windows 10 laptop and four Users (including me as admin and three with restricted access) with five iPhones, etc all accessing the network and NAS. Also have BT tv, two amazon fire sticks, Xbox one for streaming tv services so currently not bothered too much about media streaming from NAS.

I have installed two Ultrastar 8TB hdd (Set up as RAID 1) and have upgraded my Ddr4 ram to 8G. After looking at various you tube vids and content online, I have installed some Thin volumes with correct bytes per inode setting but am now a bit unsure on the following and want to ensure that I set up my NAS in the best way for quick read and write performance, full access from all devices over the lan network and web, and have a reliable back up systems in place.

1. Whether to set up volumes and access with QFile and map drives to windows explorer from pc and laptop; OR set up ISCSI LUN (Block) for certain volumes for quicker read and write and immediate drive visibility in Windows file explorer (a benefit for the 3 restricted access users who all have very limited IT knowledge).

2. How best to transfer data into the NAS volumes once created. Using Free File Sync software, I have currently successfully transferred all data from my MyCloud NAS drives onto two copies saved on Seagate potable external drives.

NAS VOLUMES:
I have created/am creating the following volumes on my NAS:

Vol 1 - Business File back up from desktop pc sdd.

Vols 2 to 5 - Server folders for each of the different users.

Vol 6 - possible music server (prob won’t use fir now as family all have iTunes) but thinking ahead for possible future use.

Vol 7 - possible movie server (prob won’t use for now as have streaming tv services) but thinking ahead for possible future use.

Vol 8 - Photos and captured video collection server.

Vol 9 - possible email server (possibly using QMail - but not got that far yet in looking into the software Or the benefits of have an email server). Currently all user email accounts on desk top and phones with IMAP set up.

Vol 10 - windows pc user back ups.

Vol 11 - Possibly Mobile phone data back ups.

QUESTIONS:

1.0 - Should I set up Vols 2-5 (acting as file servers) as ISCSI LUN (block) or stick to mapping drives in windows.

1.1 - If I do set up as ISCSI, can those LUN volumes be accessed from QFile mobile app?

1.2 - Looks pretty straight forward to set up LUN, targets and initiator access from windows pc but when setting up ISCSI LUN on QNAP, in advanced settings, should I set to 4K not 512 bytes (Default) sector? I recall reading that 4k Is better for windows 10? But could that affect access with QFile from mobiles etc?

1.3 I presume all other drives will be better as standard volumes using the QNAP software for access and sharing?

2.0 What is the best and most reliable method to transfer data into the volumes on the NAS, either:
2.1 use 3.0 usb front port and upload button.
2.2 use QFile and windows explorer on my pc.
2.3 use QNAP back up software over Ethernet.

Sorry for the very long post but wanted to ensure I fully explained my set up and what I am trying to do. Thanks in advance for any help you can offer.

 

[Ross Martin]

TBH this sounds overly complicated for what is essentially a file server. Why not just stick with one large volume and make folder shares with user accounts?! This eliminates any issues of needing to resize volumes when one runs out of space.

Generally you should only have one connection per iscsi target, with the exception being cluster/failover servers. So i wouldn't bother with that. Also if like the Synology NAS, you cannot see the files on the iscsi Luns from within the NAS interface so this can add problems, especially if you want to get the files off and can't mount it!!

Just my two pennies worth!!

Ross

 

[mickevh]

I agree - I suggest you are "over thinking" this a bit, keep it simple and there's less to go wrong and it's easier to fix if it does.

Viz, don't bother with ISCSI - just set up regular CIFS/SMB and/or NFS Shares, then all you have to do on the clients is map/mount the shares. Unless you are into serious nerd level performance comparisons, I doubt you'll perceive any difference "in use" real world. Years ago I managed the storage on an enterprise level network with c. 150 virtual servers, (let alone 100's of client workstations) and the recommendation of both the storage provider and the hypervisor provider (to my surprise) was to use "ordinary" Shares for the virtual disc volume and not bother with ISCSI.

To further echo what Ross says, with "only" two physical discs in a RAID1 set, I don't think there's anything to be gained by chopping that up into multiple volumes - it could be a disadvantage as data use grows and volumes might need subsequent re-sizing. If you have a single volume spanning the entire RAID set, that issue simple doesn't arise until you fill the entire thing. (Unless, of course, you wish to use volume size to constrain growth of some particular dataset.) I doubt there's any performance advantage with multiple volumes, I could conceive it may even be (nerd level) worse - but I confess it's not something I've ever researched.

In my view, keep it simple: One volume across the entire RAID set and chop is up functionally using an appropriate folder structure, share names and control access using permissions. "In the business" we almost always use "file/folder" permissions to police access rather than "share" permissions if the platform offers both.

Backup is an entire other can of worms, but generally I advise that "backup" is more of an ethos than any particular item of software/hardware technology. To me "backup" means making duplicate copies of the data "somewhere else." How often to make a copy, how long to keep it and where "somewhere else" is are all value judgements informed by the value of the data and how often it changes versus the cost. For example, the "backup" of my DVD's is the original media they shipped on so I don't back them up at all, albeit that it will "cost" e a lot of time to re-rip them. My camera photos don't exist anywhere else, but don't ever change, so I just ensure I have some duplicates. But my "work" changes daily and would be the end of the world if I lost it, so that gets snapshotted hourly, backup up every night to a remote storage location and I keep multiple generations going back over time in case we ever need to look at historical information. etc. etc.

For bulk data moves/copies I use Robocopy on Windows platforms, but then I'm not afraid of command line interfaces. There's doubtless many GIU tools that do the same job or "skin" Robocopy. The main thing to look for is something that is restartable in case it craps out half way - you want yo be able to kick it off again, but skip all the files you've successfully copied and just pick up anything changed or not copied yet, and Robocopy and similar tools (rsync on Linux platforms) lets you do that (with the "right" settings.)

Indeed, if you are copying server-to-server, it would be best to not use a copy programmes runing on a workstation at all and see if either server platform has a copy programme on board so that you are not copying "via" a third (workstation) machine. E.G. if you have source A, target B and workstation W, see if B has a tool that can "pull" the data direct from A or (vice versa) see if A has a tool that can "push" the data direct to B instead of running something on W and copying the data A-W-B. If you absolutely have to do a A-W-B copy, make sure none of the machines are connected Wi-Fi - that will at least double the copying time.

 

[ajohnson30]

I second what mickevh said. What many people don't realize with iSCSI is you basically are connecting your LUN/volume to a computer like a physical hard drive. In most cases, only that computer can now use that volume directly, and no others. That computer could then perform file sharing functions on that new disk, but that defeats the entire purpose of a NAS. (There are benefits to iSCSI I won't go into. Generally they are for business or enterprise use).

Stick with SMB shares.

As far as getting the data moved over; If the source drives are USB attached, I'd say test both ways. Typically the usb port on the NAS is not the fastest compared to a 3.0/3.1 on a computer, but YMMV.