[Rear-users] Backing up to tape-drive and OBDR

[Gratien D'haese]

Hi,

I like the BACKUP=NETFS and NETFS_URL=tape:///dev/nst0 method to declare output method. Used NETFS_URL=file:///path for USB mounted filesystems on occasions. If we would use the BACKUP=TAPE rule then we still need to define the tape device somehow. With the NETFS_URL way we hit 2 flies in one go.

Just would like to mention that for USB (booting) we have now the USBFS method in SVN trunk - waiting on testers!!

Back to the tape way: OUTPUT=OBDR is required when we want to create a bootable tape. On the other hand, we should be very careful to propagate this method as not every tape drive on the market is capable of doing the OBDR booting! We may not send a false signal to the end-users...

If the following are true: BACKUP=TAPE and OUTPUT=TAPE, then we wouldn't have a bootable image, right? Unless, OBDR is the standard and that is only possible with HP branded tape drives...
Handle with care is necessary. Personally, I do not like tapes as only source for recovery purposes - they tend to get lost somehow....on the moment you most need them. 

Gratien D'haese 
IT3 Consultants 
gratien.dhaese at it3.be 
http://www.it3.be 

----- Originele e-mail  -----
Van: "Schlomo Schapiro" <schlomo at schapiro.org>
Aan: rear-users at lists.sourceforge.net
Verzonden: Donderdag 29 juli 2010 21:14:18 GMT +01:00 Amsterdam / Berlijn / Bern / Rome / Stockholm / Wenen
Onderwerp: Re: [Rear-users] Backing up to tape-drive and OBDR

Hi Dag,

On 29/07/10 10:47, Dag Wieers wrote:
> I would leave the pieces of code in, but remove any mentiones from the 
> README/documentation/presentations at least. With a bit of luck we may 
> have something working in the coming weeks.

We would be most happy to accept any patch you care to submit.

I would only ask you to maybe share your thoughts with us during the design
phase so that we can help you to write your feature most fitting to the general
ReaR design philosophy. If you don't want them public on the list, just mail us
privately.

Some thoughts:
- ATM ISO creation happens after the backup which would conflict with writing
the ISO at the beginning of the tape. I don't recall any reason why we could not
switch the backup phase and the output phase (well, maybe some very small
reasons) in general to make it easier for you. If you change this please take
care of handling the RESULT_FILES properly, e.g. adding it to the TSM backup.
- If you want to move around a lot of things please submit that as several
patches (e.g. one for moving everything around without changing much code and
another one for the new code). This would help us to do the code review because
we need to mirror your changes with the proper svn move commands to keep the
version history. As an alternative you could also send me your modified working
copy, I review it and simply commit it. Thus you could do the svn move business
yourself...
- ATM we have no case where OUTPUT and BACKUP is the same and I would like to
see some discussion on this list about how to best cut the features. Maybe have
OUTPUT=TAPE and BACKUP=TAPE or maybe BACKUP=NETFS and NETFS_URL=tape:///dev/nst0
and then OUTPUT=TAPE with some magic to set TAPE_DEVICE from NETFS_URL ... The
idea would be to maximze the code reusage from NETFS which does already a fine
job of tar backups... I would not mind renaming NETFS to BUILTIN to make it
clear that this is the built-in backup method...

Kind Regards,
Schlomo

------------------------------------------------------------------------------