Hot answers tagged data-recovery
57
Ok - something was bugging me about your issue, so I fired up a VM to dive into the behavior that should be expected. I'll get to what was bugging me in a minute; first let me say this:
Back up these drives before attempting anything!!
You may have already done damage beyond what the resync did; can you clarify what you meant when you said:
Per ...
19
http://www.storagesearch.com/disklabs-art3-floods.html
Do NOT attempt to recover the data
yourself. This will do more damage to
your data and makes it more difficult
to recover when it eventually gets to
a data recovery specialist.
When hard disk drives get wet, the
'heads' can get stuck to the platters.
When the hard drive is powered ...
11
Ha - my (un)favorite question I get asked (as I wrote DBCC CHECKDB).
Here you go:
There's only one time when you should be trying to work out how long a CHECKDB is going to take - when you're planning your regular database maintenance. If you're faced with a corrupt (or suspected corrupt) database and you're only just starting to think about how long a ...
8
How valuable is the data? If your business depends on it, disconnect it and call a professional recovery service.
If it's not so valuable, this is a pretty good summary of steps you can take yourself.
It includes the controller board changing idea Dentrasi mentioned and also everyone's favourite, the freezer trick.
8
All my data in this 6 years is gone and they will just extend the hosting expired date to
another 90 days
That is very generous of them. Seriously.
Is there any other way to retrieve the data from the crashed harddisk?
Get the disc, send it to a recovery lab. Cost is some US$ PER GIGABYTE OF DISC SIZE. Are you willing to pay that?
See:
All ...
8
The software RAID solution is Windows itself: SFS refers to a "dynamic disk" in Windows 2000 or later, and software RAID volumes in Windows must be built on dynamic disks.
What I would do:
Capture offline images of all drives before attempting to boot, to ensure that we do not make anything worse than it already is.
Put the bootable NTFS drive on the ...
8
The solution you want (and this should work) is to run mysql_install_db as root.
or dpkg-reconfigure mysql if you're a deb/ubu user.
Manpage description:
mysql_install_db initializes the MySQL data directory and creates the
system tables that it contains, if they do not exist.
7
I see two options in your future.
Call PSS and open a ticket. It'll take a while to get anywhere with them.
Call SQLskills (Paul to be specific) and see what he can do. I know that Paul has successfully hacked a database back to life using a hex editor before. Paul isn't cheap, but he'll get the job done.
Good luck.
7
Look at the /etc/rc?.d directories. You will find symlinks in those that point to the scripts that were in /etc/init.d. You will know what startup scripts you will need to restore to /etc/init.d. So, something like:
$ ls -l /etc/rc?.d
and you will see something like:
/etc/rc2.d:
total 4
-rw-r--r-- 1 root root 556 2009-01-23 15:01 README
lrwxrwxrwx 1 ...
7
First and foremost, boot off a live CD or recovery disk and back up your data. You may want to include system configurations from /etc, too.
You can try doing a reinstall over what you have, leaving your partitions you want to keep untouched. As long as you weren't keeping your good data in any system partitions (and let's hope not under /usr), you should ...
6
If you still have the current log file it may be possible to recovery the data using a 3rd party tool. UPDATE statements are fully logged in most cases. Here are a couple of tools to look for:
Apex SQL Log by ApexSQL
SQL Log Rescue by RedGate
If you were running in simple recovery model with no backups, then ran your UPDATE statement, and then took a ...
6
Assuming a battery backed controller, the data should be flushed out to disk and you would be fine. Power supply failure isn't really any different from shutting of the machine unless there was some massive surge.
That being said, raid isn't backup, you must have backup.
Also, if you can afford it, two power supplies on two different power sources ("A/B" ...
6
Your best bet would be taking the drive to a data recovery company who would, in most cases, be able to remove the disk's platters and extract the remaining data from them. However, this process is quite risky and there are no guarantees that your data can be recovered either partially (as a result of a head crash) or at all (as a result of having taken an ...
6
Listing the directories does not mean that the filesystem is ok, you're just viewing metadata (which is a small percent of a filesystem).
Create a backup of everything you can
Run a filesystem check (fsck)
Create another backup (in case fsck managed to save some more files)
Replace the disk
5
I am presuming that you are using Redhat simply because that is what I am using:
Step 1-
Since you shouldn't have any actual data store in /usr (man hier), you should be able to reinstall all the system binaries with:
cd /root
rpm -Va > filename
rpm -qf `cat filename | awk '{print $3}'` | sort | uniq > filename2
yum reinstall `cat filename2`
If you ...
5
No. Without a disk scrub, a dereferenced (deleted, but not overwritten) file is still present on disk, including a .vmdk.
Fully wipe your disks with at least a pass of zeros (more passes of random data for sensitive data or [edit: see Puddingfox's comment below; one pass is plenty on modern drives] the paranoid) before selling, always.
5
The best way is to get control of the emails before they get deleted. I will discuss generally and point to examples for Exchange because that is the mail system I know best.
1- Get the emails off of the server and to an archive of some kind when they are created. The specific solution depends on your mail server ... GFI and Sherpa are among many ...
5
My recommendations:
Google "undelete for Linux", and you'll find something such as http://www.r-tt.com/data_recovery_linux/. You can use this to undelete any documents that you want to recover.
Take a step to avoid this in the future. What you want is a method to make a copy of the partition, something like Acronis TrueImage for Linux. If you run Acronis ...
4
First rule of data recovery: Stop using the disk
Undelete is possible, as Gravitas suggests, but the more you use the disk, the greater the chance the freed sectors will be overwritten by new data. Even just log files on an idle, booted system can be enough to scupper your recovery chances. The recommendations above are good, but make sure you do them with ...
4
Depends on the value of the data. If the data is of low value go with tools such as ddrescue, then export the image back to another mac.
If the data is valuable you should send the disk to a rescue company without trying to read out the data yourself. Additional operations on a failing hd can kill it permanently, which will significantly increase the cost ...
4
How brave are you? And do you know where the fault lies?
I had an electronics failure in a drive once, and it was just a matter of un-screwing the PCB on the bottom of the drive and replacing it with another one from an IDENTICAL drive (different revisions = usually no good). On the Seagate's it's very easy, because they have little contact points that you ...
4
Mounting it without specifying the password you be a bit silly, don't you think? The people at McAfee would be out of a job sooner than one would deem possible, even with the current crisis...
Mounting it with a password would require you to either load the McAfee software or have some compatible program. The latter seems rather unlikely, because again, ...
4
No it would not. An undelete would get the VMDKs back and usable.
Even if it did not, the VMDKs are not encrypted and are a fairly basic wrapper around another filesystem - not too difficult fiddling could read data directly from where they were on the disks.
Use DBAN to properly wipe them, it won't take too long.
4
If you are lucky you might have some success with getting your files back with recovery software that can read a broken RAID-5 array. Zero Assumption Recovery is one I have had success with before.
However, I'm not sure if the process of creating a new array has gone and destroyed all the data, so this might be a last chance effort.
4
Unfortunately, no - there's no more data there than Windows can see - not unless you took a ZFS snapshot.
To expose from the ZFS to iSCSI, behaving like a raw disk when it's really dealing in files, it needs to create a fake block device as a file on the ZFS pool. This specific file is exposed as a blank "disk" over iSCSI - allowing the Windows iSCSI ...
4
Looks like the filesystem was hosed and the fsck didn't fully repair it.
At this point I'd be tempted to check the logs to see if the disks are all physically working (noises? SMART status? errors in the logs regarding resets? etc.) and restore from backup rather than spend more time trying to straighten out the results of the fsck.
4
The problem was that the new motherboard created a host protected area (HPA) on some of the drives, a small section used by OEMs for system recovery purposes, usually located at the end of the harddrive.
ZFS maintains 4 labels with partition meta information and the HPA prevents ZFS from seeing the upper two.
Solution: Boot Linux, use hdparm to inspect and ...
4
You should do two things:
Since your server was compromised, you should take it offline immediately and audit how this happened. Once you know this, proceed to step 2.
Restore from a known good backup, and while still offline, fix whatever vulnerability led to your initial compromise. RAID is not a backup, and shouldn't be treated as such. Recovering files ...
3
First: Backing up tar files instead of single files is highly recommended to avoid the shoe shining effect, which is what you experience: The computer can't deliver files fast enough and the tape drive has to stop and before starting to write again wind back a little to find the precise point where the stream ended. This isn't only much slower but puts a lot ...
Only top voted, non community-wiki answers of a minimum length are eligible
