Backup volumes are show as RAW

[Tutek]

Hi,
I have to change connection on my QNAP to LACP, after that on veeam iscsi volume is shown as RAW, I was trying to disconnect it then connect again using iscsi inictiator, but when open this i get an error: v:\ is not accessible
The volumen repair was not successful.

[PetrM]

Hello,

If you see the error when you're trying to browse the file system in Windows Explorer, then it looks like an issue related to the environment and I don't think that there is a way to handle it at the level of our product. I guess it's worth asking this question on similar QNAP Community forums, maybe you'll get some ideas for troubleshooting there.

Thanks!

[Tutek]

if ReFS is so problematic that any small NAS reconfiguration can ruin all volume, so I'm right now revert back all my connected to Veeam volumes to NFTS, It's definitely better for me to keep my head calm rather to have performance improvements from unreliable ReFS.
In addition I must say that my Veaam is placed on win server 2019, not 2016.

[Tutek]

now I see on event viewer system section that for a few days I have these errors:
The file system detected a checksum error and was not able to correct it. The name of the file or folder is "Object ID Table".
The file system detected a checksum error and was not able to correct it. The name of the file or folder is "Duplicate Object ID Table".
The file system detected a global metadata corruption and was not able to repair it on volume V:. Attempting a readonly volume mount may succeed.
Volume V: is formatted as ReFS but ReFS is unable to mount it; ReFS encountered status The volume repair was not successful..

what could cause these errors? I see that QNAP nas didn't have any power failure.

[Mildur]

There are multiple possibilities for getting a corrupted refs Partition.
Power failure is one thing.

We have also seen raw disks on time from mishandling the iscsi LUN by IT staff.
They have connected it to two different windows server at the same time. Wasn’t a good idea, partition was corrupted after that.
I think it's also a possibility that network glitch can lead to a corrupted filesystem on the iscsi LUN.
Or a bad raid controller in the NAS.

Are you using backup copy jobs to create a second copy of your backups? Silent data corruption can always happen to the best filesystem. A second copy by veeams famous 3-2-1 is your savior in need, if that happens again.

[PetrM]

Adding my 2 cents: I believe that you could also contact your storage vendor to check if these errors are provoked by hardware malfunction and probably look for an answer on Microsoft Community Forums. By the way, the shared LUN concept with ReFS is not recommended according to our best practices.

Thanks!

[Mildur]

The shared lun was a mistake. it was accidentally connected to the old backup server while the new one was already connected. This was not on purpose

[Gostev]

what could cause these errors? I see that QNAP nas didn't have any power failure.

Low end NAS devices are in general quite unreliable due to not carrying enterprise-grade RAID controllers. They have been the top source of data corruptions in our support well before ReFS was a thing. This is why Veeam highly recommends using general-purpose servers with internal or direct attached storage for backup repositories.

[Tutek]

The shared lun was a mistake. it was accidentally connected to the old backup server while the new one was already connected. This was not on purpose

I don't understand what you mean shared LUN, I created one LUN on QNAP created autohorization to it, then I connected this lun only to windows server 2019 with veeam, I didn't connect this lun to any other server. So what you mean shared lun?
I checked ReFS driver on my windows 2019 and is 10.0.17763.1432 - so it's OK.

[Mildur]

Shared Between two windows servers. The lun was connected in my case to a win 2016 and win2019 the same time.

[Tutek]

as I stated, I had qnap lun connected only to windows server 2019 with veem, nothing more.
Now I read that is not recommended to use LACP on NAS which store LUN with RefS file system, could anyone confirm that?

[Mildur]

With iscsi Protocol, you should use MPIO (Multipath), not LACP.

http://files.qnap.com/news/pressresourc ... g_MPIO.pdf

[krakhger]

Hi,
I ran into a similiar issue, but not on the backup repository but on the main data store.
This saved my data..

https://andrewyager.com/2019/04/21/refs ... dows-2019/
Maybe it helps in that case.
Gerhard