Many of the question s can not be answered by us. How long is a piece of string?
Some of the existing transaction logs are 50-100GBs, what is the best approach in
determining what I should shrink them down to for the purposes of moving forward.
As long as they need to be. I suggest NO shrinking. Trunacate logs, come back in a week and see how much space is used, THEN decide. But YOU have to answer this one.
The nightly backups are roughly 8TB and needless to say, we're using more disk space than
So why turn them to simple? I mean, seriously.
All of the databases are set to FULL recovery and the transaction logs have never been
A little logic will tell you that igf you truncate them ONCE, then you will likely use a LOT less space for backing them up anyway. The result may be that you can well keep them in full recovery mode. Try that out first. If they rally are low volume etc. then the log backups wil lbe a LOT smaller in the future.
I've gone through all of the SQL Servers and identified LOW priority ones that only need a
nightly backup and a days worth of data loss in the even of a disaster will not be a
problem (Fax databases and things like that).
Yes. That is until you end up in court and get your ass handed for not having critical legal documents. Do you know that the fax logs may well be part of what you are required to keep for years as business relevant information? It is like that in my jurisdiction (10 years). If you are a U stock company there may be similar surprised (SOX). Failure to do so makes it VERY bad in court if you want to prove you did not get a fax. Or did send one. No one cares whether this happened monthly back and you have more recent logs - you fail the law requirements. Make sure this is signed off by someone VERY high, because your business not critical may be your firing reason.
Or, will they shrink on their own over time(I don't think they will)?
No. And they should not do that. Log re-sizing is a manual operation except for low volume databases.