If the file is still present, you should be able to do this:
RESTORE DATABASE YourDB FILEGROUP=YourFG WITH RECOVERY;
If the file is no longer present (or present but not eligible to recover the data), you're in for a rough weekend. Depending on the complexity of the database, I would probably start making a backup plan (no pun intended):
- create a new database
- use the "Generate scripts" option against the old database to script the objects and data (or use a 3rd party tool and do a schema/data compare)
- make sure all database settings, logins etc. are mapped the same to the new database (this can get complex if you're using TDE, certificates, service broker, etc.)
- rename the old database
- rename the new database
(You could also skip 4. and 5. if you can adjust your applications to point to the new copy of the database.)
Why does it take 3 days to backup / restore a 2.1 TB database? If it is all about moving the backup, I'd suspect copying the MDF/LDF files would actually be slower since at least the backup could be compressed. And if it's just about restoring, then writing the copies of the file there shouldn't be any faster than the restore process itself - make sure you have instant file initialization enabled. Or get faster I/O on the secondary system.
Anyway, no, you can't copy the MDF/LDF files while the database is online, you'd have to take it offline to do so. And this is the absolute LEAST safe way to copy a database. If anything happens to the files while they're detached/offline, you now have zero copies of your database.
I would suggest looking into ways to make the backup/restore faster - whether it be ensuring you're compressing your backups and transferring the files in the best way possible, using the best I/O subsystem available, getting better I/O, making sure that IFI is enabled, etc.
Another option to consider is round robin log shipping - assuming production is in full recovery and you are taking regular log backups, you can perform log shipping to one database while developers work on another, and when you get to a stable point, restore with recovery and have the developers switch, taking their recent changes with them. Now re-initialize log shipping on the copy they just stopped working on, and it will be ready for them at the next "stable" cut-over, with no waiting.
Best Answer
There is no T-SQL command to take a filegroup offline, though an individual file can be set offline.
From the documentation, ALTER DATABASE File and Filegroup Options (Transact-SQL):
To relocate files, follow the instructions in the documentation, or see the related Q & A:
How do I move SQL Server database files?