Discussions related to exporting backups to tape and backing up directly to tape.
Post Reply
MBT
Lurker
Posts: 2
Liked: never
Joined: Aug 14, 2017 9:45 am
Full Name: MB&T Technik
Contact:

Tape backup taking extremely long

Post by MBT »

Hi!

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
Problem:
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?).

Question:
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 ;-)

Thx,
Alex
Dima P.
Product Manager
Posts: 14417
Liked: 1576 times
Joined: Feb 04, 2013 2:07 pm
Full Name: Dmitry Popov
Location: Prague
Contact:

Re: Tape backup taking extremely long

Post by Dima P. »

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.
MBT
Lurker
Posts: 2
Liked: never
Joined: Aug 14, 2017 9:45 am
Full Name: MB&T Technik
Contact:

Re: Tape backup taking extremely long

Post by MBT »

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?

Thanks,
Alex
Post Reply

Who is online

Users browsing this forum: No registered users and 16 guests