And here is the modify/offline approach (you should still take a backup before attempting this):
USE [master]; GO ALTER DATABASE dbname SET SINGLE_USER WITH ROLLBACK IMMEDIATE; ALTER DATABASE dbname MODIFY FILE (name = N'dbname_log', [filename] = N'F:\new_path\dbname_log.ldf'); ALTER DATABASE dbname SET OFFLINE; /* Now go to Windows Explorer, copy the ldf file to the new location, rename the original (and move it or delete it after this process is complete). Make sure the SQL Server service account has adequate permissions on the new folder. Then: */ ALTER DATABASE dbname SET ONLINE;
Both of these are much safer, in my opinion. As long as you have a backup that you're comfortable resorting to (e.g. it isn't from yesterday or last Wednesday), then they're all relatively safe approaches, but the detach method is the one most likely to force you to revert to that backup.
Many of the so-called "solutions" pushed by SAN vendors - snapshots in particular - are pipe dreams, and they could leave you in a similar kind of lurch. I'll leave that discussion for another day, but I will suggest you maintain your own native backups in addition to anything you're doing at the SAN level. Do have a read of Denny Cherry's article, "Should I Be Using SAN Snapshots as a Backup Solution?"
As far as I'm concerned, a file system backup of mdf/ndf/ldf files is NOT a backup you can rely on. If you have any hope of recovery, you need to use proper, native SQL Server backups. Anything less exposes you to a lot of risk, could be detrimental to your career, and may even jeopardize the viability of your entire company.