1151
General Software Discussion / Re: recover an SQL .mdf file that is currently written to a bad sector
« Last post by Shades on June 21, 2015, 12:51 AM »While I'm not a fan...try if you can use CHKDSK, in the off chance Windows is actually able to repair the bad sector(s) or capable of moving data around to spare sectors.
Then I would try software such as TestDisk to retrieve data. At least it doesn't give up that quickly as Windows explorer when copying files. UnstoppableCopier is another piece of software that won't give up easily when copying files. Both are free to use.
If you don't trust the hard disk to last much longer, you might be better off to clone the current hard disk to a new (similar storage capacity or bigger) hard disk, disconnect the current hard disk to keep the original data as safe as possible and try to retrieve data from the cloned hard disk. This way is likely best, as you will need a new hard disk for your server anyway. And with cloning you have a 1-on-1 copy, so the server should work immediately after the cloning is finished and the original HD is disconnected. Especially when you can get a new hard disk that is the same brand and model as the original.
If you have more than one SQL Server running, you could dump the original database and import it in the other SQL Server. That would be fastest and give you an option to check for content and/or structural differences between both databases and make fixes where necessary. Which is also not hard to do with the software that comes with the server software. As your database is only 2.3 GByte in size you can download the free SQL Server 2012 Express software, with which you are allowed to run a database smaller than 10GByte. There might be already an express edition from SQL Server 2014 available, if you fancy the latest.
And as a general rule: always verify if your dumps are correct...don't trust the message saying the dump was created successfully, but upload it again and actually check for errors during import and do random checks for structural and/or content integrity. I have been burned by dumping Oracle databases that show no error in the dump log file, but still are capable of generating import errors. This hardly ever happens, so if you feel lucky, go without the verification...but don't say you weren't warned.
Making backups/dumps from a MS SQL Server database is quite easy and fast. At least it is on my MS SQL 2012 Server with the management software that comes standard with the server software. PowerShell is very handy too when making SQL database dumps.
Then I would try software such as TestDisk to retrieve data. At least it doesn't give up that quickly as Windows explorer when copying files. UnstoppableCopier is another piece of software that won't give up easily when copying files. Both are free to use.
If you don't trust the hard disk to last much longer, you might be better off to clone the current hard disk to a new (similar storage capacity or bigger) hard disk, disconnect the current hard disk to keep the original data as safe as possible and try to retrieve data from the cloned hard disk. This way is likely best, as you will need a new hard disk for your server anyway. And with cloning you have a 1-on-1 copy, so the server should work immediately after the cloning is finished and the original HD is disconnected. Especially when you can get a new hard disk that is the same brand and model as the original.
If you have more than one SQL Server running, you could dump the original database and import it in the other SQL Server. That would be fastest and give you an option to check for content and/or structural differences between both databases and make fixes where necessary. Which is also not hard to do with the software that comes with the server software. As your database is only 2.3 GByte in size you can download the free SQL Server 2012 Express software, with which you are allowed to run a database smaller than 10GByte. There might be already an express edition from SQL Server 2014 available, if you fancy the latest.
And as a general rule: always verify if your dumps are correct...don't trust the message saying the dump was created successfully, but upload it again and actually check for errors during import and do random checks for structural and/or content integrity. I have been burned by dumping Oracle databases that show no error in the dump log file, but still are capable of generating import errors. This hardly ever happens, so if you feel lucky, go without the verification...but don't say you weren't warned.
Making backups/dumps from a MS SQL Server database is quite easy and fast. At least it is on my MS SQL 2012 Server with the management software that comes standard with the server software. PowerShell is very handy too when making SQL database dumps.

Recent Posts

