Best NAS Server for VEEAM ?

[umenz]

Hello Community,

i have configured a VEEAM 6.5 Backup Job to a Synology NAS device (24x2TB) via 2 GB links connected. Use a Proxy with 4 vCPU and Backing up local DAS Attached RAIDs (14TB).
At the Backup Job it shows Target 95%, all other 5-10%, the troughput is "only" 35MB/s on the Network with no peaks.

A Replication Jobs from one Host to another Host loads the Network up to 90MB/s (read >150MB/s)

If I log in to the VEEAM VM and mount the Backup share and copy some Files: over 115MB/s is possible continously, (150MB/s peaks)

Why is the Backup Job mutch slower ?
Is VEEAM slow accessing a SMB Share ? or is it a Synology typically result, - I haved useed Synology at other sites too and get the same results.
Can everybody confirm this or not ? Is more througput possible ?

thanks

Ulrich

[nickr]

You didn't say which backup mode you're using, but If you're using reverse incremental backups, that could be your problem. Reverse Incremental uses a lot of random read/writes and has to build an entire new full backup file each time it runs. Unlike a standard incremental job which only builds a single incremental change file on each run.

I've learned not to use reverse incremental for large backup jobs.

We use a similar setup, but use a QNAP TS-1679U-RP NAS with two bonded NIC's.

[umenz]

Hello Nick,

yes, Reverse Incremental is used. My opinon was that this process runs after a Backup Job.

Thanks Ulrich

[dellock6]

Hi Ulrich, no reverse calculation is part of the backup job, and it uses 3 times the I/O of a forward incremental. Bottleneck on target is totally expected, and it could be a real pain on small/medium NAS. Have a look at this paper I wrote about it:

Veeam backup methods and the impact on destination storage I/O

To get a fair comparison with your copy task, try to switch to forward incremental, you will see for sure higher numbers.

Luca.

[umenz]

Hi Luca,

thanks for the illustration. its more complex.
I learnd now that Rev Inkr ist slower, but a important thing is the Restore time if i need a complete restore.

this year we need a restore of 9 TB and it runs 50h from a reversed Backup.
The desaster was 2 Days offline. So we can´t risk a mutch longer time with inkrementals Backups.
In this case we must life with slow Backup and "fast" restores.

The Problem of long Backuptimes ist only that Snaspots has a livetime up to 24 hours while Backup and the volumes running out off space in times with high loads. I have add more freespace but the risk is not eleminated.

thanks
Ulrich

[dellock6]

About your numbers, that means 50 MB per second, is somewhat expected especially for a 9 TB VM. Have you considered using Instant VM Recovery to speed up restore times? A VM can be powered on from backup in few minutes even if it's that large, and then you can move it to production storage with ease, even if it is going to take you 50 hrs, via storage vmotion (if you have the license) or via quick migration (included in Veeam regardless of VMware license).

Luca.

[umenz]

don´t have experence with Instant Recovery, the buffer for writes must contain up to 1TB (10%) capacity, i think. In this case in the past it was 100GB free on this VMs NFS. The switchover to normal production must be possible. My tests with VEEAM V5 fails. possible with the actual release ?.

In the Case above it was filled with 9.5TB SQL Data on a 14TB Store.
Problem ist the SQL Server can write so many blocks in a short timeframe. The Blocksize for a changed block in a snapshot file is 16MB I think (right ?). So random writes can produce havy capacitys they will be synced back after in hours and hours. I have calculated <24h to full restore but 50h was the fact.

The initinal problem was the replication has stopped by getting out of space. After this the snapshotsize has occoured the crash of the source system... an so on..
I decide a full restore and have a clean system. But next problem was the Backup runs faster with BackupProxys than the restore that has no optimizing and runs mutch longer.

At the next firedrill lab i will test run a big vm with instant restore. did you have proceed this ?

Ulrich

[dellock6]

Uhm, reading at your last post, my doubts are a virtual proxy with attached vPower NFS can sustain an Instant Recovery of a SQL Server that big, and probably also the Qnap is maybe not the best choice for such a heavy VM to be saved and restored.
All your questions are correct, with a virtual proxy directly attached to a qnap, NFS will be executed by the Veeam server itself, how is configured this VM? Or is the same as the proxy with 4 vCPU? How much RAM? And how much ram has the original SQL server?
At least for write redirection, you can choose directly a VMFS datastore instead of the vNFS.

Luca.