I stumbled across an interesting problem today. One of our production clusters was starting to run out of space on the C:\. I went in and expected to find the usual suspects: $kbuninstall$ folders in C:\Windows\, crap in C:\Temp\, people downloading huge installation files and leaving them in C:\ root or on their desktop… no, it was none of these. I had 9 GB of data inside C:\Documents and Settings\All Users\Application Data\Red Gate\SQL Backup\Log\ …probably a year and a half's worth of tiny, 3 KB log files. Because of the sheer quantity it took a long time to delete, so in the meantime I fired up the SQL Backup GUI to figure out why things were going here.
Apparently this is the default location, and from browsing a few threads over on the Red Gate forums, it seems this is intentional. Had I known it was going to log everything it does, I may have looked into it sooner; as it stands, there is nothing during setup that prompts me to change the location or even lets me know what the process is going to be. And of course after the product is installed on the server, I handle everything with command line and calling master.dbo.sqlbackup, so I hadn't been in the GUI long enough to even notice that such a setting existed.
If you launch the SQL Backup GUI, go to Tools | Options and you will find a tab called File Management (it should be highlighted by default). Here are the options I set up for this specific server:
Customize the path to somewhere more appropriate than the system drive. If you have SQL Backup installed on a cluster, you should probably use a shared drive for this (in my case I moved it to Y:\). If you use a local disk, unless you ensure that the same folder structure exists on all nodes, the logging will stop working in the event of a failover. Here you can also configure how much trailing history you want to keep.
If you are already using SQL Backup, this may be a known issue to you. Or it may be brain dead obvious. However, if you weren't aware of this issue, I would check your settings and configure them correctly now, rather than next Saturday when you get paged at 4 AM. Also keep it in mind if you are planning to deploy SQL Backup to new servers in the future.