damien commenge wrote:
I can confirm when you use file to tape job the DB increase a lot because each file you have on all tape are also présent in database…
However I m sorry but I don't find any recommendation about sql should be préfèred to postgre in this scénario...in your links I don t find it too... sql standard was recommended before postgre because it was the only way... 10gb can t handle a lot of file to tape so you were forced to migrate if you want to continue to backup your datas.…
The only way to reduce space support gave me was to remove from catalog some tapes and restart veeam service to get back the space.
It’s only the metadata that fills up the database. The files themselves go to tape, not the database. I guess, you meant that, @damien commenge.
There is no specific recommendation to prefer MS-SQL over PostgreSQL for file to tape. But it’s not only about database size hard limitations. For SQL-Express the main problem was most of the time the sluggish performance. You are restricted to 1 socket / 4 cores and 1410MB of buffer pool memory here. The latter being the most important restriction here with VBR when it comes to performance.
This is, what I tried to emphasize with the links provided.
There is a recommended limit for VM backups with PostgreSQL: With 12.0 ist was 5k VMs which was lifted to 10k VMs with 12.1.
Current number of VM limitations - R&D Forums (veeam.com)
It was always recommended not to have more then ~500VMs with SQL-Express while there was no VM limitation with the full blown SQL.
650GB is quite a size for a VBR database which would usually be expected for way more than 10k VMs - probably we’re beyond the recommended limit for PostgreSQL here. At least you would need to specifically size the database server here according to CPU, RAM and IOPS provided.
I would be interested what the actual number of files and versions is here.