Problem with OBDR on DPE 3.50 SP1/Linux with ext Ultrium 460

[Ben Tullis]

Hi all.

I am suddenly experiencing a problem with my OBDR environment and I wondered whether anyone else had come across a similar situation.

Environment:
Data Protector Express 3.50 SP1 Single Server Edition with OBDR entitlement.
Debian Linux 4.0
External Ultrium 460 LTO2 drive
Kernel version 2.6.22.9

Symptoms:
Since I upgraded to SP1 of DPE I have not been able to start the recovery process from a tape.

The tape boots ok, brings you into the recovery environment, then says:

Do you want to recover?
Are you sure?
Really sure?

Starting the restore gets as far as:
Formatting all partitions

Then displays a large red error saying:
Cannot find device.
Hit enter to try again.

Operating system is trashed as a result of the OBDR process. Not very good.

I hope that someone can help me with this situation. I'm going to try reverting to a tape without the SP1 version of DPE on it, in order to verify whether it was this patch which broke it for me.

Many thanks.
Ben

[D Lancaster]

Hi Ben,

For starters, Data Protector Express is not tested on Debian Linux. A full list of supported OSes is available at ftp://ftp.compaq.com/pub/products/storage/software/datapexp/DataProtectorExpressSingleServerEditionSupportMatrix12Sep07.pdf

If OBDR isn't working, the recovery process would be:
- manually reinstall the OS
- reinstall Data Protector Express
- import the catalog from your latest recovery tape
- run the full recovery

DL

[Ben Tullis]

Thanks for your response Dave.

I've got to start by saying that I'm well aware that I'm not using a supported O/S for this project. Despite the "Official support for Debian" from HP, I know that it doesn't currently extend to this product.

Despite that, I have had it working and I would be happier with installing a Debian based system, which works, as opposed to a.n. other distribution, which is supported.

Also thank you for your instructions related to the recovery of a system from a tape which doesn't boot.
I've actually been through this "disaster recovery disaster recovery" scenario now, although I used a Live CD (Sabayon 64) to host the DPX instance, while restoring.

I've done some regression testing and found out that it is not an issue caused by SP1. There is another cause for not being able to find the tape drive.

My next move is to try changing the way in which the modules are packed into the intramfs. I have noticed that upon booting the recovery environment, there is no "st" module in /modules even though this is now being built as a modular component.

I shall try modifying /etc/initramfs-tools/initrafms.conf on the host and specifically telling it to include the st module. If that doesn't work, I shall try rebuilding all of the scsi and tape drivers into the kernel.

Does anyone know any details on how the bootable image is created? Does it include modules from your current initrd, or from /lib/modules/`uname -r`

How does it decide which to include?

Many thanks again.
Ben

[D Lancaster]

Ben,

Make sure it is loading the sg module rather than the st module. For some reason the developers chose to the use the SCSI General (sg) module rather than the SCSI Tape (St) module.

Dave

[Ben Tullis]

Many thanks again Dave. I can tell you that I've got my system back and that it wasn't an issue with SP1.

I tried the solutions outlined above:

1: Forcing the st module to be included in the initrd, by adding st to /etc/initramfs-tool/modules

Outcome: It was installed the the resulting intrd, but still didn't make it to the recovery environment.

2: Rebuilt my kernel, ensuring that the required SCSI components were built in, rather than modular

Outcome: Successful disaster recovery.

Components added included sg and st as well as scsi_transport_spi and some spare SCSI controllers.

Regarding the scsi-generic module, as opposed to the scsi-tape, I remember reading something about that in relation to the service pack.

When I was using kernel version 2.6.18 and DPX 3.50 sp1, the software wouldn't utilise the tape until I upgraded to at least 2.6.20 because it stated that there were incompatibilities with the sg module.

I had been using two different SCSI HBAs as well, up until SP1 and I'd noticed that throughput was significantly slower through the Adaptec LPE320 PCI-e card, than through the HP (LSI) dual-channel PCI-X controller.

I may have a chance to test whether the speed is better under the Adaptec card now, but I might not need to.

All in all, I have learnt a number of useful things from this episode already.

Kind regards,
Ben

[D Lancaster]

Thanks for the testing and the feedback. We can always use that to help improve our products.

DL