ways to restore data from crashed disk

Hello,

Recently my server drive has crashed and I'am trying to get some data of it. The only problematic part is my xfs partition, the drive has some "holes" in it, unfortunatly on the place where the superblock would be. I did:
dd_rhelp /dev/hdb4 hdb4.img
xfs_repair -f hdb4.img
Phase 1 - find and verify superblock...
superblock read failed, offset 9397895168, size 2048, ag 1, rval 0 Is there an alternative available on xfs or a way to recreate it?

Groetjes Japie

For starters, is the file really that big? (9397895168 bytes?)

-eric

Eric Sandeen schreef:

dd_rhelp /dev/hdd4 hdd4.img
xfs_repair hdd4.img
Phase 1 - find and verify superblock...
superblock read failed, offset 103376846848, size 2048, ag 11, rval 0 fatal error -- Gelukt (gelukt is dutch for sucses or done)

The image is 92G. big but my original filesystem was about 120G. but the 92G is about the size of the data that was on the disc.

dd_rhelp /dev/hdd4 hdd4.img info:
- Jump pos : 96365061.0 - max file size : 156019623.0
- Biggest hole size : 119309126 k - total holes : 0k
- xferd(succ/err) : 36710498.0k(36710496.0k/2.0k)
- EOF is not found, but between 36710498.0k and 156019623.0k. ALL your data has been dd_rescued !!

Groetjes Japie

xfs_db hdd4.img

xfs_db> sb 0
xfs_db> p
magicnum = 0x58465342
blocksize = 4096
dblocks = 36710528
rblocks = 0
rextents = 0
uuid = 9b1a2a9c-9572-426f-b234-b6ba89bae713 logstart = 33554436
rootino = 128
rbmino = 129
rsumino = 130
rextsize = 16
agblocks = 2294408
agcount = 16
rbmblocks = 0
logblocks = 17925
versionnum = 0x3084
sectsize = 512
inodesize = 256
inopblock = 16
fname = "\000\000\000\000\000\000\000\000\000\000\000\000" blocklog = 12
sectlog = 9
inodelog = 8
inopblog = 4
agblklog = 22
rextslog = 0
inprogress = 0
imax_pct = 25
icount = 76864
ifree = 20402
fdblocks = 8890535
frextents = 0
uquotino = 0
gquotino = 0
qflags = 0
flags = 0
shared_vn = 0
inoalignmt = 2
unit = 0
width = 0
dirblklog = 0
logsectlog = 0
logsectsize = 0
logsunit = 0
features2 = 0

Groetjes Japie

Thank you for this interesting thread.

I'm going to check an xfs image file and your advises are really useful.

Kind regards

Robert

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

when you are talking about sizes, do you mean space used (du) or max offset (ls -l?) max offset should be the same for your image file as for your original device... 120G.

-Eric

Eric Sandeen schreef:

ls -l
But I don't know what tot trust anymore, if I look with gparted at my partitions the old disk gaves me a partition of 140G with 106G used space. My new disk has a partition of 200G with 166G used space.
If I create a new xfs partition it has about 10% used space (according to gparted, I suspect thats the size of the logfiles?) so from the 166G on the new disk 146G is the "real" used space so that should be the size of the image file. (nomather what ls -l tells me)
Is this correct?

Groetjes Japie

Ok. repair is trying to read a superblock at:

superblock read failed, offset 103376846848, size 2048, ag 11, rval 0

103376846848 bytes... or about 96 MB (base 2) (or 103 base 10)

if ls -l on your image file is not at least that big, of course it can't read it. And if that's smaller than your filesystem, then the image isn't right...

from your db output:

xfs_db> sb 0
xfs_db> p
magicnum = 0x58465342
blocksize = 4096
dblocks = 36710528

it looks like the original filesystem was bigger than your image:

4096*36710528
150366322688 <-- 140 MB

so it looks like your image file is not correct... I'm not familiar with the tool you're using, is it somehow compressing a sparse file or something like that?

-Eric

Eric Sandeen schreef:

You are completely right!

I used dd_rhelp instead of dd_rescue since everytime a bad block is hit my disk isn't acceseble anymore and I have to reboot.
So I tryed another aproach and used a knoppix cd to boot and used dd_rescue right away and with knoppix the disk keeps readable. (so it seems the kernel knoppix is using isn't killed by bad blocks, mine is) In concreto: I dumped my disk on another, used xfs_repair without problems and got almost all my data back (except for the last 2G that was written)
Thanks for pointing me the right track, or else I was still wrestling to recover an incomplete image file!

Groetjes Japie