Trying to restore dumped filesystem...

O

osx-addict

Hi all..

I've got my level-0 dumps of most of my old Linux box and would like to recover my user accounts (spanning across 3 DLT tapes). To that end, I tried doing an interactive restore and get the following :

Code: 
srv1# pwd
/home
srv1# restore ivf /dev/sa0
Verify tape and initialize maps
Tape block size is 10
Dump   date: Sat Feb 21 21:17:07 2009
Dumped from: the epoch
Level 0 dump of /home on srv1:/dev/cciss/c0d0p2
Label: /home
Extract directories from tape
Mangled directory: reclen not multiple of 4 reclen less than DIRSIZ (1 < 12) 
Mangled directory: reclen less than DIRSIZ (0 < 12) 
Mangled directory: reclen less than DIRSIZ (0 < 12) 
Mangled directory: reclen less than DIRSIZ (0 < 12) 
Mangled directory: reclen less than DIRSIZ (0 < 12) 
Mangled directory: reclen less than DIRSIZ (0 < 12)

Now, obviously the dump was done under Linux (Fedora Core 6 to be exact). Are these errors caused by a slightly different dump format between FreeBSD dump vs. Linux dump? Should I try specifying some other args or use a linux restore instead? I should have checked this before I nuked the old Linux installation.:(
 
You can't restore linux dump with freebsd restore.
you need to make FS matching the one you dumped (ext3fs probably, right?)

you can do this either on real machine or virtual machine, and then copy files (with external HDD/Flash or SCP)
 
Thanks.. Do I really need another ext3fs filesystem? I can't just run a linux version of restore in an emulated environment (ala the handbooks chapter 10 suggestion) but write to a UFS2 filesystem? I'm guessing 'no' perhaps due to filesystem differences with flags et-al....
 
osx-addict said:
Thanks.. Do I really need another ext3fs filesystem? I can't just run a linux version of restore in an emulated environment (ala the handbooks chapter 10 suggestion) but write to a UFS2 filesystem? I'm guessing 'no' perhaps due to filesystem differences with flags et-al....
Click to expand...
I think you MUST use the linux restore to avoid dump format issues. I haven't tested restoring a linux dump with the linux restore binary into an UFS2 filesystem, but I think it should work. If it doesn't work, you can restore to an ext2 filesystem, the only difference I know from ext2 to ext3 is journalling capability.
 
I'm hoping I can dig up a linux restore program.. If worse comes to worse I'll reformat my /home partition which is currently ~293Gb into two pieces -- one for FreeBSD and one for Linux and use it as a minimal installation partition/restoration drive.. Once there I assume I could have FreeBSD mount that ext2/ext3 partition to copy things from..

However, my preference is to avoid using Linux directly if I can.. I'll have to hunt around for some linux binaries to try out tonight.
 
Did you actually verify the directories? This can be just a warning, since you used verbose. I believe restore will do the right thing (i.e., just create the directories with minimum blocksize of the target filesystem).
If you only have level 0 dumps and not incrementals, you can use xf, which will save you the restoresymtable.
 
I'm not sure what you mean by verify.. I've spent the last several hours trying to get a Linux version of restore working under FreeBSD -- no luck.. Not even the statically linked version works.. Anyway, I think I'm up the creek and will need to use a bootable version of Linux that hopefully has /sbin/restore loaded on it.. Using that, I might be able to restore to a local disk .. A couple of questions come up though:

1) I've currently got a FreeBSD partition (/home, /dev/da0s1g) and would need to split it out into a linux piece + FreeBSD piece. What can I use to do this alteration.. Currently my /home partition has nothing on it -- but surrounding partitions do.

2) anyone know if I can restore over the network to some disk space on a Mac using OSX? It would be slick if this is possible but I'm not convinced..

3) Anything else I missed?
 
It's possible the dump formats differ. A statically linked linux version should work, if you:
  • Have linux kernel module loaded (kldload linux)
  • Have sysctl compat.linux.osversion set to 2.6.16, since this is an fc6 binary
  • Have emulators/linux_base-fc6 installed
  • Have linprocfs mounted.
  • brandelf the binary

Rather then splitting the fs, consider the following:
  1. Create a file the size of your expected linux dump (round up a bit)
  2. Create a file-backed memory disk, using mdconfig(8)
  3. Format as ext2fs using sysutils/e2fsprogs
  4. Mount the file-backed memory disk, using ext2fs mount argument on /mnt
  5. Restore the dump on that mount.
Then one final command:
Code: 
# assuming pwd = /mnt
tar -cpf - . | tar -xvpf - -C /home
 
Thanks.. Does that not assume that I'd try using it under FreeBsd?

Below is the output from the statically linked restore :

Code: 
srv1# ./restore.static xvf /dev/sa0
Verify tape and initialize maps
Input is from file/pipe
./restore.static: Tape read error on first record
srv1# 
srv1# 
srv1# 
srv1# tail /var/log/messages
Mar 10 23:28:27 srv1 kernel: linux: pid 2099 (restore.static): ioctl fd=3, cmd=0x6d02 ('m',2) is not implemented
Mar 10 23:28:28 srv1 kernel: (sa0:sym1:0:4:0): 10240-byte tape record bigger than supplied buffer
srv1#

I also tried the following hoping that perhaps if I fed in the data to the restore program that it wouldn't have to deal with the tape drive directly.. However, the results are similar to above (see the last line from above about big buffers).

Code: 
srv1# cat </dev/sa0 | ./restore.static xvf -
Verify tape and initialize maps
Input is from file/pipe
cat: stdin: Input/output error
./restore.static: Tape read error on first record

Any ideas on whether I can just suck in the contents of the tape drive into a giant file and then feed that into restore and have it work properly? Just curious...
 
Below is what I get :

Code: 
srv1# /bin/dd if=/dev/sa0 bs=1024 | /usr/compat/linux/sbin/restore.static xvf -
Verify tape and initialize maps
Input is from file/pipe
dd: /dev/sa0: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 1.237517 secs (0 bytes/sec)
/usr/compat/linux/sbin/restore.static: Tape read error on first record
srv1# tail /var/log/messages
Mar 10 23:51:43 srv1 kernel: (sa0:sym1:0:4:0): 10240-byte tape record bigger than supplied buffer
srv1# mt -f /dev/sa0 status
Mode      Density              Blocksize      bpi      Compression
Current:  0x1a:DLTapeIV(20GB)    variable       81633    IDRC
---------available modes---------
0:        0x1a:DLTapeIV(20GB)    variable       81633    IDRC
1:        0x1a:DLTapeIV(20GB)    variable       81633    IDRC
2:        0x1a:DLTapeIV(20GB)    variable       81633    IDRC
3:        0x1a:DLTapeIV(20GB)    variable       81633    IDRC
---------------------------------
Current Driver State: at rest.
---------------------------------
File Number: 0	Record Number: 0	Residual Count 0

It doesn't seem to like the blocksize and dies... To be completely honest I've never had this tape drive (DLT20/40) run under FreeBSD other than the above 'status'.. Am I using the wrong device or something? Even a 'cat /dev/sa0' fails like above..Hmm

one more thing.. I used "mt -f /dev/sa0 blocksize 1024" which was reflected when doing the "mt status" command and tried the "dd" again and got the same 10240 block size too big complaint.. I'm wondering if I've just plain got a general tape drive issue...
 
trev said:
How about increasing the default buffer size? I don't think you can shrink the blocksize once it's been recorded :)
Click to expand...

Hey.. That worked -- at least I could read the tape.. See below.. However, the linux restore program is still unhappy:

Code: 
srv1# /bin/dd if=/dev/sa0 bs=10240 | /usr/compat/linux/sbin/restore.static xvf -
Verify tape and initialize maps
Input is from file/pipe
Input block size is 32
Dump   date: Sat Feb 21 21:17:07 2009
Dumped from: the epoch
Level 0 dump of /home on srv1:/dev/cciss/c0d0p2
Label: /home
Extract directories from tape
Mangled directory: reclen not multiple of 4 reclen less than DIRSIZ (1 < 12) 
Mangled directory: reclen less than DIRSIZ (0 < 12) 
Mangled directory: reclen less than DIRSIZ (0 < 12) 
Mangled directory: reclen less than DIRSIZ (0 < 12) 
Mangled directory: reclen less than DIRSIZ (0 < 12) 
Mangled directory: reclen less than DIRSIZ (0 < 12)

I guess I'm wondering at this point if I need a newer version of the statically linked restore program -- the version I'm using may be a bit old.. Anyone got a newer version lying around?

On another note, I tried a blocksize=20480 and it worked the same as the 10240 size..

By the way.. I was able to do a "strings" on the data from the tape and see the files sitting on it so I know its there..
 
It is actually possible these dumps are faulty. Did you restore them before so you know they are good?
I'm also wondering about the compression.
Also - does everything stop after these messages or does restore continue and directories are created on disk?
 
I hope that's not the case.. I'm going to try and burn a Fedora CD today and try booting it up tonight when I get home and keep my fingers crossed that the CD has /sbin/restore loaded on it.. If not, I may have to play some games with some spare (hot swap) drives I've got for my H/W raid setup and put a bootable version of FC6 (or newer) on those drives and go from there..

I'll keep you posted..
 
Mel_Flynn said:
It is actually possible these dumps are faulty. Did you restore them before so you know they are good?
I'm also wondering about the compression.
Also - does everything stop after these messages or does restore continue and directories are created on disk?
Click to expand...

Forgot to answer your specific questions.. Once the complaints start about record len, they scream off the screen at a very fast pace -- I just hit ctrl-c and abort. I didn't try to let it just keep going.. I'm doubtful that would work.

As for the question on whether I had tried to restore using these tapes on FC6, the answer is no.. I've read stories like this before and can obviously kick myself but there's no use in crying over (possibly) spilt milk at this point.. I'll try my darnedest to get the data off -- one way or another.
 
Ok.. Just a quick followup.. I found I had some striped raid discs lying around that still had a working Fedora Core 6 installation on it and swapped all my drives out.. Once it was loaded, I was able to obviously use the restore utility just fine under Linux.. I was having issues with not having room to restore on the smaller Linux drives -- so I made a compressed tarball of that version of /sbin/restore and plopped it on my powerbook laptop. I then rebooted back into Freebsd and copied the tarball back over again. I checked the version of the utility compared to the version I was using last night and it was 4 years older (2002 vs 2006). Anyway, I tried using it under FreeBSD and it complained about the kernel version (which I had set to 2.4.x). Once I reset the kernel version back to 2.6.16 in FreeBSD, the utility ran fine but wasn't too happy talking to the tape drive directly..

So, I used the above mentioned :

Code: 
/bin/dd if=/dev/sa0 bs=10240 | /usr/compat/linux/sbin/restore.static xvf -

and now I see messages like (after the initial stuff):

Code: 
extract file ./rickf/src/network/ofx/bankinfo/7048.xml
/tmp/sbin/restore: ./rickf/src/network/ofx/bankinfo/7048.xml: EA set security.selinux:root:object_r:user_home_t:s0 failed: Operation not supported
extract file ./rickf/src/network/ofx/bankinfo/7049.xml
/tmp/sbin/restore: ./rickf/src/network/ofx/bankinfo/7049.xml: EA set security.selinux:root:object_r:user_home_t:s0 failed: Operation not supported
extract file ./rickf/src/network/ofx/bankinfo/7054.xml
/tmp/sbin/restore: ./rickf/src/network/ofx/bankinfo/7054.xml: EA set security.selinux:root:object_r:user_home_t:s0 failed: Operation not supported
extract file ./rickf/src/network/ofx/bankinfo/7056.xml

I believe I can just ignore the complaints above since I don't have SELinux on FreeBSD..

The only thing I'm a bit concerned about is what will happen when the tape runs out -- the volume being restored covers 3 tapes... I guess I'll find out a bit later tonight..
 
Those are extended ACL's you can indeed ignore.

Good thing it's working now. I'm enclined to blame the internal compression and/or FreeBSD's (lack of) support for it, but with these kind of things, the need to get the data far outweighs the energy/time to get to the bottom of things.

What I would suggest though, is use FreeBSD's dump to dump your smallest partition to tape, then restore it in a virgin directory on a bigger partition, using -xf. If that works, you at least know that you can backup/restore with that drive, if not try filing a PR so that this can be looked into.

Either way, thanks for the follow up :D
 
I agree.. I'll do some more fiddling but the data is slowly coming off the tape (it aint the fastest medium out there!) but it does work.. I suspect it will take the next 12+ hours to get all of the data off the 3 tapes.. Yikes!

good ol 'DLT'..
 
Ok.. Just a quick followup.. The first tape finished up sometime early this morning and ended up saying it couldn't find a crapload of files on the first tape (duh!). Anyway, I tried to get it to read the 2nd tape and it refused (i tried the '-R' command too). Anyway, I'm going to try a different approach using /bin/dd. I'm going to use dd to copy every freakin byte off the tape into one giant file representing the virtual 'tape' and then feed that into the restore program.. That ought to work -- right?
 
Ok.. Got all of my files restored -- with a few minor exceptions for some large MPEG files.. Everything worked fine using the method listed above..
 
You must log in or register to reply here.
Back
Top