And there's the "A-hah" moment where a lightbulb should go off in your head.
SBS comes with a ton of crap by default. Honestly nobody....nobody..cares about WSUS logs. And Sharepoint logging. And various other SBS maint routines. WSUS? Who ever has to refer to those? You can wipe that clean to zero on a weekly basis and not miss one bit of important info. Not to mention most biz clients are on an RMM package for updates anyways. Sharepoint? What percentage of SBS users really actually use sharepoint? 10% maybe? MMmmm...even that is generous, I'd say <5%.
I really hate to have to say this (and believe me I honestly do, because I usually agree 100% with everything you say and I totally respect your vast knowledge of all things server), but I have to disagree here.
I think you may have fallen into the common trap of mistaking SQL transaction logs as .... well, just that, mere 'logs'. I made the same mistake myself for a while when I first started working with databases. The examples you give, WSUS and Sharepoint logs (unless I have totally misunderstood the purpose of both of those, which is entirely possible) are essentially diagnostic logs.
Now I'm not claiming to be an SQL expert, nor do I even know enough to call myself a DBA -- I just know enough to get by to be honest and, like everyone else, I'm learning all the time -- but I think I do understand a little about SQL transaction logs, and diagnostic logs they're not.
I think one of the main reasons transaction logs are so commonly disregarded and misunderstood is their name; 'logs' is such a misleading term in this case. Yes, they log the transactions (ie the DB changes) but they're so much more than just logs. Their functional relationship with the database probably more closely resembles that of the VSS snapshots of NTFS. They're not some passive log that should be ignored or discarded, they're an active record of database transactions that not only provide the detailed log of events of each and every database change, but a means to revert the DB back to any point in time with single-transaction resolution.
Referring back to
the link I posted earlier -- I'd highly recommend reading the article in its entirety for a full understanding, but to reiterate the with the snippet I posted previously:
Crash recovery is only possible if the transaction log is intact. In fact, the transaction log is the most important part of the database—it's the only place where all changes to the database are guaranteed to be described in the event of a crash.
If the transaction log is missing or damaged after a crash, then crash recovery cannot complete, leading to a suspect database. In that case, the database must be restored from backups or recovered using less desirable options, such as emergency mode repair.
I've been doing tons of SBS installs since the early days of Back Office 4.5 and SBS2000...it's been my bread and butter...and esp with SBS2K3 and onward, the management of those default useless SQL logs has been the bain of most SBSrs...just neutering that logging saves tons of time, and has never...ever ended up in a "whoops..I shouldn't have done that" moment.
I don't doubt your experience and knowledge of servers for a minute -- it's far greater than mine, but there are tons of examples of configurations and procedures that, while considered to be bad practice, may be employed for years without any significantly dire consequences, but that doesn't make them the right thing to do. A couple of common examples: Running a server as part of a workgroup instead of as a domain controller, or even failing to maintain regular backups; both are common scenarios that you might 'get away with' for years, but I'm certain that, like me, you wouldn't recommend them.
Sure the risks of major issues in this case are minimal -- the more likely scenario is that you may introduce a number of minor database corruptions over time. Those corruptions may be so minor that they cause no issues and go completely unnoticed, but isn't it better to eliminate the risks all together, especially considering the highly granular database recovery ability that properly maintained transaction logs also provide?
Setting up regular transaction log backups is not only 'best practice' but as easy to do as setting up regular database backups. It's also, arguably, more important than regular database backups AND (here's the best bit) it solves the growing log problem, elegantly and properly. Why compromise?
