WSS 3.0 Sharepoint content log file size

Hello, recently my sharepoint server ran out of disk space. The SQL database is stored locally on it. I drilled down and found out that the Content LDF was consuming all of the hard drive space. I searched around the web and several sites recommended changing the recovery mode to Simple. I did make that change and I was able to shrink the log file database. That freed up about 17 gigs on the server. Further reading stated that this was not a good practice and that log files should be "dumped". I checked my 2005 SQL server manager and it doesn't appear that I have the capability to backup the log file anymore. I can still shrink it though. I'm not very familiar with Sharepoint. It's basically being used now as a knowledge base. I'm wondering if what I've done to the database will prevent it from expanding again, resulting in the same issue? Also, do I need to be backing up the log file? Any help would be greatly appreciated.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

zephyr_hex (Megan)DeveloperCommented:
changing the recovery model to Simple will keep it from expanding like it previously was.  however, in using Simple recovery model, you lose the ability to restore to point in time... which for many people, is not a big deal.
you do need to be sure to run backups... perhaps nightly.  perhaps weekly...  it depends on how much your sharepoint content changes over time.

so, for example, if you did nightly backups of sharepoint (NOT the log... but actually use sharepoint stsadm (or central admin) to initiate full farm backups), and then this afternoon the server crashed and you had to restore from that backup... you would be missing all of the content between the last backup and the crash.
if you can not have any loss, then you need to be using Full Recovery in SQL, and get more hard drive space to accommodate the log file.

when i was running sharepoint, i did a combo of nightly sharepoint backups, and weekly SQL level backups (again.... backing up the CONTENT databases in SQL ... 'cause the log files are not very useful if you're using Simple recovery)

see here for more on sharepoint recovery models:

(the article is moss 2007, but it applies to wss 3.0)

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
zephyr_hex (Megan)DeveloperCommented:
jmchristyAuthor Commented:
Okay. That all makes sense. The only other thing I noticed was the autogrowth on the log file. Should that be turned off? By default it was set to 10% and 2GB when I changed it to Simple. Should I just leave that stuff alone?
Big Business Goals? Which KPIs Will Help You

The most successful MSPs rely on metrics – known as key performance indicators (KPIs) – for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.

zephyr_hex (Megan)DeveloperCommented:
leave the autogrowth alone.  changing the recovery model is enough.

autogrowth has to do with SQL "sizing" itself that there is enough space for new data.  instead of constantly allocating space, it does it in chunks, and you don't want it to do that too often because it's a performance hit.
i also didn't use autoshrink because if it runs mid-day, it could be a performance hit.
more info here:

in my environment, i changed sharepoint db's to Simple recovery, implemented weekly full backups, and i also occasionally manually ran a SQL defrag script.  i can't remember exactly which defrag script i used, but it was something similar to this:
jmchristyAuthor Commented:
Okay. Thanks alot, you've been a HUGE help! Points awarded.
zephyr_hex (Megan)DeveloperCommented:
oh, i also ran nightly Sharepoint stsadm backups using something like this:

nightly Sharepoint full farm backups, (and a library of 7 days of previous backup files) - scheduled in windows scheduler
weekly full SQL backups on Sharepoint databases - scheduled in SQL
about once every 3 months, i ran the SQL defrag script.  it was a small company, and sharepoint was used daily, but not used heavily.

and then i copied all backup files to offsite storage nightly.  so i had 2 copies of every backup file... one one onsite, and one offsite.

and i'd say that was overkill, but it wasn't interfering with performance or costing any extra money to do it, so i did it.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Hardware Firewalls

From novice to tech pro — start learning today.