-2

I am working on implementing a D2D backup solution for ~150 computers based on Crashplan ProE (no cloud storage). For the storage backend, I picked up an Overland Snapserver DX2 head unit and one expansion, with 12x2TB per cabinet and I'm planning on using RAID6 on a per-cabinet level. While the foundation of the system is as a NAS, the DX2 is a "unified" storage provider, as it also has the ability to act as an iSCSI target.

Most things have been good so far, but I'm fairly stuck if I want to go with accessing backup archives through NAS, or through iSCSI. I've determined that there really isn't any noticeable processing or performance overhead associated with iSCSI. I'm mostly concerned with filesystem reliability in the long run, with iSCSI essentially seeming like a feature that's been tacked on. They also only supported 2TB iSCSI volumes until sometime last year, when support for larger volumes was enabled. I'd probably be working with an 18TB iSCSI disk. I've done what I can for trying to recreate possible "worst case" scenarios of sudden power loss, drive removal/reinsert/rebuild, etc and things have seemed okay. I've also seen some commentary indicating that iSCSI may be more appropriate than SMB for the sort of multithreaded file access most conducive to decent performance from Crashplan.

So- the short version- anyone with experience with very large iSCSI disks on "unified" low to mid-end NAS/SAN boxes have any comments on iSCSI file system reliability in the longer term?

Edit: All traffic is going to a Crashplan ProE server from the desktops. The server is the only system that communicates with the storage units. I could have gone with a DAS, but was looking for flexibility. Sorry for not being clear there.

2
  • 10
    Just as an aside: backing up 150 individual workstations is really not a great way to be doing backups. You should probably be doing something like folder redirection to a file server so that all important documents exist centrally. You can also configure user profiles to roam so that user settings and preferences are central as well, then just back up the file server(s) that they sit on. It's much much more reliable. I couldn't imagine trying to troubleshoot locked file issues or backup failures on 150 client PCs.
    – MDMarra
    Jan 10, 2013 at 16:49
  • That's why I'm using Crashplan ProE. We were previously using Retrospect which was serviceable but requires too much attention. We've already got a client/server backup system in place (the clients don't backup directly to the storage target themselves) so replacing it with a likewise system is much easier than centralized storage. It's also a mixed OS X/Windows environment, we have A LOT of data (giant image files), and only 100Mb to desktops (moving all switches to GbE isn't in the budget). Thanks for the suggestion though.
    – Adam
    Jan 10, 2013 at 18:54

2 Answers 2

2

First, iSCSI isn't a file system, it's a protocol for sending/accessing/receiving data by using SCSI commands over a network (interface). (yeah I know that's basic, you can google iscsi if you want wikipedia or other research)

That said, the reliability is really based around the back end storage's reliability and the front end host's reliability along with the reliability of the network that iSCSI operates on.

If you implement iSCSI vs. straight NAS access you do add a front-end host that could go down, so factor that into reliability.

I won't go into a great dissertation, you can see "Related" links on the side that will give you more info on various iSCSI topics, but your short version question about whether the iSCSI "file system" is reliable long term can only be answered individually based on the above in bold. And it is still subjective. Maybe reliable for you is that it runs 24x7x365 for 5 years straight. For others if it simply lasts 6 months with an hour a month of downtime they are cool.

NOTE: all that said...you seem to really be questioning the difference between iSCSI block level access vs. storing the data on the storage as a NAS/CIFS/SMB server. Realize that if you are implementing iSCSI you'll still need to carve up that LUN on the host into whatever file system you plan on using, which sounds like a basic SMB file server still.

1

As TheCleaner states iSCSI isn't a file system, meaning you have to pick a cluster-aware file system to use the blocks iSCSI shares, and there has to be a locking management system in place too, either as part of the cluster-aware file system or as a stand alone.

I'm unaware of there being any general-purpose cluster-aware file systems capable of managing the levels of traffic you'll need that can support 150 clients, and for good reason, they're not designed to do that job.

So use a NAS file system, and also the idea of having any more than say 12-15 machines backing up to such a low-performance array (i.e. 1250 IOPS max) would be asking for trouble. You'd have to be REALLY precise with the per-PC backup scheduling to ensure it didn't just time-out for everyone.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .