Tape backup taking extremely long

Discussions specific to tape backups

Tape backup taking extremely long

Veeam Logoby MBT » Mon Aug 14, 2017 11:12 am


We have implemented a new backup system for a client of ours. They insisted to have a LTO-06 tape backup as part of their strategy as they are used to handling tapes. Problem is, that tape backup jobs take literally ages and the customer cannot swap tapes as they (and we'd) like to.

Current setup:
  • dedicated VBR Enterprise host (physical, Windows 10 Pro, i5-7400, 16 GB RAM) with default Veeam Backup Proxy, internal LTO-06 SAS drive
  • dedicated Synology RS815RP+ NAS, 4 x Seagate 2.7 TB HDD for VBR repository (CIFS)

Backup Jobs:
  • Hyper-V Backup with 5 VMs, inremental, "configure secondary destination for this job" is checked and backup to tape jobs are set as secondary target, advanced settings are set to recommended settings
  • 4 x Veeam Agent for Windows 2.0 on Windows Server hosts, set to use the VBR host as backup server and its Veeam backup repository on NAS, rest set to default

The primary backup jobs run rather fine.
Problem is when the backup to tape jobs starts. E.g. for one of the agent backups it currently stands at 97% after 12:30 hours with 620 GB processed at 14 MB/s. Looking at the NAS while this part of the tape backup runs, it shows that the volume is at 100% load which, I guess, has to do with lots of movement from the disks' heads (fragmentation?).

What can we configure differently to speed up the tape job?
Our client wants to have a current copy of all full backups on each tape. Ideally - as they are used to this - they would like to have one complete tape backup every day (Mon - Sat). But they'd also be okay with swapping tapes every Mondays at 10 a.m. - if only we coukd make sure it's done by that time and noone had to wait hours for the job to finish, etc.
If possible we'd like to keep the daily full tape backup, but of course it has to be on time every day. They drive to office on Saturdays just to swap tapes. Sitting around waiting hours for a job to complete is no option there ;-)

Posts: 2
Liked: never
Joined: Mon Aug 14, 2017 9:45 am
Full Name: MB&T Technik

Re: Tape backup taking extremely long

Veeam Logoby Dima P. » Thu Aug 17, 2017 6:34 pm

Hello and welcome to the community Alex,

What are the bottleneck stats for your tape job? Are you using encryption (any chance on both source jobs and tape job)? Thanks in advance.
Dima P.
Veeam Software
Posts: 8206
Liked: 588 times
Joined: Mon Feb 04, 2013 2:07 pm
Location: Prague
Full Name: Dmitry Popov

Re: Tape backup taking extremely long

Veeam Logoby MBT » Fri Aug 18, 2017 8:51 am

Hi and thanks, Dima!

The stats are: Source 90% > Proxy 30% > Network 19% > Target 26%
We don't use encryption anywhere in this setup.

Our customer was on holiday this week and wants to see some results when he's back next week. Understandably because having a working backup is critical and we've been tweaking for weeks with no breakthrough, we disabled all jobs, set up new ones and changed the scenario:

We tweaked the whole timing of the daily jobs of the agents and hyper-v. Backup remains incremental but with a active full on Friday. We took some measurements while running active fulls to get their timing when only one job is active at a time and were rather pleased.
We rescheduled the daily tape job to work just an Saturday after the Friday active full backups have run.

My hope is, that the tape job on Saturday morning just takes the Friday active fulls and copies them on tape without having to create a synthetic full backup again. But I read somewhere in this forum that this may not be the case, because the tape job does only use the last full backup if it is from a job from the same day. Sounds weird.. we'll have more on that on Sunday I guess.

We'll see if this satisfies our client because - as I stated - he initially wanted full backups on tpye six days a week in perfect timing. But I just don't see a way to make it work.

What irritates me right now is that we decreased retention on the jobs but the runs last night did not delete the old VIB and VBK files.
E.g. on one agent I set retention from 60 to 7. I manually ran an active full yesterday afternoon and the job did a regular incremental yesterday evening. But there's still 43 files dating back to July in the repository. Isn't the scheduled run after decreasing retention supposed to delete the old files?
Do I have to / will it work without breaking something to manually delete the VBK and VIB files from before the last active full backup?

Posts: 2
Liked: never
Joined: Mon Aug 14, 2017 9:45 am
Full Name: MB&T Technik

Return to Tape

Who is online

Users browsing this forum: No registered users and 16 guests