- Service Provider
- Posts: 13
- Liked: never
- Joined: Aug 11, 2017 9:09 pm
- Full Name: Matt Burnette
The issue here is the amount of data they have being sent to tapes.
As of today, they have over 118 million files @ 43.7 TBs.
Trying to send this all to tapes causes a lot of issues such as memory used on the VBR server, Veeam SQL growth, and the amount of files alone makes the jobs last days or weeks.
From what we can tell, there is no good way to use Veeam or Tapes to do what the client is trying to achieve though we wanted to post on here first to validate our findings.
As a note, the client chose file to tape instead of backup to tape so they could keep the files 'forever' with no rotation and never needing to send off another full or process GFS type jobs.
Has anyone used File to Tape jobs in this manner or have recommendations on how to improve this?
We have recommended several non-veeam options to accomplish this as well, if anyone has any input its also welcome.
- Veeam Software
- Posts: 5902
- Liked: 811 times
- Joined: Sep 01, 2014 11:46 am
- Location: Austria
for file to tape jobs, the SQL server is the bottleneck. So that's the thing where you can try some tuning
In general: Veeam is built for image based / block based backup and fast restore. File-to-tape was never planned or built for scale. So nobody from Veeam will recommend doing what your customer is trying.
NAS backup (to disk) with the next version will be built for scale (no NAS-to-tape support in the first version).
So the Veeam recommendation is to use image based backup or use a tool that is built for file-to-tape
Users browsing this forum: No registered users and 3 guests