SUMMARY: Dumping on a Sun 20GB 4mm tape autoloader

From: sssgst3@reading.ac.uk
Date: Thu May 23 1996 - 05:42:31 CDT


This appears to be bouncing so delete if you have seen it previously.

> I wrote on 13 May 1996:
> Hi everyone,
> I've got a couple of queries relating to dumping onto a Sun 20GB 4mm
> tape autoloader. Crontab jobs using /usr/lib/fs/ufs/ufsdump are used
> for dumping from Solaris 2.x and SunOS 4.1.x systems. Thus far, we
> have not been successful with SGI Irix and Linux systems.

> Queries:
> 1. On Solaris 2.4/2.5 systems, whenever the End-of-tape is detected,
> the autoloader mounts the next volume automatically. However, with
> SunOS 4.1.x systems, it crashes with Tape write error xxx feet into
> tape and the dump is aborted for the SunOS system(s). I've tried
> to insert sleep 120 or some such in the script to allow the system
> time for the autoloader to load the next tape but it invariably
> fails and the dump is aborted. Does anyone know of a solution for
> this or is there a patch from Sun? I've checked SunSolve but there
> is no mention and I've logged a call with Sun but there has been
> no response thus far.
> 2. I've tried use the autoloader for dumping SGI systems too but it seems
> that a root login access is required. I was hoping to use a dumper
> or similar login but to no avail. Does anyone know of a neat solution
> for this? Likewise, I've also tried using the autoloader for dumping
> Linux systems. Again, does anyone have a neat solution for this too?

> I've checked the FAQ but there does not appear to be anything in there
> for the queries above. For those who are in the know, I would appreciate
> your words of wisdom and I'll summarise with the appropriate
> acknowledgements.

I forgot to mention that there is no ufsdump on SunOS 4.1.x systems but there
is /etc/dump. Hence the use of the "l" option on ufsdump does not apply to
/etc/dump on SunOS 4.1.x systems.

A Sun engineer suggests the use of Soltice Backup 4.1.x (networker) so it looks
that is the way to go (if you have the financial resources). Alternatively,
a cheaper option would be to modify the various parameters like tape density,
blocking factor and dump size for now ...

Suggestions:
------------
>: From zaitcev@lab.ipmce.su
>: I think that you may try Amanda (a scheduling software). It will help you
>: with Linux systems (which can write ufsdump tapes without actual UFS, true).
>: As far as know Amanda compensates for EOT problems.

>: We use Sun Backup Copilot for years and this software works well on lovely
>: SunOS and newer Solaris machines. But Sun does not support it anymore.

>% From misawa@physics.Berkeley.edu
>% SunOS 4.x does not detect end of tape.
>% You have to mess with the tape density and tape length options for
>% dump.

>% There is a SunSolve bulletin that gives density and length numbers
>% that should work most of the time.

>$ From dhb@ssd.ray.com
>$ SunOS dump program does not process the end-of-tape condition. What I do
>$ is to estimate the size of each dump that is being written to the tape and
>$ then request the autoloader to load the next tape when I think the tape is
>$ almost full. It wastes a little tape but it works.

># From vpopa@dss.mc.xerox.com
># On 4.1.x ufsdump does not exists...therefore you should use just dump.
># If you are doing remote backups from the 2.5 machine use something like this:
># rsh 4.1.x_machine dump 0cbsdf 126 35000 40000 2.x_machine:/dev/rmt/0n /filesystem

Most of us already use such remote dump scripts ... but your blocking factor,
volulme dump size and tape density are interesting esp volume dump size.

># The optimal block factor for your autoloader is 96 ...however for me did not
># worked and I end up using the formula above. The downgrading time is only 4 min for
># a 4Gb filesystem.

Thanks to everyone who replied.

Steve



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:00 CDT