Forum Discussion

Andre_Torres's avatar
12 years ago

Backup taking too long time to complete

Hi everyone, here I am again,

 

One of my clients, is having a problem since version 7.0. We upgraded to 7.1.0.3 last year, and now to 7.5.0.4 and the problem doesn't solve. Already tried Symantec Support, even they could not solve the problem.

 

The problem is, we have two File Servers, about 1.4TB each, the two take about 40 hours each to complete full backup, working with 3 drives simultaneously. The Client is running on a SuSe 10 SP3. The strange thing is that this problem only occurs on the full backup, on incremental backup, it doesn't happen.

 

In attachment I'm putting the job details of last full backup.

  •  

    Info bptm (pid=865) waited for full buffer 171902
    times, delayed 190773 times

    What we see above is that NBU was waiting for data. Either slow read speed from disk on the client or slow network.

    Filesystems on file server  normally get very fragmented over time, which causes slow read performance when entire filesystem needs to backed up.

    See this recent discussion for ways to test disk read spead as well as network performance. 
    https://www-secure.symantec.com/connect/forums/taking-too-long-time-finish-backup

    We have manged to speed up backups for customers with similar issues by enabling multiple data streams in Policy attributes.

    If you do the same, separate backup jobs for each of these folders will be generated:

     

    /media/nss/SYS_K1/
    /media/nss/VOL1/
    /media/nss/VOL2/
    /media/nss/IPRINT/
    /backup/

    You need to ensure that 'max jobs per client is set to 5, change MPX in schedules to 5, ensure MPX in STU is set to 5.

    This will kick off 5 jobs, all writing to the same tape drive. 
    One of our customers divided job into 8 streams. Backups that used to run from Friday night into working hours on Monday morning completed early hours on Saturday morning.

    PLEASE only do this when FULL backup is due, otherwise INC will run as full.

9 Replies

Replies have been turned off for this discussion
  • Hi,

    First check in that the file backedup on Archive based or Time stamp. IF salect Archive bit then salect time stamp.

     

    And if possible please share policy snap.

  • Do you use multiplexing?

    That can prevent drive slow down and / or shoe shining

    I am wondering if your incremental schedules use multiplexing and so are efficient but your full schedules do not and so tend to shoe-shine the tape drives and slow your jobs down

  • One thing I forgot to tell, is that the full backup and incremental backup uses diferent policies.

     

    How do I enable multiplexing?

  • How do I change from archive based to time stamp?

     

    in attachment is the print of atributes.

  •  

    Info bptm (pid=865) waited for full buffer 171902
    times, delayed 190773 times

    What we see above is that NBU was waiting for data. Either slow read speed from disk on the client or slow network.

    Filesystems on file server  normally get very fragmented over time, which causes slow read performance when entire filesystem needs to backed up.

    See this recent discussion for ways to test disk read spead as well as network performance. 
    https://www-secure.symantec.com/connect/forums/taking-too-long-time-finish-backup

    We have manged to speed up backups for customers with similar issues by enabling multiple data streams in Policy attributes.

    If you do the same, separate backup jobs for each of these folders will be generated:

     

    /media/nss/SYS_K1/
    /media/nss/VOL1/
    /media/nss/VOL2/
    /media/nss/IPRINT/
    /backup/

    You need to ensure that 'max jobs per client is set to 5, change MPX in schedules to 5, ensure MPX in STU is set to 5.

    This will kick off 5 jobs, all writing to the same tape drive. 
    One of our customers divided job into 8 streams. Backups that used to run from Friday night into working hours on Monday morning completed early hours on Saturday morning.

    PLEASE only do this when FULL backup is due, otherwise INC will run as full.

  • You should not have a full and incremental schedules in different policies - they must be in the same policy otherwise the incremental will always run as a full

    To use multiplexing enable it on the storage unit (set a figure such as six - which tends to work well) and then also enable it in each schedule tab

  • So, it is already divided in 2 data streams each server.

     

    MPX is multiplexing?

  • Correct. MPX = multiplexing.

    You need to generate more simultaneous streams on the client.

    Check Master Server -> Host Properties -> Master -> Global Attributes -> Max Jobs per Client. This should be between 4 and 8.

    BTW - your client is Linux. Incrementals are based on Timestamp.

  • One thing I forgot to tell, is that the full backup and incremental backup uses diferent policies.

    Full and Incremental schedules must be in the SAME policy. Having them in different policies will cause Incrementals to run as Full.