Hi,
Is a ReFS volume on an iSCSI LUN hosted from a Synology NAS a good thing to do?
The reason for this is to gain performance by utilizing faster synthetic fulls.
It's a fairly strong NAS with four 2.1Ghz atom cores and 12x8TB drives.
Kind regards,
Bastiaan
-
- Service Provider
- Posts: 880
- Liked: 164 times
- Joined: Aug 26, 2013 7:46 am
- Full Name: Bastiaan van Haastrecht
- Location: The Netherlands
- Contact:
ReFS on iSCSI LUN hosted on a NAS
======================================================
Veeam ProPartner, Service Provider and a proud Veeam Legend
Veeam ProPartner, Service Provider and a proud Veeam Legend
-
- Veeam Software
- Posts: 3626
- Liked: 608 times
- Joined: Aug 28, 2013 8:23 am
- Full Name: Petr Makarov
- Location: Prague, Czech Republic
- Contact:
Re: ReFS on iSCSI LUN hosted on a NAS
Hi Bastiaan,
I don't see a problem with that as long as it is supported by Synology, at least it's recommended to confirm details with the storage vendor, here is an article from Microsoft.
According to this post, the configuration with iSCSI LUN is stable enough but if I'm not mistaken there was an issue with possible data corruption when Write Cache was enabled. There is an example on Synology forums, I believe your question worth asking there as well.
Thanks!
I don't see a problem with that as long as it is supported by Synology, at least it's recommended to confirm details with the storage vendor, here is an article from Microsoft.
According to this post, the configuration with iSCSI LUN is stable enough but if I'm not mistaken there was an issue with possible data corruption when Write Cache was enabled. There is an example on Synology forums, I believe your question worth asking there as well.
Thanks!
-
- Chief Product Officer
- Posts: 31807
- Liked: 7300 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: ReFS on iSCSI LUN hosted on a NAS
It is certainly a way better than using SMB, from every perspective but still not as ideal comparing to using a general-purpose server with internal or direct attached storage. I covered this in details in one of my newsletters last fall, but here's a shorter summary of that story that I had to make for my Reddit post on the same exact subject a few days ago:
Yes, moving to iSCSI completely removes the chance of data corruption in the SMB stack specifically.
You can then further improve reliability by enabling iSCSI header and data digests in the SAN settings. This will address the majority of data corruption/loss events which may happen to data in transit due to faulty network equipment, which are fairly common too. This however still leaves the possibility for corruptions to occur during the protocol crossover between Ethernet, TCP and iSCSI.
This is why it is so important to have integrity checking as a part of a higher-level protocol, as is the case with Veeam's proprietary data movement protocol. Which in turn makes general-purpose servers with internal storage the best possible candidate for a backup repository in terms of reliability. Because as soon as data is stored on some other box, it has to travel there over the network, at which point Veeam loses control over it and is no longer able to ensure its integrity.
Yes, moving to iSCSI completely removes the chance of data corruption in the SMB stack specifically.
You can then further improve reliability by enabling iSCSI header and data digests in the SAN settings. This will address the majority of data corruption/loss events which may happen to data in transit due to faulty network equipment, which are fairly common too. This however still leaves the possibility for corruptions to occur during the protocol crossover between Ethernet, TCP and iSCSI.
This is why it is so important to have integrity checking as a part of a higher-level protocol, as is the case with Veeam's proprietary data movement protocol. Which in turn makes general-purpose servers with internal storage the best possible candidate for a backup repository in terms of reliability. Because as soon as data is stored on some other box, it has to travel there over the network, at which point Veeam loses control over it and is no longer able to ensure its integrity.
Who is online
Users browsing this forum: c.guerin, Google [Bot] and 296 guests