Re: tape changer

[Marc SCHAEFER]

Alan Pham [EMAIL PROTECTED] wrote:
 2. How do I configure amanda.conf so data will be APPEND to current tape 
in drive?  The default is overwrite.

This isn't wise, because be prepared to loose upto X days of backups if
the tape breaks.

Knowing that, and having evaluated your risks you can then install the
`append-patch' from
   http://www-internal.alphanet.ch/archives/local/alphanet/divers/patches/amanda/

Re: Tape verification

[Marc SCHAEFER]

Anthony Valentine [EMAIL PROTECTED] wrote:
 Does (or can) Amanda verify the contents of a tape after the backup to
 verify that it backed up properly?  Or does it do something similar already?

In addition to the amverify mentionned here, the append patch contains
an amcompare commands that use tar --compare to actually compare level-0
backups to the tape, and possibly list files that aren't on tape but
are on disk, or backwards.

Re: Getting a TOC from an existing tape?

[Marc SCHAEFER]

Paul Lussier [EMAIL PROTECTED] wrote:
 I have a tape, and want to find out what's on it directly from
 the tape.  I know I've seen this answered some where before, but
 can't seem to remember wherer.

#! /bin/sh

TAPE=/dev/nst0
COUNT=1
mt -f $TAPE rewind  dd if=$TAPE bs=32k count=1 2/dev/null | (head -1; cat  
/dev/null)  while mt -f $TAPE fsf 1 ; do
  if [ $# = 0 ]; then
 echo -n FILE $COUNT 
  else
 echo -n FILE $COUNT (real: `mt -f /dev/nst0 status | awk '/^file number/ { print 
$NF; }'`) 
  fi
  dd if=$TAPE bs=32k count=1 2/dev/null | (head -1; cat  /dev/null)
  COUNT=`expr $COUNT + 1`
done

Re: how do you test for a bad tape...?

[Marc SCHAEFER]

John W. Price [EMAIL PROTECTED] wrote:
 I'm sure this is something I should probably already know, aside from
 being mildly off-topic, but is there a way to test a tape for quality
 *before* you put a backup on it?  I just had a brand new tape come back

The built-in SCSI chg driver tests for soft error counters. Alternatively,
if using the DISASTER_RECOVERY floppy I gave the URL recently in amanda.hackers
you will be able to read the error counters and exercise the tape.

Re: amrecover problem

[Marc SCHAEFER]

John W. Price [EMAIL PROTECTED] wrote:
 amrecover: amandaidx/tcp unknown protocol

something is missing in your /etc/services.

Re: taper: FATAL syncpipe_get: w: unexpected EOF

[Marc SCHAEFER]

Charles [EMAIL PROTECTED] wrote:
 It is a 120M, it is HP's 8GB tape for the DAT8i model we're using.

maybe check you disabled compression: if you compress both software and
hardware, you may get a too large file for the tape.

Re: Listed-incremental interaction

[Marc SCHAEFER]

On Mon, 6 Aug 2001, John R. Jackson wrote:

 GNU tar.  Instead, it creates a copy of the file (xxx.new).  In the case
 of a full dump, it will copy /dev/null to the file.  Otherwise it copies

oh, I see.

 the live name for the next run.  But in the case of no-record, the
 rename is bypassed and the file effectively thrown away.

ah, that's good.

Thank you. I will verify that on the next backup :)

Listed-incremental interaction

[Marc SCHAEFER]

Hi,

assuming I use one config which has record and index (using GNU tar, thus
listed-incrementals), and one other config which has no-record and no
index.

Those two configs aren't on the same filesystems, but some ARE the same, ie
for example computer /path is in the two configurations. The idea is
to have the first config be the daily run, with 6 weeks history, one backup
a day, and the second run a monthly run, whose tapes will be kept, for
now, for some time.

Is there a risk that the GNU tar doesn't, on the day following the level 0
dump of the monthly configuration, backup some changed files because its
listed-incremental say otherwise ?  Or did I wrongly understand the concept,
and GNU tar doesn't use the OLD listed-incrementals, but the last dump
date in amandates, that I don't touch because of no-record ?

The no-record config:

   define dumptype comp-user-tar-no-index {
program GNUTAR
comment partitions dumped with tar, no index, no record
options no-record, compress-fast , skip-incr
priority high
dumpcycle 0
maxcycle 0
}

Thanks!

Re: Estimates taking a long time.

[Marc SCHAEFER]

Colin Smith [EMAIL PROTECTED] wrote:

 I'm running backups on 3 Linux systems, one of the systems is a Cobalt
 Qube. All the backups are done using GNU tar. It works OK but the

try remounting those fs noatime during estimates:

   mount / -o remount,noatime

Re: Appending incrementals

[Marc SCHAEFER]

John R. Jackson [EMAIL PROTECTED] wrote:
 Again, future work may allow this, but only after you've aced an intensive

I have implemented tape appending about one or two years ago. Your
warnings however still apply :)

Re: Userid for pre-packaging binaries

[Marc SCHAEFER]

Christopher Hamilton [EMAIL PROTECTED] wrote:
 I am trying to set it up as an optional package for a Linux
 distribution. "bin" does have a ~, it is /bin. /bin isn't exactly the

You should not install it as bin, but as user backup (as e.g Debian
does), or user amanda (as Amanda does by default).

If you install it as user bin, then, yes, .amandahosts will have to
be in ~bin, which is /bin in your case.

 standard users to select from in our distribution, I can't add one just
 for amanda. "root" is the only user we have that has an actual home

You should. SuSE and Debian do.

Re: amanda to blame for NT crashes?

[Marc SCHAEFER]

Henning P. Schmiedehausen [EMAIL PROTECTED] wrote:
 Bug according to which spec? 

According to the default assumption that no protocol flaw shall make
an OS hang or crash. What happens with some SMB servers such as
the one developped by Microsoft is that the SMB server code is
deeply buried in the OS kernel (arguably for performance reasons ---
doesn't explain why Samba, a completely user-space implementation,
has outperformed those implementations in some cases), and thus
a failure of the software will crash the OS.

Now, if you ask me, the main problem is that so far Microsoft servers
were used with Microsoft clients, and so the incorrect code paths
were never exercized. Microsoft could have done white box
testing on their own code, but they obviously haven't. They
basically write buggy code (like everyone does, sadly), and only
test it in a very limited set of circumstances --- or at least
it's what it looks like. This, added to the fact that they
usually develop/test only for one architecture will let bugs
pass through.

NB: there is a specification of SMB available (infact, well, there
are plenty `protocol levels' to choose from). I haven't kept
up on the latest CIFS/SMB news, however.