Veeam DB size for a File2tape job compared to V10 NAS backup

[sandsturm]

Hi

Currenly, we're using Veeam file2tape jobs to backup our SMB fileshares from the Netapp storagesystem to tape. The Veeam DB gets huge with these file2tape jobs, maybe due to the indexdata, I don't know. My question now is: Is the Veeam DB smaller, if we would implement the V10 NAS backup instead of the file2tape job, to backup the Netapp SMB shares to a Veeam Disk repository and copy these backup data in a second step to tape?

thx a lot
sandsturm

[Gostev]

The answer is yes: if you use v10 NAS backup, Veeam DB will be very small as it will no longer store the File to Tape job catalog.

However, you cannot copy v10 NAS backups to tape reliably, as this engine is built for D2D backups - and is not compatible with basic tape out. You would need to ensure NAS backup and tape out jobs never overlap, which I assume will be hard to achieve with your data size. Because whenever they do overlap, you will end up with an inconsistent and unrecoverable NAS backup state copied to tape.

[cody_bird]

I have the same configuration as the OP. Could I ask on this topic, how you are recommending the NAS backups are written to tape. In working our deployment we were unable to get Veeam NAS backups written to tape. So we had to configure file to tape jobs. (Are these the jobs you are referencing not to overlap?)

[soncscy]

Heya cody_bird,

There's no path for file share backups to tape at the moment. Even if you do get a successful one, understand that your restore narrative means restoring the entire file share backup (every single file) before you can start a restore.

You can avoid stressing production in Veeam 11 by doing an instant file share recovery and backing __that__ up to tape (it's a little lazy maybe, but it works I think).

But right now there's no way to properly take file share backups to tape.