Re: tapeless backup with amanda
On Wed, 27 Mar 2002 21:45:26 + (GMT), Dan Barnes [EMAIL PROTECTED]|said: |Has anyone out there successfully configured amanda to backup to a |spare hard drive without backing up to tape? not a solution to your problem (sorry), but a question in regards to media: is there any chance of getting Amanda to back up to CD-R or even DVD-R media? -- Malcolm HerbertThis brain intentionally [EMAIL PROTECTED]left blank
Backup to CD/hard drive?
I seem to remember someone mentioning using Amanda to back up to CD or to removable hard-drive ... can someone point me in the right direction for this? thanks. -- Malcolm HerbertThis brain intentionally [EMAIL PROTECTED]left blank
Testing ... please ignore
apologies ... making sure I can post from this address ... -- Malcolm HerbertThis brain intentionally [EMAIL PROTECTED]left blank
runtar problems ...
I'm trying to get the amanda client working on this Irix machine, using
the GNUTAR dump method.
The client is now running OK (after many and various problems which I
won't go into here) however amcheck -c reports that GNUTAR isn't available
on the client (and therefore won't dump anything)
Here's what's in /tmp/amanda/amandad.blah.debug:
|amandad: debug 1 pid 914 ruid 10002 euid 10002 start time Mon Jan 21 15:08:06 2002
|amandad: version 2.4.2p2
|amandad: build: VERSION=Amanda-2.4.2p2
|amandad:BUILT_DATE=Thu Dec 20 17:14:22 EDT 2001
|amandad:BUILT_MACH=IRIX64 orion 6.4 02121744 IP27 CC=cc
|amandad: paths: bindir=/usr/local/bin sbindir=/usr/local/sbin
|amandad:libexecdir=/usr/local/libexec mandir=/usr/local/man
|amandad:AMANDA_TMPDIR=/tmp/amanda AMANDA_DBGDIR=/tmp/amanda
|amandad:CONFIG_DIR=/usr/local/etc/amanda DEV_PREFIX=/dev/dsk/
|amandad:RDEV_PREFIX=/dev/rdsk/ DUMP=/sbin/dump
|amandad:RESTORE=/sbin/restore XFSDUMP=/sbin/xfsdump
|amandad:XFSRESTORE=/sbin/xfsrestore
|amandad:COMPRESS_PATH=/usr/sbin/gzip
|amandad:UNCOMPRESS_PATH=/usr/sbin/gzip MAILER=/usr/sbin/Mail
|amandad:listed_incr_dir=/usr/local/var/amanda/gnutar-lists
|amandad: defs: DEFAULT_SERVER=orion DEFAULT_CONFIG=DailySet1
|amandad:DEFAULT_TAPE_SERVER=orion
|amandad:DEFAULT_TAPE_DEVICE=/dev/null HAVE_MMAP HAVE_SYSVSHM
|amandad:LOCKING=POSIX_FCNTL SETPGRP_VOID DEBUG_CODE
|amandad:AMANDA_DEBUG_DAYS=4 BSD_SECURITY USE_AMANDAHOSTS
|amandad:CLIENT_LOGIN=backup FORCE_USERID HAVE_GZIP
|amandad:COMPRESS_SUFFIX=.gz COMPRESS_FAST_OPT=--fast
|amandad:COMPRESS_BEST_OPT=--best UNCOMPRESS_OPT=-dc
... which seems to indicate that runtar would be looking for
/usr/local/bin/tar. So, it's there, and the path to it is free:
|orion[/tmp/amanda] 108v#: ls -ald /usr /usr/local /usr/local/bin /usr/local/bin/tar
|drwxr-xr-x 48 root sys 4096 Jan 21 14:44 /usr
|lrwxr-xr-x1 root sys 34 Nov 7 16:25 /usr/local -
|/Mount/exsci1/sci1/local/local_sgi
|drwxrwxr-x6 root local 2802 Jan 21 15:03 /usr/local/bin
|-rwxr-xr-x1 root sys 445948 Jan 21 14:17 /usr/local/bin/tar
I thought perhaps that because /Mount/exsci1 is an NFS share that there might
be permission problems when running as the backup user, but no, it executes:
|orion[/tmp/amanda] 110v#: su - backup
|orion% /usr/local/bin/tar --version
|tar (GNU tar) 1.13
|
|Copyright (C) 1988, 92,93,94,95,96,97,98, 1999 Free Software Foundation, Inc.
|This is free software; see the source for copying conditions. There is NO
|warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
|
|Written by John Gilmore and Jay Fenlason.
... so why would I get this on the server:
|tethys: {28} amcheck -c daily
|
|Amanda Backup Client Hosts Check
|
|ERROR: orion.earth.monash.edu.au: [GNUTAR program not available]
|Client check: 3 hosts checked in 0.445 seconds, 1 problem found
|
|(brought to you by Amanda 2.4.2)
It's got me totally stumped ... the _only_ thing I can think of was
that I didn't have tar in /usr/local/bin when I compiled the client on
this machine ... and I can't find any reference to tar in within
the runtar binary using strings, either ...
Can someone help me out here?
--
Malcolm HerbertThis brain intentionally
[EMAIL PROTECTED]left blank
Re: runtar problems ...
On Sun, Jan 20, 2002 at 08:58:39PM -0800, Chris Marble wrote: |Since you didn't have gnu tar in any path when you built the amanda binary |you will have to rebuild it. Here's what I've got on one of my IRIX clients: damn ... was hoping that wouldn't be the case ... *sigh* ... OK, will try that |amandad:GNUTAR=/usr/local/freeware/bin/tar ah ... no, I don't have that ... thanks for the info. -- Malcolm HerbertThis brain intentionally [EMAIL PROTECTED]left blank
Re: runtar problems ...
On Mon, Jan 21, 2002 at 03:23:04PM +1100, Malcolm Herbert wrote: |On Sun, Jan 20, 2002 at 08:58:39PM -0800, Chris Marble wrote: ||Since you didn't have gnu tar in any path when you built the amanda binary ||you will have to rebuild it. Here's what I've got on one of my IRIX clients: | |damn ... was hoping that wouldn't be the case ... *sigh* ... OK, will try that | ||amandad:GNUTAR=/usr/local/freeware/bin/tar | |ah ... no, I don't have that ... thanks for the info. recompile and install seems to have done the trick ... thanks for the input. -- Malcolm HerbertThis brain intentionally [EMAIL PROTECTED]left blank
client start problems under Irix 6.4
I'm having a few difficulties installing a client for our Irix 6.4 server orion. I have added relevant services to /etc/services and the appropriate inetd line for this machine, as can be seen below, however all I get is the exit status line reported by inetd. Nothing is logged to /tmp/amanda. It doesn't appear as if .amandahosts is a problem, since it doesn't look like amandad is starting at all ... |orion# uname -a |IRIX64 orion 6.4 02121744 IP27 |orion# grep am /etc/services |name42/tcp # IEN 116 |whois 43/tcp nicname |domain 53/tcp nameserver # name-domain server |domain 53/udp nameserver |hostnames 101/tcp hostname# usually from sri-nic |# SGI demo programs |amanda 10080/udp |amandaidx 10082/tcp |amidxtape 10083/tcp |orion# grep amanda /etc/inetd.conf |# amanda backup stuff |amanda dgram udp waitbackup /usr/local/libexec/amandad amandad |orion# grep amanda /var/adm/SYSLOG |Dec 21 13:46:43 4D:orion inetd[23159]: /usr/local/libexec/amandad: exit status 0x100 |Dec 21 13:46:52 4D:orion inetd[23159]: /usr/local/libexec/amandad: exit status 0x100 |Dec 21 13:47:02 4D:orion inetd[23159]: /usr/local/libexec/amandad: exit status 0x100 |orion# From memory, 0x100 exit code is equivalent to the called program exiting with 1 (which is then bit shifted by 8 for some reason) ... trouble is that there is more than one place that could exit with a value of 1 within amandad.c as far as I can tell ... amandad itself does run (and works for this particular machine): if I run it from the command line it will start, and once I've killed it I do get output in /tmp/amanda: |orion# /usr/local/libexec/amandad |orion# cd /tmp/amanda |orion# ls -al |total 16 |drwx--2 backup backup46 Dec 21 14:01 . |drwxrwxrwt 16 sys sys 4096 Dec 21 14:01 .. |-rw---1 backup backup 1833 Dec 21 14:01 amandad.20011221140100.debug |orion# cat * |amandad: debug 1 pid 11824 ruid 10002 euid 10002 start time Fri Dec 21 14:01:00 2001 |/usr/local/libexec/amandad: version 2.4.2p2 |/usr/local/libexec/amandad: build: VERSION=Amanda-2.4.2p2 |/usr/local/libexec/amandad:BUILT_DATE=Thu Dec 20 17:14:22 EDT 2001 |/usr/local/libexec/amandad:BUILT_MACH=IRIX64 orion 6.4 02121744 IP27 CC=cc |/usr/local/libexec/amandad: paths: bindir=/usr/local/bin sbindir=/usr/local/sbin |/usr/local/libexec/amandad:libexecdir=/usr/local/libexec |mandir=/usr/local/man |/usr/local/libexec/amandad:AMANDA_TMPDIR=/tmp/amanda |AMANDA_DBGDIR=/tmp/amanda |/usr/local/libexec/amandad:CONFIG_DIR=/usr/local/etc/amanda |DEV_PREFIX=/dev/dsk/ |/usr/local/libexec/amandad:RDEV_PREFIX=/dev/rdsk/ DUMP=/sbin/dump |/usr/local/libexec/amandad:RESTORE=/sbin/restore XFSDUMP=/sbin/xfsdump |/usr/local/libexec/amandad:XFSRESTORE=/sbin/xfsrestore |/usr/local/libexec/amandad:COMPRESS_PATH=/usr/sbin/gzip |/usr/local/libexec/amandad:UNCOMPRESS_PATH=/usr/sbin/gzip |MAILER=/usr/sbin/Mail |/usr/local/libexec/amandad: |listed_incr_dir=/usr/local/var/amanda/gnutar-lists |/usr/local/libexec/amandad: defs: DEFAULT_SERVER=orion DEFAULT_CONFIG=DailySet1 |/usr/local/libexec/amandad:DEFAULT_TAPE_SERVER=orion |/usr/local/libexec/amandad:DEFAULT_TAPE_DEVICE=/dev/null HAVE_MMAP |HAVE_SYSVSHM |/usr/local/libexec/amandad:LOCKING=POSIX_FCNTL SETPGRP_VOID DEBUG_CODE |/usr/local/libexec/amandad:AMANDA_DEBUG_DAYS=4 BSD_SECURITY USE_AMANDAHOSTS |/usr/local/libexec/amandad:CLIENT_LOGIN=backup FORCE_USERID HAVE_GZIP |/usr/local/libexec/amandad:COMPRESS_SUFFIX=.gz COMPRESS_FAST_OPT=--fast |/usr/local/libexec/amandad:COMPRESS_BEST_OPT=--best UNCOMPRESS_OPT=-dc it looks like inetd isn't calling amandad properly or that amandad is quitting immediately (even before logging anything), so it's got me rather stumped ... unfortunately I don't know Irix all that well ... does anyone have any other ideas? -- Malcolm HerbertThis brain intentionally [EMAIL PROTECTED]left blank
Suggestions on how to proceed ...
I have recently set up Amanda on a system here and am generally pleased with how it works, although the ideal setup I have in mind doesn't seem to be immediately obvious from the documentation. I have a 160G holding disk to which I spool several 13G partitions. The tape drive is a 20G Mammoth drive, with a 10 tape stacker unit attached. I am backing up all partitions on all of the network hosts, including /, /usr and /var but obviously these don't need to be written to tape once a night - the 13G partitions contain user data and do need to be written to tape at least once a week (plus daily incrementals). I can then fit two 0-level dumps and as many incremental dumps onto one tape and stagger the 0-level dumps across my dumpcycle. These tapes would then ideally be taken offsite. The first question is how to easily stagger 0-level dumps across a dump cycle where some disks need to be backed up at different frequency to others. I initially thought that I could introduce disks to the dump cycle one after another, however this didn't work for me ... it is also likely to fail when/if there are any backup problems which need fixing ... is there an easier way to manage a backup cycle and which dumps are done when? The second question has to do with dumping streams to tape - in order to make recovery quicker, I'd like the facility to leave dumps in the holding disk area until the space they occupy is needed for more dumps ... I have enough holding disk space to hold an entire dump cycle, so leaving dumps in a near-line area would make the most sense to me ... can one dump backup streams from more than one config into the one holding area? Can one put backup streams from more than one config on the same tape? Regards, Malcolm -- Malcolm HerbertThis brain intentionally [EMAIL PROTECTED]left blank
Problems with chio tape changer under NetBSD
This may affect other versions of *BSD which also use chio to manage the tape changer, I don't know ... I seem to be having problems with the chg-chio script to manage my tape changer (an ExaByte Mammoth 10-tape unit) - chg-chio appears to want to change tapes that aren't present, even when chio has told it so ... Does anyone else have these problems with it? I am thinking of rewriting it from scratch, but I want to make sure someone hasn't already done so ... -- Malcolm HerbertThis brain intentionally [EMAIL PROTECTED]left blank
