Forum Discussion

twshelpdesk's avatar
twshelpdesk
Level 4
8 years ago

BackupExec 2014 - Incremental Backup jobs much slower than full backups

Hi,

I have a simple backup job in BackupExec 2014 which copies some veeam .vbk backup files to tape.  In total there are probably around 10 files, but the total file size is around 1.4TB

What I am finding is that if I run a full backup, the job rate is around 6500 MB/Min and completed in around 6hrs 30mins..

When the incremental backup runs (all the same files update so the incremental backup is essentially the same set of files as the full backup), the job is a lot slower and the job rate drops to around 2400 MB/Min (taking around 12hrs 30mins to complete).

Is there any reason this might be happening?

I realise that I could switch my backup job to a Full backup ever night, but occasionally Veeam also does an active full backup which results in a duplicate .vbk file which could be up to 1TB in size and.  I dont want to be backing this up everynight as well, so this is why I am trying to use an incremental backup.

backupexec
  • DarthBilly's avatar
    DarthBilly
    Level 5
    8 years ago

    Since there are ten files, have you tried to determine if it's a specific file that's causing the slowdown? Are you sure that veeam is not writing to one of them during the incremental backup?

    Try creating a couple of different backups for the files and see if there's a specific file that Backup Exec is getting hung up on. Also try using Backup Exec instead of veeam all together. We can protect VMs :)

    • twshelpdesk's avatar
      twshelpdesk
      Level 4
      8 years ago

      I have decided that I am just going to use Full backups's instead on incrementals as this just works so much better.  I presume it must be something to do with all the incremental handles the files differently.

       

      I was trying to avoid it, but I will just have to manually deselect the additional .vbk which Veeam produces when it runs its full active backup.

       

      Thanks anyway, but I think this can be marked as resolved.