VEEAM’s vmware backup management software often touts how it can “backup SQL Server databases and truncate the transaction log”.
This is probably significant for many corporations that do not have a DBA on staff and only have system administrators and helpdesk folks minding the database servers.
Out of the box, databases are not backed up unless someone does something to back them up. That and the transaction logs for FULL and BULK_LOGGED recovery model databases continue to grow until they get backed up and then are automatically truncated once they are backed up.
This can result in poor performing databases that have disks filling up and transaction log files that are many times larger than the actual data files.
VEEAM allows system administrators a way to trigger native database and transaction log backups. A sysadmin would probably think it is enough that now those unruly transaction logs aren’t filling up disks anymore, pat themselves on the back, and think they are done.
Unfortunately, folks tend to stop short of asking questions “What are transaction logs, are they important?”, “I wonder why transaction logs grow until they are backed up?’, etc…
The trouble with this is that if database and transaction log backups are being performed by other processes, then if VEEAM initiates a backup, it can break the continuity of your backup chain and cripple your ability to do point in time restores to a point in time between full backups.
Having a mixture of tools managing database backups is a recipe for disaster.
If you have squirrelly sysadmins who insist on using VEEAM to back up databases, you will need to do one of two things:
1. Tell them to perform only COPY-ONLY full backups and not to perform any transaction log backups. Then assure them that you are performing your own full and transaction log backups using your own backup management tools and that the transaction logs are getting truncated.
-OR-
2. Use VEEAM to manage ALL of your full and transaction log backups