Tag: data recovery

No More Lost Deleted Files in Ubuntu

I had a shocking error of judgement this morning when I accidentally deleted some of my son’s photos from his toy digital camera. They were sitting on my desktop, and I was on a cleanup… These were a casualty of my cleanup-fest and obsession with the shift key.

Thinking on a Windows vein – I thought that I should be able to backup the files easily and seamlessly. But I don’t want too much aggravation. A quick scoot around the Ubuntu forums, and I found TimeVault.

TimeVault is the equivalent project to Windows’ Shadow Copy service or Apple’s Time Machine. Basically it’s a completely transparent backup that allows you to recover files easily on the system you are working on.

I’ve downloaded the .DEB and forced the installation (there’s no binary x64 version at the moment). I’ll see how it all goes and report back!

Using dd and dd_rescue

Following up on a post about recovering bad disks and reiser file systems, here is a list of ddrescue commands to help make life that little bit easier:

Backup MBR (boot code + partition table):

<code>dd if=/dev/hda of=mbr count=1 bs=512</code>

Restore boot code + partition table:

<code>dd if=mbr of=/dev/hda</code>

Restore, not including partition table:

<code>dd of=/dev/hda if=mbr bs=448 count=1</code>

Saving partition sizes to text file:

<code>fdisk -l /dev/hda >partition-info.txt</code>

Backing up to gzipped file:

<code>dd if=/dev/hda | gzip >hda.gz</code>

Restoring:

<code>gunzip -c hda.gz | dd of=/dev/hda</code>

Backing up to archive split into 1GB chunks:

<code>dd if=/dev/hda | split -b 1024m -d - hda.</code>

Restoring:

<code>cat hda.* | dd of=/dev/hda</code>

Backing up over ssh tunnel to remote machine (blowfish = faster):

<code>dd if=/dev/hda | ssh -c blowfish user@machine "dd of=hda"</code>

copying files over ssh tunnel:

<code>tar cv /source | ssh -c blowfish user@machine "cd /destination ; tar x"</code>

Thanks to colinm over at Digg for putting these so succinctly

Recovering bad discs in Linux – pt 2

So, maybe in part 1 the data recovery didn’t work for you?

Well, that’s OK because Linux is robust against bad discs in one form or another. The trick is to work out what that might be.

A good method is to use dd or dd_rescue. These tools create a forensic copy of your hard disk drive or partition so that you can mess around with it without affecting the original drive. This is also a benefit as generally a virtual disk will mount and work faster than a faulty disk drive.

To begin with, we need to create that copy of the partition that you need data from.

mkdir ~/myDisks
dd_rescue /dev/hda1 ~/myDisks/hda1.image

The reason that I’m using dd_rescue rather than dd is that seeing as you’re reading this guide, the drive probably has faulty areas of the disk. dd_rescue will work around those quite nicely.

I’m working on the premise that it’s a single partition that you need to recover. If not, you may want to look over at http://edseek.com/~jasonb/articles/linux_loopback.html#id2494145 to read up on ways to read parts of disk images and generally show off.

Right, so we have our image.

Let’s set up the mount point

mkdir /mnt/restore

And now mount the new partition image

mount -o loop ~/MyDisks/hda1.image /mnt/restore

The partition should now mount on the folder. To check if anything is there:

ls /mnt/restore/

You should see a familiar list of files (or if someone else’s drive, one that is not so familiar). You can now copy the files away and do whatever you need to do to the image.

Once finished, unmount the disk image

umount /mnt/restore

Recovering a faulty hard disk drive in Linux – PT1

Today, I’ve been working on a server that doesn’t want to mount one of the partitions that has been formatted with reiserfs.

Using the fsck command doesn’t work because there are bad blocks on the drive, resulting in fsck vehemently refusing to cooperate.:

Cannot read the block (41713664): (Input/output error).

To get fsck to play with such a faulty device, you need to build a list of badblocks first, so that fsck can deal with them. If the disk is REALLY bad, then this will do no good at all – just dd_rescue that bad boy!

It’s never bad to backup before doing something like this anyway, so if you can – use dd_rescue to clone onto another disk. The likelihood is that you don’t have another disk and that’s why you’re reading this. If so, read on.

First of all, we need to be able to tell fsck which blocks on the disk are bad. To compile a list of badblocks, you’ll need to use the badblocks tool:

badblocks /dev/hda1 >>badblocks.txt

Obviously, change hda1 for the partition that is causing you trouble.

You may also need to specify a block size for the partition. The default is 4096, which is the standard size of reiserfs, but to be doubly sure, you can run the debugreiserfs command, and the output will show you the blocksize:

Blocksize: 4096

If the blocksize differs, run
badblocks -b 4096 /dev/hda1 >>badblocks.txt
replacing 4096 with your block size.

This may take some time. Grab a book, make a drink, have a snack.

Once the blocks have been read, enter less badblocks.txt to make sure that there is something in the file. You should see a series of numbers output to the screen. If that’s good, press ‘q’ to return to the shell.

Now to run fsck. We will need to account for the bad blocks, so you will need to include that badblocks file that you have just created:

fsck.reiserfs –fix-fixable -B badblocks.txt /dev/hda1. Once again, change the device from hda1 to what you are trying to recover. As long as the driver isn’t completely nerfed, the you might be able to run through the commands and recover the drive table.

If not, then I’ll have another article very soon.

Windows Files Systems and Booting Woes

The battle is on. Me vs. the Windows disk structure.

It’s been brewing for some time now. It was only two weeks ago that I had to rebuild a server as the hard disk had began to fail. Quite phenomenally I might add. It was a race against time to copy all of the critical data away from the beast for all of the user accounts.

Of course, this in itself was quite a battle as backing up the system didn’t seem to be on some people’s primary agenda. Therefore the system that I recovered was about 1 month old. Not very good.

Oh, and restoring an AD that old creates a new problem as Windows expects the restore to be fairly recent. If you’re having trouble after a restore and the event log gives some cryptic message about Volume Shaddow Copy dates and updates, you need to roll-back the system clock so that it doesn’t think that you’re doing anything dodgy.

Then an arduous task of copying all of the data back into the relevant partitions ensued.

Anyway, that’s not exactly the latest news. The recent events occurring are that I now have another failed drive on my hands at a second site. This time, there are bad sectors appearing on the disk.

The story began with one of the staff performing a defrag on the server as part of a daily task. He also noticed that there were a startling number of errors in the event log that seemed to have to appear out of nowhere over a recent few days.

The defrag caused the blue screen of death and the server would no longer start. chkdsk /r was ran in recovery console and reported various errors.

ARGH! It gets worse. Bad sectors were bleeding across the disks like cancer. Time to act people!

Thankfully, there’s a damn nifty Linux tool for copying drives. dd_rescue. It doesn’t have a startling homepage, but it does come with most Linux distros, including Knoppix.

dd_rescue cloned the disk to another disk, ignoring all bad sectors. Once the system was copied we faced the next challenge. The Windows boot sector was firked. Bootcfg, Fixboot and Fixmbr wouldn’t work. Or more accurately, they did work – just not very well. In fact, booting into a Windows PE session showed that two of the drive’s partitions had switched letters. The system disk was now D!

Various trickery ensued, but the final resolution was to install Windows Server the existing disk (that was thought to be D:), under a folder called Win2k3. Unfortunately, Windows was still under the impression that the system disk is D:. I followed the instructions for reconfiguring the hard disk drives through the registry on the Microsoft site.

One final reboot later, allowed me to boot into the existing O/S and repair it with the setup disk. It’s such a shame that in the process – loads of MS SQL and Windows components were shot.

WSUS is completely messed up and the SQL engine has also knocked out McAfee’s network deployment tool. I think that it’s a poorly server now.

I just wish that clients would listen when I tell them that a backup device of any sort is crucial (as well as actually doing it). Alas, the attitude nowadays seems to be a mired philosophy of locking the door once the horse has bolted – and hoping that you never need to.