cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted

Client side Dedup, very slow to start backup

Hi !

sorry for my english, i'm french speaking.

Our Master (AIX), Media(Linux RH) and client(AIX) are running NB 8.1.1

When the config is set to "Always use ÙClient-side deduplication" for the client, the backup start BUT, before the writing is started, we can wait about 3 minutes...

...
2020-03-11 09:39:45 - Info {Media Server} (pid=97579) Using OpenStorage client direct to backup from client {Client} to {Media Server}
2020-03-11 09:43:07 - begin writing
2020-03-11 09:44:59 - Info bpbrm (pid=97547) from client {Client}: TRV - [/HNAS-NFS-AUTO] is on file system type autofs. Skipping
...

 

I did some test, always the same result.

Next, if I use the same client, same data to backup and change to "Always use the media server", the backup start immediately, no delay of 3 minutes.

...
2020-03-11 09:35:56 - Info bptm (pid=97062) backup child process is pid 97092
2020-03-11 09:35:56 - Info bpbrm (pid=97038) from client SFIBD4479.INTEGPP2.RQPES: TRV - [/HNAS-NFS-AUTO] is on file system type autofs. Skipping
2020-03-11 09:35:56 - begin writing
...

 

I checked the firewall, nothing from this side.  both, Media and client have this file set to "0" in the folder /usr/openv/netbackup/NET_BUFFER_SZ

 

If someone have any idea

 

Thanks for your help or hint

Tags (1)
6 Replies
Highlighted

Re: Client side Dedup, very slow to start backup

Do you have firewall in place that prevent communication on port 10082 and 10102 ?

NetBackup deduplication ports

https://www.veritas.com/support/en_US/doc/80731497-127431417-0/v124789758-127431417

Highlighted

Re: Client side Dedup, very slow to start backup

You should know that is normal, because generally client’s ressources are not the same as a media server.. (PCU, RAM..) and also if your client server is being used by a lot of users it impacts ressources which would simply impact the netbackup’s deduplication to start.
IMHO, 3 minutes isn’t really a problem if I may say..
You can run the job and monitor the client’s ressouces while the backup is running..
Good luck
Highlighted

Re: Client side Dedup, very slow to start backup

Hello,

what about backup time as a whole - I guess that with the client dedup the overall backup time is shorter, despite the slow start - is not? Then I won't worry about this detail..

Regards

Michal

 

Highlighted

Re: Client side Dedup, very slow to start backup

 For client-side dedupe the client has to verify segment fingerprints with the MSDP deduplication database; whilst I believe a proportion of existing fingerprints may be cached on the client, new data will require a round trip to the Media Server to check whether it already has the new data's fingerprints. I would expect this would cause a delay before "begin writing" can actually start, but as others have said, overall backup times should be shorter and the actual amount of data transferred will almost always be much less. I would not worry about this...

Andrew

Highlighted

Re: Client side Dedup, very slow to start backup

Hi there, just a couple of questions, re:

2020-03-11 09:39:45 - Info {Media Server}...
2020-03-11 09:43:07 - begin writing

...for selection path:  /HNAS-NFS-AUTO

.

1) When using client-side dedupe is the delay of 3m 22s always exactly the same duration or very nearly the same duration?

2) Is the problem only ever experienced by this one AIX backup client, or are many different clients that use client-side dedupe affected, or are all clients that use client-side dedupe affected?

3) Does the same or similar delay problem occur with a different path from the same AIX client?  i.e. does the same problem occur when the path is not an NFS mount from your HNAS?

.

Personally, I'm kind of with @andrew_mcc1 , because the "apparent" delay could just be a feature combination of "a large NFS structure" PLUS "not much changing from day-to-day" in so far as maybe it takes around three or more minutes for the client to walk the HNAS hosted folder structure before bpbkar finds anything new or changed that needs to be sent to the media server, and maybe it is only when the media server actually receives it first piece of backup data that the media server logs "begin writing".

Highlighted

Re: Client side Dedup, very slow to start backup

I'm sorry for the delay, I was out of office for long time.

I do a lot of test with client-side Dedup, always have this delay of 3-4 min. for 2 clients (both are in the same cluster).  All others clients work fine with same setting.  We have anothers AIX cluster and all clients work fine with client-side dedup.

This morning I tried to take only 1 file, /etc/passwd, same delay.  Taking 9 minutes overall for a backup of 32ko, it's a little bit huge

Thanks !

Tags (2)