Skip to main content
Question

Feedback needed to evolve our backup repository

  • July 29, 2026
  • 1 comment
  • 14 views
P

Hello everyone,

I'm reaching out today because we're experiencing performance issues with our Veeam backups. More specifically, I find that both the incremental backup duration and the Synthetic Full backup duration are extremely long.

Here's a quick overview of our current physical infrastructure:

  • Veeam Backup Server running as a virtual machine (connected at 10 Gbps) - 13.0.2.29
  • Backup Repository: Synology RS2418+ (Intel Atom C3538, 4 GB RAM, no SSD cache, connected at 10 Gbps)
  • Disks:
    • Disk 1: WDC WD80EFAX-68KNBN0
    • Disk 2: WDC WD80EFAX-68KNBN0
    • Disk 3: WDC WD80EFAX-68KNBN0
    • Disk 4: WDC WD80EFAX-68KNBN0
    • Disk 5: WDC WD80EFPX-68C4ZN0 (recently added, hence the different model)

For every backup job, the bottleneck consistently shows "Target".

Backup configuration

We currently have two backup jobs:

Job 1

  • Selected production servers
  • Incremental backups: Monday to Friday, starting at 7:00 PM
  • Synthetic Full: Saturday (same start time, as it's not possible to schedule a Synthetic Full earlier than the job schedule)

Job 2

  • Remaining production servers
  • Incremental backups: Monday to Friday, starting at 10:00 PM
  • Synthetic Full: Saturday (same start time for the same reason)

Normal incremental backup reports

Job 1:

Job 2:

 

Normal Synthetic Full reports

Job 1:

 

Job 2:

Synthetic Full report from this weekend

This week's Synthetic Full took even longer because the previous weekend's Synthetic Full could not complete. Even taking that into account, I still find the execution time excessive.

Job 1:

Job 2:

My questions

  1. Until we replace our hardware (planned in approximately six months), what can we do to improve backup performance?

Our production environment is business-critical, so the Synthetic Full must not extend into Monday. When it does, our production systems experience noticeable slowdowns.

  1. When we replace the infrastructure, what type of backup repository would you recommend?

Would it be better to use:

  • a physical Veeam Backup Server with directly attached storage,
  • a DAS (Direct Attached Storage),
  • or another architecture?

What are the current best practices for a Veeam backup repository?

Thank you very much for your feedback and recommendations. I appreciate any advice you can provide and will take all suggestions into consideration.

    1 comment

    D
    Forum|alt.badge.img+3
    • ddomask
    • Veeam Product Management
    • July 30, 2026

    Hi Pierre, 

    With SMB, Target bottleneck usually means writing from gateway to the share itself, so testing from the gateway that was used is ideal. 

    Don’t use a file copy for this, modern OSes do some tricks to speed up file copies and it’s better to use Diskspd and target a path on the share that you can write to. Test with a relatively large file (25 GiB or larger) and try using both the Active Full and the Synthetic Full options from the test page there.

    If you’re seeing similar speeds to the backup, there’s unfortunately not much you can do.

    Synthetic operations (Synthetic Full, Forever Forward Incremental merge) are very IO heavy (multiple reads for each write) and with SMB, that means that the data needs to go out to the gateway first then back to the SMB share to complete the write; very likely, this is why synthetics are not performant for you. Best you can do is avoid synthetic operations entirely by switching to periodic active fulls.

    As for what to replace with, heavily depends on your needs and available resources -- a dedicated repository server with directly attached storage tends to be recommended, but with the current hardware crunch of course that may not be feasible, but if you can manage it, a Hardened Repository deployed from the Veeam Infrastructure Appliance is likely best, just ensure that the hardware you get for it is on the RHEL certified hardware list if it’s a dedicated physical machine. VMs are typically not recommended for your repository but it is possible.

    Will let others discuss the replacement options (and if you can share more about what your replacement hardware will be people can better advise), but for the current issue with poor performance, I recommend first test with Diskspd as per the article to get an idea on the performance you can expect; the article includes the flags necessary to replicate the IO pattern Veeam uses, so it will be pretty close to what you can expect with Veeam.

    0x0D 0x0A
    Terms & ConditionsAccessibility statement