Which actions within Veeam B&R reduce size of dbo.tape.file_versions

[Derry43]

I have been trying to emulate GFS type backup for File to Tape backup of a small file server (2.5Tb) by having Daily, Weekly, Monthly and Yearly tape pools and a Daily, Weekly1, Weekly2, Weekly3, Weekly4, Monthly and Yearly file to tape jobs. This has created a rather large dbo.tape.file_versions table and I am now rethinking how best to perform the same tasks either using a single daily job with full and incremental or Veeam Agent for Windows or simply moving to a VM backup using Forever Forward.

However the purpose of my post is not to get advice on which approach might be better (although that would be welcome, but I suspect that Forever Forward is the bookies favourite), but to get advice on what actions in the Veeam B&R Console will reduce or empty the dbo.tape.file_versions table. Is it...

1. deleting the File to Tape jobs? (tried but did not seem to make much difference)
2. removing the tapes created by the File to Tape jobs from the catalog?
3. deleting the tape pools?
4. some combination of the above?

Also, does anyone know if the Veeam Agent for Windows will also run into the same database size issues with SQL Express if the file set is the same?

Any help appreciated.

[HannesK]

Hello,
yes, for file-to-tape, you need a higher edition of SQL because of the 10GByte database size limit of the Express edition. File-to-tape is not built for that. It creates a database entry for each file in backup.

4. might help, but I recommend asking support for help as manual "drop table" commands might be required.

You won't have any issues with the Veeam Agent for Windows. It uses completely different technology (image based / block based instead of file based)

Best regards,
Hannes

[david.domask]

Hi,

@Derry43, Regrettably, manual edits are not safe on the Tape.Files* tables, and will irrevocably break restore from tape on that copy of the database in a bad way.

The only safe and supported ways to free up space used by File to Tape jobs are:


1. Remove the tapes from catalog; note that deletes in SQL will temporarily need space in the Tombstones table, which is cleared when all console connections to VBR are closed. This is important as sometimes the delete may fail due to lack of space in the Database on Express
2. Temporarily install a trial of MSSQL STD, migrate the Database there with Configuration Migration, and then remove the old tapes from Catalog
3. Use Postgres and migrate the configuration database to a PostgreSQL instance.

I know these are not _great_ options, but regrettably to maintain the database integrity, one will need to be done.