Forum Discussion

laguns97's avatar
laguns97
Level 4
5 years ago

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

AIX

9 Replies

Sort By
  • Hamza_H's avatar
    Hamza_H
    Moderator
    5 years ago
    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
    • Michal_Mikulik1's avatar
      Michal_Mikulik1
      Moderator
      5 years ago

      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

       

      • andrew_mcc1's avatar
        andrew_mcc1
        Level 6
        5 years ago

         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

  • sdo's avatar
    sdo
    Moderator
    5 years ago

    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".

    • laguns97's avatar
      laguns97
      Level 4
      5 years ago

      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 !

  • alpes38's avatar
    alpes38
    Level 3
    3 years ago

    Hi,

    We are seeing the same malfunction in 8.3.0.1 on some clients.
    Has anyone found the source of this problem.

    Thank you.

     

  • alpes38's avatar
    alpes38
    Level 3
    3 years ago

    here is an example
    we lose 3 min before writing and 2 minutes after!

    26 mai 2022 20:33:04 - connected; connect time: 0:00:00
    26 mai 2022 20:33:05 - Info bptm (pid=259454) using 262144 data buffer size
    26 mai 2022 20:33:05 - Info bptm (pid=259454) using 16 data buffers
    26 mai 2022 20:33:05 - Info msdpname (pid=259454) Using OpenStorage client direct to backup from client clientname to msdpname
    26 mai 2022 20:36:13 - begin writing
    26 mai 2022 20:36:19 - Info dbclient (pid=38921) dbclient(pid=38921) wrote first buffer(size=262144)
    26 mai 2022 20:40:31 - Info dbclient (pid=38921) done. status: 0
    26 mai 2022 20:42:26 - Info msdpname (pid=259454) StorageServer=PureDisk:msdpname; Report=PDDO Stats (multi-threaded stream used) for (msdpname): scanned: 69408 KB, CR sent: 17894 KB, CR sent over FC: 0 KB, dedup: 74.2%, cache hits: 1 (0.2%), where dedup space saving:0.0%, compression space saving:74.2%
    26 mai 2022 20:42:27 - Info msdpname (pid=259454) Using the media server to write NetBackup data for backup clientname_1653589973 to msdpname
    26 mai 2022 20:42:29 - Info bptm (pid=259454) EXITING with status 0 <----------

  • alpes38's avatar
    alpes38
    Level 3
    8 months ago

    Hi, we have the same pb in 10.3.

    We use a single policy to backup each Oracle and SAP database with a dedicated archivelog schedule.
    On some servers we actually lose 3 or 4 minutes for each archivelog backup.
    Is there a solution to reduce this 3 or 4 minutes delay?

     

    Many thanks.