OBDR doesnt work on DAT320 #35

Closed
dagwieers opened this Issue Mar 29, 2012 · 10 comments

Comments

Projects
None yet
3 participants
Member

dagwieers commented Mar 29, 2012

Reported by Kai-Olaf Pieth at SF#3475615 on 2012-01-18 12:23:22 PST

Original report

installed rear 1.12 by copying etc and usr to the root file system. edited /etc/rear/local.conf to simply have OBDR Backup on /dev/st0 (HP Storageworks DAT320 USB).

OUTPUT=OBDR
BACKUP_URL=tape:///dev/nst0
BACKUP=NETFS

After sucessfull rear mkbackup i tried to boot from tape but the tape drive ejects the tape after a while and the server boots from hdd.

I then used HP Dataprotector to test OBDR functionality and this worked.

I then formated the tape again with "rear format /dev/st0"

And made rear mkbackup again with the same options.

Now I get a bootloader, but it is the Dataprotector Bootloader(look at the screenshot attached). But it surely cannot boot because the right ramdisk is missing or whatever.

Logfile said this:
2012-01-18 16:01:41 Wrote ISO Image /tmp/rear-dc-vserver.iso (39M)
2012-01-18 16:01:41 Including output/OBDR/default/81_write_image.sh
2012-01-18 16:01:41 Writing ISO image to tape
19686+0 records in
19686+0 records out
40316928 bytes (40 MB) copied, 28.0842 s, 1.4 MB/s

For me it looks like the bootloader isnt written to the tape or it is written at the wrong position?

gdha was assigned Mar 29, 2012

Member

dagwieers commented Mar 29, 2012

The original issue on Sourceforge at SF#3475615 contains a lot of additional details about this issue.

Member

dagwieers commented Mar 29, 2012

We are waiting for feedback from the original reporter in order to get this ball rolling again...

@gdha: Is there a possibility to get in contact with the reporter using private email ?

kpieth commented Apr 11, 2012

here i am! i still have to create and dump a tape from data protector express. then find out what is different. didnt find any specs that shows a difference between OBDR on DAT160 and DAT320.

Member

dagwieers commented Apr 11, 2012

Hi Kai-Olaf,

We have made a few assumptions in the past regarding the OBDR implementation that worked with the various hardware we had at that moment.

  • Padding of 20 blocks (using zeros and blocksize of 512 bytes hardcoded)
  • Label at the very start of padding (blocksize of 512 bytes hardcoded)
  • OBDR blocksize of 2048 bytes OBDR_BLOCKSIZE=2048
  • Padding, label and OBDR image are written with compression disabled

It would be nice to find out how HP DataProtector writes a bootable tape, but it could be equally useful to know whether Mondo Rescue is doing it correctly for this tape device. Unfortunately there is no tool (that I know of) to inspect what is written on a tape-device and in what blocksize. If the blocksize is incorrect you get an input/output error if I am correct. But you also get an input/output error if anything else is wrong, so a tool that attempts various access using a permutation of options and blocksizes would be very useful IMO.

In more than one occasion this would have helped a lot. Having access to various tape drives would be useful too :-)

kpieth commented Apr 11, 2012

I have all DAT and all LTO drives from HP here :-) But not the time to test them all. Tested LTO2 and DAT160 successfully. That are the drives we currently sell to customers.

Mit freundlichen Grüßen
Kai-Olaf Pieth

kpieth commented May 10, 2012

I found the time to look closer at this problem. So the problem is that after writing the rear OBDR-header, the tape is not exactly at block 20.
Although "mt -f /dev/nst0 tell" says "At block 20" dd cant read the ISO Image.

Read the Header:

TAPE_DEVICE=/dev/nst0
OBDR_BLOCKSIZE=2048
mt -f /dev/nst0 tell
At block 0.
dd if=$TAPE_DEVICE of=tape-rear-header4 bs=512 count=20
20+0 records in
20+0 records out
10240 bytes (10 kB) copied, 12.9311 s, 0.8 kB/s

Look where we are after reading the header:

mt -f /dev/nst0 tell
At block 20.

Ok it says 20, but when I try to dd, it first cannot read the iso:

mt -f "${TAPE_DEVICE}" setblk ${OBDR_BLOCKSIZE:-0}
dd if=$TAPE_DEVICE of=tape-rear-iso ${OBDR_BLOCKSIZE:+bs=$OBDR_BLOCKSIZE}
0+0 records in
0+0 records out
0 bytes (0 B) copied, 0.0291118 s, 0.0 kB/s

Without rewinding or seeking I repeat the tell command, it even says 20, but now it is at the beginning of the iso and can read it:
mt -f /dev/nst0 tell
At block 20.
dd if=$TAPE_DEVICE of=tape-rear-iso ${OBDR_BLOCKSIZE:+bs=$OBDR_BLOCKSIZE}
34049+0 records in
34049+0 records out
69732352 bytes (70 MB) copied, 18.9389 s, 3.7 MB/s

The rear tape is not bootable when the ISO is not exactly positioned. I've compared the functioning DataProtector Express tape, there the iso begins exactly at block 20.

The solution for me getting a working ReaR Tape on DAT320 was to add a line at the bottom of the WRITE_OBDR_HEADER Skript that seeks the tape exactly at block 20.
mt -f "${TAPE_DEVICE}" seek 20

I dont know yet why the tape drive does not behave like the other one's but so it is now.
Best regards
Kai-Olaf Pieth

Member

dagwieers commented May 10, 2012

Very interesting !

Small question, did you modify the device's blocksize (to 512) before padding zeroes ? You did not specifically state that. Rear should do that correctly though. If the seek 20 fixes the problem, we should add this it should not harm.

Problem is, we don't have any gear to actually test this change so are you willing to test this on all the gear you have available ?

dagwieers closed this in b7a522b May 10, 2012

kpieth commented May 11, 2012

Yes, I did.

Mit freundlichen Grüßen
Kai-Olaf Pieth

kpieth commented May 21, 2012

ReaR should only "LogIfError" because "seek" is not available on all tape drives and in 99% OBDR works without seeking.

From the mt manual:
... (SCSI tapes) Seek to the count block on the tape. This operation is available on some Tandberg and Wangtek streamers and some SCSI-2 tape drives...

Member

dagwieers commented May 21, 2012

I listened and acted :-) -> cdd8930

@jhoekx jhoekx pushed a commit to jhoekx/rear that referenced this issue May 23, 2012

@dagwieers dagwieers Since "mt seek" may not work on all tape devices, do not bail out whe…
…n it fails. Closes #35. (Kai-Olaf Pieth)
cdd8930

dagwieers was assigned May 31, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment