The fact that their own FAQ on using their product to back up SQL Server databases has incorrect information in it isn't promising to me:
If you use SQL's own backup utility, a full backup will backup the database, then truncate the log files.
That's wrong. It will do no such thing.
Most likely, if you purchase their add-on for SQL backups, it will be fine and you'll get what you need from it. Not sure it will actually give you any real advantage, but it should work. I'd do a try-before-you-buy on a test server. Run some backups, restore them, see how it goes. If it works okay, then go for it.
I currently have backups to disk via SQL Agent using a custom script I wrote. Then the backups are copied to tape. Full backups weekly, diff nightly, log hourly (on appropriate databases only, of course). Some variations, like the model system database only gets a full backup after I change something in it. Managed by DDL triggers and the normal backup script. It changes so infrequently that there's no real point to backing it up every night. I also have a few read-only databases where I have a full backup after any changes (usually annual), and then don't bother the rest of the time. But most of the databases it's weekly full, nightly diff, hourly log.
Since the backups are swept to tape every day, there's no "you end up with double the files". And SQL 2008 and beyond can compress the backups, so it's a less critical issue even if they were doubled up. But they aren't, so it's moot.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon