Amanda-Users

RE: [LONG] Amanda Tru64 V5.1A client sendsize, /sbin/dump fails

2003-02-17 13:43:29
Subject: RE: [LONG] Amanda Tru64 V5.1A client sendsize, /sbin/dump fails
From: donald.ritchey AT exeloncorp DOT com
To: amanda-users AT amanda DOT org
Date: Mon, 17 Feb 2003 11:14:21 -0600
We use Tru64 UNIX here and we did nothing special for Amanda to work with 
our systems.  I do see a problem with the setup.  If the user is running 
with the Advanced File System (AdvFS) for Tru64 (a journaled file system 
with very fast recovery times), the standard dump command is not supported.
The proper version of the command is '/sbin/vdump' (correspondingly, the 
correct restore command is '/sbin/vrestore').  The man page for the advfs(4)

for details, as well as vdump(8) and vrestore(8).  Also, vdump is compatible

with any UNIX file systems (including UFS and NFS).  

Set up the correct commands in your build configuration and see if the 
backups work better for your system.  We use Amanda 2.4.3 and have had no 
problems with setting up the configuration.  We do use the file system mount

point in the disklist files instead of the disk device entry.

So, an excerpt of my disk list looks like:

emcspdsras2              /orabck             normal
emcspdsras2              /                   normal
emcspdsras2              /usr                normal
emcspdsras2              /opt                normal
emcspdsras2              /var                normal
emcspdsras1              /oracle             normal

Where 'normal' is:

define dumptype proto {
    comment "Prototype dump parameters"
    priority medium
    compress client fast
    index yes
    record yes
}

define dumptype normal {
    comment "Regular backup"
    proto
}

Questions for anyone else using Tru64 UNIX?

Don

Donald L. (Don) Ritchey
E-mail:  Donald.Ritchey AT exeloncorp DOT com

-----Original Message-----
From: Jon LaBadie [mailto:jon AT jgcomp DOT com]
Sent: Thursday, February 13, 2003 2:19 PM
To: amanda-users AT amanda DOT org
Subject: Re: [LONG] Amanda Tru64 V5.1A client sendsize, /sbin/dump fails


On Thu, Feb 13, 2003 at 06:14:30PM +0000, Sean McGeever wrote:
> Hi,
>       I've failed to find this precise error condition in either the 
> amanda or Tru64 archives, so any hints as to solutions would be most
welcome.
> Sorry for the length of the appended logs, but I hope by including them 
> I've provided enough data to enable someone to point me in the right 
> direction.
> 
> *******************************************************************
> 
> Tru64-client sendsize.debug:
> 
> sendsize: debug 1 pid 268247 ruid 203 euid 203 start time Thu Feb 13
17:39:50 2003
> /usr/local/libexec/sendsize: version 2.4.2p2
> calculating for amname '/', dirname '/'
> sendsize: getting size via dump for / level 0
> sendsize: running "/sbin/dump 0Ssf 1048576 - /dev/rdisk/dsk0a"
> running /usr/local/libexec/killpgrp
> dump: Cannot fopen /dev/tty for reading
> query(): fopen(): No such device or address
> dump: SIGTERM received 
> dump: The ENTIRE dump is aborted

Trying to open /dev/tty.
Seems like it is expecting an interactive session.

Maybe the Tru64 version of dump requires options
to run in a non-interactive mode?  If so, perhaps
a wrapper script replacing dump on the client
would work by supplying the needed options.

-- 
Jon H. LaBadie                  jon AT jgcomp DOT com
 JG Computing
 4455 Province Line Road        (609) 252-0159
 Princeton, NJ  08540-4322      (609) 683-7220 (fax)


************************************************************************
This e-mail and any of its attachments may contain Exelon Corporation
proprietary information, which is privileged, confidential, or subject 
to copyright belonging to the Exelon Corporation family of Companies. 
This e-mail is intended solely for the use of the individual or entity 
to which it is addressed.  If you are not the intended recipient of this 
e-mail, you are hereby notified that any dissemination, distribution, 
copying, or action taken in relation to the contents of and attachments 
to this e-mail is strictly prohibited and may be unlawful.  If you have 
received this e-mail in error, please notify the sender immediately and 
permanently delete the original and any copy of this e-mail and any 
printout. Thank You.
************************************************************************