Pick holes in my Veeam storage architecture

[stevehughes]

I'm looking to lean on the real-life experiences of others here.

We are an MSP and manage onsite backups for our clients. Several of our sites run a dedicated box for Veeam, with the server, proxy and at least the daytime backup repository all local to the machine. Very often this is the customer's previous generation server if it is still serviceable. We often don't have space on this box for retention, and so use an iSCSI-connected QNAP NAS, formatted ReFS, as a retention datastore, and we run backup copy jobs to this iSCSI storage.

We are getting fairly frequent corruption of the backups on the retention repository. The retention repository works pretty hard when rollups occur, and I'm starting to think that having ReFS sitting atop an iSCSI-connected volume is a bad idea, at least when a low-end NAS is used as the iSCSI target.

Any thoughts?

Thanks,
Steve

[nielsengelen]

In regards to ReFS, there is a topic about this which I suggest you should dig into veeam-backup-replication-f2/refs-state- ... ml#p299340

About the NAS boxes, could you clarify a bit more on the setup underneath (RAID setup, type of disks)? In regards to the iSCSI connection, are we talking about 1Gbit or 10Gbit connectivity?

[stevehughes]

Thanks. I read that. Its a 4-disk NAS using RAID-5 over a bunch of WD Reds or Seagate IronWolfs. 1G connectivity. The QNAPs give the option of using file-based or block-based storage under the iSCSI LUN, and we are using file-based unfortunately. I imagine block-based would be more robust, but I suspect our problems are larger than the choice of file/block.

[nielsengelen]

While the setup sounds like it should be handle everything, I can't really tell where the corruption comes from. How frequently does this happen? Did you already contact our support when it happens for insight? Is the corruption within VBR or is it due to for example a raid rebuild/external factor?