#35 Issue `closed`: OBDR doesnt work on DAT320¶

Labels: bug

dagwieers opened issue at 2012-03-29 08:54:¶

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?

dagwieers commented at 2012-03-29 08:55:¶

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

dagwieers commented at 2012-03-29 14:22:¶

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 at 2012-04-11 15:52:¶

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.

dagwieers commented at 2012-04-11 16:07:¶

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 at 2012-04-11 16:42:¶

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 at 2012-05-10 18:48:¶

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

dagwieers commented at 2012-05-10 19:10:¶

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 ?

kpieth commented at 2012-05-11 07:19:¶

Yes, I did.

Mit freundlichen Grüßen
Kai-Olaf Pieth

kpieth commented at 2012-05-21 10:14:¶

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...

dagwieers commented at 2012-05-21 14:10:¶

I listened and acted :-) -> cdd89309a09dcb46501481233daa96b9efc678e5

arunmani004 commented at 2021-08-15 05:43:¶

Following Error has been occurred during OBDR Backup

Please provide solution for this issue. @kpieth @dagwieers

/usr/share/rear/lib/_input-output-functions.sh: line 328: type: sedutil-cli: not found
2021-08-14 22:57:55.953203894 Including prep/NETFS/default/400_automatic_exclude_recreate.sh
2021-08-14 22:57:55.957783259 Including prep/OBDR/default/400_check_tape_drive.sh
drive type = 114
drive status = 1509949440
sense key error = 0
residue count = 0
file number = 0
block number = 0
2021-08-14 22:57:55.968471199 ERROR: Tape in device '//dev/nst0' is not online.
===== Stack trace =====
Trace 0: /usr/sbin/rear:544 main
Trace 1: /usr/share/rear/lib/mkbackup-workflow.sh:9 WORKFLOW_mkbackup
Trace 2: /usr/share/rear/lib/framework-functions.sh:101 SourceStage
Trace 3: /usr/share/rear/lib/framework-functions.sh:49 Source
Trace 4: /usr/share/rear/prep/OBDR/default/400_check_tape_drive.sh:23 source
Trace 5: /usr/share/rear/lib/_input-output-functions.sh:458 StopIfError
Message: Tape in device '//dev/nst0' is not online.
=== End stack trace ===
2021-08-14 22:57:55.973644821 Exiting rear mkbackup (PID 118328) and its descendant processes
2021-08-14 22:57:56.994473245 rear,118328 /usr/sbin/rear -d -v mkbackup
  `-rear,118759 /usr/sbin/rear -d -v mkbackup
      `-pstree,118760 -Aplau 118328
/usr/share/rear/lib/_input-output-functions.sh: line 157: kill: (118764) - No such process
2021-08-14 22:57:57.014085058 Running exit tasks
2021-08-14 22:57:57.015415175 Exit task 'rmdir -v /tmp/rear.zppmQ2BHhrocBKE/outputfs >&2'
rmdir: removing directory, '/tmp/rear.zppmQ2BHhrocBKE/outputfs'
2021-08-14 22:57:57.017308193 Exit task 'cleanup_build_area_and_end_program'
2021-08-14 22:57:57.018538345 Finished in 2 seconds
2021-08-14 22:57:57.019723200 You should also rm -Rf /tmp/rear.zppmQ2BHhrocBKE
2021-08-14 22:57:57.020933198 End of program reached
2021-08-14 22:57:57.022100792 Exit task '(( EXIT_FAIL_MESSAGE )) && echo 'rear mkbackup failed, check /var/log/rear/rear-drapprd6.log for details' 1>&8'
2021-08-14 22:57:57.023335925 Exit task 'exec 8>&-'
2021-08-14 22:57:57.024514357 Exit task 'exec 7>&-'
2021-08-14 22:57:57.025688857 Exit task 'exec 6<&-'
2021-08-14 22:57:57.026874263 Exit task ''

pcahyna commented at 2021-08-15 05:46:¶

@arunmani004 I think you should open a new issue, instead of following up on a 10 years old one.

arunmani004 commented at 2021-08-15 06:17:¶

Thank you very much for your immediate response.

I'm New to Github Community. Please Help me to create a case regarding this issue.

gdha commented at 2021-08-15 07:59:¶

@arunmani004 Just click on the green "new issue" button and fill in the template you see appearing.
BTW this is the first sign of OBDR being still used since 2012...

pcahyna commented at 2021-08-15 19:55:¶

yes, we were discussing recently that OBDR support seems broken and nobody seems to have noticed (and we have no way to test it).

jsmeix commented at 2021-08-31 11:57:¶

Only as a final side note in this issue here
(I never used any tape device so what I write here is plain guesswork):

https://github.com/rear/rear/issues/35#issuecomment-898999159
contains

ERROR: Tape in device '//dev/nst0' is not online.

which does not look like an error inside ReaR but an error in ReaR's environment
namely that the tape device which is needed by ReaR is "not online"
so probably an admin may have to do something to make it "online"
before running "rear mkbackup".

Furthermore OBDR only works with some specific HP tape devices, cf.
https://github.com/rear/rear/pull/2625#issuecomment-863965520
https://github.com/rear/rear/pull/2625#issuecomment-863984556
https://github.com/rear/rear/pull/2625#issuecomment-864002011
but
https://github.com/rear/rear/issues/35#issuecomment-898999159
does not tell what exact tape device is used - as far as I see.

OBDR will be declared deprecated so it could be removed later, see
https://github.com/rear/rear/issues/2637

[Export of Github issue for rear/rear.]

#35 Issue closed: OBDR doesnt work on DAT320¶