Somewhere in the documentation it mentioned that File To Tape jobs should be kept to a minimum quantity of files (regardless of size). I think I ran into the reasoning recently.
The first run of my File to Tape job was obviously a full backup and ran as normal, but the second run (incremental)... it was well past 6 hours and still trying to process objects to protect.
In Veeam's defense, I should have known that my 567,000 files in the File to Tape job was not going to go well. However, during about the first two hours, network traffic was very high with the source server, so I assumed it was doing checksums or hashes to detect changes, but then the network traffic returned to normal and SQL Express (yes... express...) pegged one of my CPU cores for the next ~4 hours.
Is there anything I can do to improve performance? I believe the docs indicate to make multiple File to Tape jobs and this would remedy the issue; but the issue there is that I'm using Amazon Storage Gateway's VTL and tapes don't get transitioned to archive unless they're ejected.
For some strange reason, Amazon only allows the creation of virtual tapes for the VTL, at most 10 at a time... so an ejection after each of multiple jobs would be hard to manage as well.
Would multiple jobs work better the count of files? Is there anything else I can do to improve performance?
Thank you,
~Bill
-
- Expert
- Posts: 129
- Liked: 24 times
- Joined: Jul 12, 2016 12:51 pm
- Location: Vermont, U.S.A.
- Contact:
-
- Product Manager
- Posts: 20415
- Liked: 2302 times
- Joined: Oct 26, 2012 3:28 pm
- Full Name: Vladimir Eremin
- Contact:
Re: File To Tape Performance
I suspect SQL Express is the main cause here. Though, if I were you, I would log a support ticket just to confirm the environment and identify the main bottleneck before modifying the setup. Thanks!
Who is online
Users browsing this forum: No registered users and 22 guests