moving 80+ TB to Tape using 1 GFS tape job, Takes 3 DAYS TO COMPLETE. is there a better way?

The other way would be to split the data to separate jobs for backup.  Sending that much via one job would take long as you have shown.

Regrettably there is no means to utilize multiple drives for a single backup, so that larger FileServer will tie up one of the drives while it writes. At max drive speed for LTO8 that’s at least 33 hours.

I would advise against the periodic fulls to disk, it won’t meaningfully help here with the tape-out, and in fact, Virtual Full backups for tape are typically faster than direct copies of full backups (and you save storage space as well)

Few suggestions:

1. Check the bottleneck on the job -- you mention your two drives typically max out at 540 MB/s, but likely you can eke out some more here (360 per drive is max)
   1. If bottleneck is tape drives, then test with a full write test (without compression) with your tape vendor’s native tools, see if they reach closer to peak
   2. If bottleneck is elsewhere, best to investigate with Veeam Support to determine why the bottleneck is happening
2. You won’t be able to do much easily to fix the initial full backup of the File Server, but subsequent fulls are best served by Virtual Full Backups for Tape
   1. You will still be limited to one drive here, but Virtual Full should reduce if not eliminate source as bottleneck

Outside of that, only thing I can think of is more drastic, and it involves changing how you backup the File Server. If the fileserver has multiple disks that can be backed up independently of each other (i.e., not spanned disks), then you can do the following:

1. N primary backup jobs for N disks you want to protect, include only the desired disk
   1. Name the jobs appropriately
2. Add each primary job as a source job to the tape job
3. Enable parallel processing in the media pool the tape job will use

This will let you “split” the workload across the two tape drives a bit more easily, but naturally this means recovery is a bit more of a pain since each job only has one disk, so you would only do disk restores or file level restores effectively. In a full DR event for the FileServer, restore the OS disk to a VM, then restore the individual disks from each backup.

I would do it like this:

1 – Move GFS creation to disk

2 – Use Tape Copy Jobs (not GFS from repository)

3 – Split workloads strategically

4 – Improve tape drive utilization

Investing in 10 Gbps L3 switches and setting up trunks that can span across multiple ports.    I would do 40-100 Gbps Trunk.  You will need multiple LTO 9 tape drives to handle that much bandwidth.

Our data center at work has 120 Gbps (12 x 10 Gbps NICs) in a team.   The tape server have 3 LTO 5 tape drives with 6 x 10 Gbps NICs (one on each subnet).   Each tape drive can get 7-8 GB/min backup performance.   You could go to even faster networking.  I have heard of 100 Gbps L3 switches.  Way above our budget.

Damn that is some speed for tape.  🫪

It is all due to the 60 Gbps NICs that are split between subnets.   

​@knorman I would double-check the library itself to verify whether the drives are working properly. Try using the library tools to simulate a workload and check if the library is performing as expected. If you have an HPE library, you can use the Library and Tape Tools (L&TT).