If you wanted to make life easier, according to the Version and Edition Upgrades page, there exists an edition upgrade for SQL Server 2008 R2 Express to SQL Server 2008 R2 Developer. You could just perform an edition upgrade and call it a day.
Alternatively, if you wanted to keep with your original plan of installing a new instance and migrating the database...
If you can't find files on your system, try installing Everything. It is an extremely fast indexing application that will run in your notification area.
Once you find the backup file, try running the following command to see if SQL Server can access it:
RESTORE HEADERONLY FROM DISK = 'drive:\path\to\mybackup.bak'
or
RESTORE FILELISTONLY FROM DISK = 'drive:\path\to\mybackup.bak'
If that does not work, then try moving the file to a location that the SQL Server service account has access to. If you don't plan on accessing any network resources with SQL Server, it would be easiest to run SQL Server as local system on your workstation.
Once your Developer instance can see the .bak file, you can either use the Restore Database task in SSMS (Right-click Databases in Object Explorer and select Restore Database) or you can script it. Just remember in either option you should change the destination path to the data and log files so they reside in the new default data path of the SQL Developer instance (or some other directory on your workstation). By default, it'll try putting them back in the original location when the backup was taken.
Here is an example restore script you could modify (use the RESTORE FILELISTONLY details for the logical file names):
RESTORE DATABASE [MyDB] FROM DISK = 'drive:\path\to\mybackup.bak' WITH MOVE 'logicalDataFilename' TO 'drive:\path\to\physicalDataFilename.mdf', MOVE 'logicalLogFilename' TO 'drive:\path\to\physicalLogFilename.ldf'
Best Answer
Correct, you would need to create a new file on the correct filegroup and recreate all your objects on the correct filegroup (if any existed) to move them, as you cannot move a file between filegroups.
I've seen this before in SQL Server 2012. If you query sys.master_files you will see the drop_lsn field has an LSN value in it for this file. This indicates the LSN at which this file was dropped. You need to perform a log backup to clear this value, then it will disappear from the DMVs.