Bad NDMP performance on NetApp

[tom.schmidt]

Hi there,
I would like to use NDMP for the backup of our NetApp's cifs shares, just for desaster recovery (no file level restore required).
I tried it, but with bad performance (about 160MB/s). Reason is the use of DUMP instead of SMTape. Are there any plans to implement SMTape? NAS backup is not an option, because we use the storage in a multi tenant environment and are not going to deploy a backup server in each client domain...

Using DUMP exceeds our backup window, we are talking about ~22M tiny files...

Greetings
Thomas

[Gostev]

No plans at this time.

NAS backup is not an option, because we use the storage in a multi tenant environment and are not going to deploy a backup server in each client domain...

Why do you think you need to do this?

[tom.schmidt]

Hi Gostev,

my understanding is, that I need to access the data via a share. All domains a seperated via firewall. Our security policies prohibit data transfer across domain borders or servers with multiple interfaces bridging these networks. So no direct access possible. SMTape would help in this case; the backup would only be for desaster recovery, restore would be much faster also.

Greetings
Thomas

[Dima P.]

Thomas,

During NDMP backup to tape data is transferred via the NDMP gateway server to the tape proxy server and then from the tape proxy to the actual tape library. By the way you can install gateway component and tape server component on the same machine, then traffic will be isolated within this specific machine.

P.S. Moved this discussion to tape subforum.

[tom.schmidt]

Hi Dima,

that is not the problem. I see two possibilties:
- Do backup via NDMP -> No implementation of SMTape -> extrem slow backup (~80 MB/s, bottleneck is source because NDMP has to access every single file, where SMTape would backup the whole volume as one file)

- Use NAS-Backup -> access to the shares in multiple AD-domains is needed. Our policy prohibits access from one server to all domains; so multiple servers are needed. Restore would be slow too, because one has to restore millions of files....

SMTape is the solution for DR only, which is just what we need.

Greetings
Thomas

[Dima P.]

We will discuss it with the team, but as Anton mentioned, we do not have any short term plans to enhance NDMP support. Thanks for the feedback Thomas!

[tom.schmidt]

Hi Dima,

your response made me a bit sad...
IMHO you would only implement "DUMP" over "SMTape" if you intend to do FLR, which Veeam does not support (for obvious reasons). I totally unterstand, that "DUMP" is the universal method which would function on almpost any devise supporting NDMP. On the other hand, the advantages of SMTape a huge (e.g. backing up all your snapshots). In the current state we are not able to meet our RTO and will have a look at other solutions (which I hoped to avoid).

Greetings
Thomas

[Dima P.]

Hello Thomas,

I am sorry to upset you, but for now I can only promise to discuss it with the team. Thank you!

[bRogg]

Hello,
we have the same issue (since VEEAM 11 A) - performance is dropped from several hundred MB/s to 80 MB/s.

Tested against several NetApp filers - tested with several Veeam servers (running on 11A) - in all Scenarios we're having 80 MB/s (incl. DisableHtAsyncIo = 1 and UseUnbufferedAccess = 0 set - and also not set)

After that I tested in the same scenario with VEEAM 11 (build: 11.0.0.837_20210507) - the performance is back at 400MB/s.

I have also a VEEAM case: 05112017
Cheers

[HannesK]

Hello Bernhard,
welcome to the forums. I just escalated that case for further investigations.

It looks like a bug if something becomes 5x slower after an upgrade. The two reg keys should be irrelevant for that situation.

Best regards,
Hannes

[HannesK]

Bernhard, you please open a new case and add logs to that case? Unfortunately, the old logs in the old case were already deleted from the support servers.

The escalation engineer told me, that the behavior is probably related to issue 351150 and new logs should clarify that situation. If you post the case number here, I can route it though support to get to the correct engineer.