How should I best handle a rapidly growing database? I have a database that I need to maintain.
Sadly, the setup and use of that database I can't change, much (thanks to some internal politics).
It's running on SQL Server 2008r2.
Its only been live for 5 days and has grown from 20GB to upwards of 120GB in that time. (essentially most of the data gets deleted and then imported, but like I say I can't control that side of things)
I would love to run nightly jobs to shrink the database and reorganise the indexes, but I know that's a long way from best practices and could lead to more problems than I've already got!
QUESTIONS

What's the best way to handle a database that's rapidly increasing in size?
Should I be looking at moving the file group around to keep the physical size on disk down?
Is there any way to stop the server running out of space within a month?
I don't recommend to shrink your database files unless you are completely sure that the space will not ever be needed again.  Why shrink every night only for it to grow every day?  You're going to run into the pain points of shrinking your data files, and you're forcing yourself to run into performance impact when the database files need to grow during the day.

If it ramped up to 120 GB because of initial space requirements, is it safe to say that the database will not be larger than that (obviously with some buffer)?  Size your database appropriately.

Otherwise, if the database will continuously grow, and you don't have any input on the data growth that happens (in other words, if you can't archive data off of the database) then you will simply need to ensure that there is ample drive space for the required growths.

Do you know which database files have been growing?  There is different behavior that will cause data files to grow, as opposed to transaction logs to grow as well as maintaining their size.  If the transaction log is the main consumer of the space because of heavily logged transactions, you can consider more frequent transaction log backups to ensure the log is reused more often (there are some stops here, as open transactions, so this might not be possible across the board).

More information surrounding what is growing and the scenario is needed to get more specific, but I don't recommend scheduled shrinking of your database files.