Re: Comperession/Tape Size Issues

2003-07-07 Thread Gene Heskett
On Monday 07 July 2003 18:16, Joshua D. Bello wrote:
>Thank you to everybody for their help and suggestions.  I went ahead
> and disabled hardware compression on my drive.
>
>Unfortunately, I am running into further problems in my attempts to
>clear out the previously spooled dumps with amflush.  amflush fails
>after a short time without writing anything at all to tape.
>
>Here is what happens...
>
>I rum amflush and get the following output:
>
>  Scanning /local0/ambackup/nextrials...
>20030703: found Amanda directory.
>20030704: found Amanda directory.
>
>  Multiple Amanda directories, please pick one by letter:
>A. 20030703
>B. 20030704
>  Select directories to flush [A..B]: [ALL]
>
>I get the same results, whether I pick A, B, or ALL.  The amflush
> report looks like:
>
>STATISTICS:
>
>
>"--">
>
>NOTES:
>  driver: WARNING: /local0/ambackup: 83886080 KB requested, but only
>  61325902 KB available
>  taper: tape NEXTRIALS026 kb 0 fm 0 [OK]
>
>DUMP SUMMARY:
> DUMPER STATSTAPER
> STATS HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS  KB/s
> MMM:SS KB/s --
> - --- anubis   /   
>  NO FILE TO FLUSH --- anubis  
> /local0   NO FILE TO FLUSH --- anubis  
> /usr/localNO FILE TO FLUSH ---
> anubis   /var  NO FILE TO FLUSH
> --- athene.web   / NO FILE TO
> FLUSH --- athene.web   /var  NO
> FILE TO FLUSH --- etc, etc, etc...
>
>While amflush is running, amstatus reports that everything is
> waiting to flush, as in:
>
>flush   :  47  7288612k
>   <0k, 0.00% values for everything else>
>wait to flush   :  47  7288612kk  7288612k (100.00%) (  0.00%)
>4 dumpers idle, 0 dumpers busy...
>
>The amanda log file reports:
>
>DISK amflush hades /
>DISK amflush hades /usr
> etc, etc...
>DISK amflush bali.web /var
>START amflush date 20030707
>START driver date 20030707
>WARNING driver WARNING: /local0/ambackup/nextrials: 104857600 KB
>requested, but
>only 61325652 KB available.
>STATS driver startup time 0.071
>START taper datestamp 20030707 label NEXTRIALS026 tape 0
>
>The amflush log file reports:
>
>amflush: datestamp 20030707
>driver: pid 58387 executable driver version 2.4.3b2
>driver: send-cmd time 0.004 to taper: START-TAPER 20030707
>FLUSH ra /local0 20030703 0
>/local0/ambackup/nextrials/20030703/ra._local0.0
>FLUSH ra /usr/local 20030703 1
>/local0/ambackup/nextrials/20030703/ra._usr_local
>.1
> etc, etc...
>ENDFLUSH
>driver: adding holding disk 0 dir /local0/ambackup/nextrials size
>61325652
>reserving 61325652 out of 61325652 for degraded-mode dumps
>driver: start time 0.071 inparallel 4 bandwidth 1410666408 diskspace
>61325652 di
>r OBSOLETE datestamp 20030707 driver: drain-ends tapeq LFFO
> big-dumpers sssS
>taper: pid 58388 executable taper version 2.4.3b2
>taper: page size is 4096
>taper: buffer size is 32768
>taper: buffer[00] at 0x30048000
>taper: buffer[01] at 0x3005
>taper: buffer[02] at 0x30058000
>taper: buffer[03] at 0x3006
>taper: buffer[04] at 0x30068000
>taper: buffer[05] at 0x3007
>taper: buffer[06] at 0x30078000
>taper: buffer[07] at 0x3008
>taper: buffer[08] at 0x30088000
>taper: buffer[09] at 0x3009
>taper: buffer[10] at 0x30098000
>taper: buffer[11] at 0x300a
>taper: buffer[12] at 0x300a8000
>taper: buffer[13] at 0x300b
>taper: buffer[14] at 0x300b8000
>taper: buffer[15] at 0x300c
>taper: buffer[16] at 0x300c8000
>taper: buffer[17] at 0x300d
>taper: buffer[18] at 0x300d8000
>taper: buffer[19] at 0x300e
>taper: buffer structures at 0x300e8000 for 240 bytes
>taper: read label `NEXTRIALS026' date `20030707'
>taper: wrote label `NEXTRIALS026' date `20030707'
>driver: result time 8.932 from taper: TAPER-OK
>driver: send-cmd time 8.932 to taper: FILE-WRITE 00-1
>/local0/ambackup/nextr
>ials/20030703/ra._local0.0 ra /local0 0 20030703
>driver: state time 8.932 free kps: 1410666408 space: 61325652 taper:
>writing idl
>e-dumpers: 4 qlen tapeq: 46 runq: 0 roomq: 0 wakeup: 86400
> driver-idle: not-idle
>driver: interface-state time 8.932 if : free 60 if FXP0: free
>1410065408 if
>LOCAL: free 1000
>driver: hdisk-state time 8.932 hdisk 0: free 61325652 dumpers 0
>
>This is frustrating, I need to get the spool disk flushed or else
>backups will fail completely tonight due to lack of space.
>
>Am

Re: Comperession/Tape Size Issues

2003-07-07 Thread Eric Siegerman
On Mon, Jul 07, 2003 at 03:16:33PM -0700, Joshua D. Bello wrote:
> I get the same results, whether I pick A, B, or ALL.  The amflush report
> looks like:
> 
> STATISTICS:
> 
> 
>  "--">

It would be useful if you could post the *full* versions of:
  - the amflush mail report
  - log file
  - amflush file

A few things we could learn from those, that we can't learn from
your exerpts:
  - how long amflush ran before it failed
  - did amflush complain about tape errors?
  - are you sure the DLEs *all* say "NO FILE TO FLUSH", or does
one somewhere in the middle of the list look different?
  - whatever else might turn out to be useful, but we don't yet
have enough info to even know what that is :-)

As well, the log and amflush exerpts seem to be for a
still-running amflush, not for one that's already failed.
Neither file seems to contain anything past the first few seconds
into the run.  Or is it really the case that amflush simply died
some time after t=8.932 seconds, without writing anything more to
either log file?  Hard to believe, because of the existence of a
mail report -- unless you generated the report manually with
amcleanup or amreport.  Did you?

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
|  |  /
When I came back around from the dark side, there in front of me would
be the landing area where the crew was, and the Earth, all in the view
of my window. I couldn't help but think that there in front of me was
all of humanity, except me.
- Michael Collins, Apollo 11 Command Module Pilot



Re: Comperession/Tape Size Issues

2003-07-07 Thread Joshua D. Bello
Thank you to everybody for their help and suggestions.  I went ahead and
disabled hardware compression on my drive.

Unfortunately, I am running into further problems in my attempts to
clear out the previously spooled dumps with amflush.  amflush fails
after a short time without writing anything at all to tape.

Here is what happens...

I rum amflush and get the following output:

  Scanning /local0/ambackup/nextrials...
20030703: found Amanda directory.
20030704: found Amanda directory.

  Multiple Amanda directories, please pick one by letter:
A. 20030703
B. 20030704
  Select directories to flush [A..B]: [ALL]

I get the same results, whether I pick A, B, or ALL.  The amflush report
looks like:

STATISTICS:




NOTES:
  driver: WARNING: /local0/ambackup: 83886080 KB requested, but only
  61325902 KB available
  taper: tape NEXTRIALS026 kb 0 fm 0 [OK]

DUMP SUMMARY:
 DUMPER STATSTAPER STATS
HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS  KB/s MMM:SS KB/s
-- - ---
anubis   / NO FILE TO FLUSH ---
anubis   /local0   NO FILE TO FLUSH ---
anubis   /usr/localNO FILE TO FLUSH ---
anubis   /var  NO FILE TO FLUSH ---
athene.web   / NO FILE TO FLUSH ---
athene.web   /var  NO FILE TO FLUSH ---
  etc, etc, etc...

While amflush is running, amstatus reports that everything is waiting to
flush, as in:

flush   :  47  7288612k
<0k, 0.00% values for everything else>
wait to flush   :  47  7288612kk  7288612k (100.00%) (  0.00%) 
4 dumpers idle, 0 dumpers busy...

The amanda log file reports:

DISK amflush hades /
DISK amflush hades /usr
 etc, etc...
DISK amflush bali.web /var
START amflush date 20030707
START driver date 20030707
WARNING driver WARNING: /local0/ambackup/nextrials: 104857600 KB
requested, but 
only 61325652 KB available.
STATS driver startup time 0.071
START taper datestamp 20030707 label NEXTRIALS026 tape 0

The amflush log file reports:

amflush: datestamp 20030707
driver: pid 58387 executable driver version 2.4.3b2
driver: send-cmd time 0.004 to taper: START-TAPER 20030707
FLUSH ra /local0 20030703 0
/local0/ambackup/nextrials/20030703/ra._local0.0
FLUSH ra /usr/local 20030703 1
/local0/ambackup/nextrials/20030703/ra._usr_local
.1
 etc, etc...
ENDFLUSH
driver: adding holding disk 0 dir /local0/ambackup/nextrials size
61325652
reserving 61325652 out of 61325652 for degraded-mode dumps
driver: start time 0.071 inparallel 4 bandwidth 1410666408 diskspace
61325652 di
r OBSOLETE datestamp 20030707 driver: drain-ends tapeq LFFO big-dumpers
sssS
taper: pid 58388 executable taper version 2.4.3b2
taper: page size is 4096
taper: buffer size is 32768
taper: buffer[00] at 0x30048000
taper: buffer[01] at 0x3005
taper: buffer[02] at 0x30058000
taper: buffer[03] at 0x3006
taper: buffer[04] at 0x30068000
taper: buffer[05] at 0x3007
taper: buffer[06] at 0x30078000
taper: buffer[07] at 0x3008
taper: buffer[08] at 0x30088000
taper: buffer[09] at 0x3009
taper: buffer[10] at 0x30098000
taper: buffer[11] at 0x300a
taper: buffer[12] at 0x300a8000
taper: buffer[13] at 0x300b
taper: buffer[14] at 0x300b8000
taper: buffer[15] at 0x300c
taper: buffer[16] at 0x300c8000
taper: buffer[17] at 0x300d
taper: buffer[18] at 0x300d8000
taper: buffer[19] at 0x300e
taper: buffer structures at 0x300e8000 for 240 bytes
taper: read label `NEXTRIALS026' date `20030707'
taper: wrote label `NEXTRIALS026' date `20030707'
driver: result time 8.932 from taper: TAPER-OK 
driver: send-cmd time 8.932 to taper: FILE-WRITE 00-1
/local0/ambackup/nextr
ials/20030703/ra._local0.0 ra /local0 0 20030703
driver: state time 8.932 free kps: 1410666408 space: 61325652 taper:
writing idl
e-dumpers: 4 qlen tapeq: 46 runq: 0 roomq: 0 wakeup: 86400 driver-idle:
not-idle
driver: interface-state time 8.932 if : free 60 if FXP0: free
1410065408 if 
LOCAL: free 1000
driver: hdisk-state time 8.932 hdisk 0: free 61325652 dumpers 0

This is frustrating, I need to get the spool disk flushed or else
backups will fail completely tonight due to lack of space.

Amanda has been chugging along just fine for over a year, this problem
has just now crept up as my ammount of data storage has grown.

Thanks again, you folks are super helpful!

--Joshua D. Bello

On Mon, Jul 07, 2003 at 10:26:09AM -0700, Joshua D. Bello wrote:
> I am currently experiencing problems with Amanda backup runs completing
> successfully, supposedly due to running out of tape.  I am using
> Amanda 2.4.3 on a FreeBSD 4.8-STABLE machine, backing up to 35/70GB
> DLT 7000 drive.  Compression is enabled on the drive, and we are also
> using compression within Amanda.  W

Re: Comperession/Tape Size Issues

2003-07-07 Thread Gene Heskett
On Monday 07 July 2003 13:26, Joshua D. Bello wrote:
>I am currently experiencing problems with Amanda backup runs
> completing successfully, supposedly due to running out of tape.  I
> am using Amanda 2.4.3 on a FreeBSD 4.8-STABLE machine, backing up
> to 35/70GB DLT 7000 drive.  Compression is enabled on the drive,
> and we are also using compression within Amanda.  We are getting
> nowhere near the expected 70GB compressed capacity of the tapes.
>
>I would guess that something is misconfigured somehow, and I am
> simply not catching it.  If somebody else has suggestions or
> information on how to deal with these problems, it would be greatly
> appreciated.  Thanks in advance!!
>
>--Joshua D. Bello
>
As Joshua Baker-LePain says, bad, bad, bad.

You cannot use both compressions.  In doing so, its quite likely that 
the data, already being compressed, will expand enough that what 
amanda thinks is 35Gb of data, measured after compression, will be 
enough over 35Gb to cause the tape to hit EOT, its full.

That 70Gb rating is what you'll get under ideal conditions using 
hardware only compression on 'sparse' files.

Feed that HW chip a tar.bz2, and some are smart enough to step aside, 
but if it doesn't, the file will grow.

You have 2 choices.  You can shut down the software compression and 
let the drive do its thing.  The disadvantage to that is that you'll 
have to lie to amanda and set the tapetypes capacity down 15 to 20% 
from the 70Gb the makers use as sales propaganda.  This will be 
required because amanda has no way to tell how many bytes have 
actually been written to the tape when the HW chip is in use.

Or you can shut down the hardware compression.  That will probably 
take a conversion routine applied to each tape to get rid of the 
"hey, I'm compressed" flags that will turn the compression back on 
even when the dipswitch has been set to off, this so that the drive 
can read a formerly compressed tape.  Unforch, it seems to carry over 
into the next write, maintaining the status quo.

Anyway, once thats done, then amanda can compress, probably better 
than the hardware can, and it keep track of the files compressed 
size, so it can know to within 1% of the tapes raw capacity just how 
much has been written to the media.  That would be 35Gb in your case.

Generally speaking, this group tends to recommend against useing the 
hardware compressor, particularly if the tape drive is a bit small 
for the job because the software can do a better job of squeezing, 
averageing around 40% of the input size for the output size.

Those of us who are "drive challenged" (lets face it, nothing compares 
in cost per megabyte to an old DDS2 drive) will often break our 
disklists up into smallish pieces just so we can compress that which 
can be compressed, and skip that which doesn't compress.

But those are the sorts of things you learn after running amanda for a 
while, paying attention to the emails amanda sends you.

>Relevant info:
>
>## mt status output ##
>
>Mode  Density  Blocksize  bpi  Compression
>Current:  0x1b:DLTapeIV(35GB)variable   85937IDRC
>-available modes-
>0:0x1b:DLTapeIV(35GB)variable   85937IDRC
>1:0x1b:DLTapeIV(35GB)variable   85937IDRC
>2:0x1b:DLTapeIV(35GB)variable   85937IDRC
>3:0x1b:DLTapeIV(35GB)variable   85937IDRC
>-
>Current Driver State: at rest.
>-
>File Number: 0  Record Number: 0Residual Count 0
>
>## Relevant lines of amanda.conf ##
>
>define tapetype DLT7000 {
>comment "Quantum DLT7000"
>length 35000 mbytes # 35Gb tapes
>filemark 8 kbytes   # as per all examples
>look like this
>speed 10 mbytes # not sure about this just yet
>#speed 2500 kbytes
>}
>
>## An example of the lines in disklist ##
>
>ra  /   comp-root
>ra  /varcomp-high
>ra  /usr/local  comp-user
>ra  /local0 comp-high

Break this up into much smaller pieces, staying at no more than 5% of 
the drives 35Gb capacity.  This will allow amanda to fine tune the 
schedule, eventually arriving at a very consistent amount of tape 
useage per run, but this will be over a few dumpcycles before its 
well settled.  When its all in one swell foop like '/' above, amanda 
doesn't have anything to use for 'wiggling room', which is also 
contributing to your EOT problems

I am doing 4 disks, in 2 machines here, with 44 entries in my 
disklist.  A total of over 60Gb on about 210 Gb of disks, not all of 
which is in the disklist.  After compression, I'm writing around 3.4 
Gb per run on DDS2 tapes with a tapecycle of 28, dumpcycle and 
runspercycle of 7.

Tonight I'm going to see if I can squeeze my firewalls /usr/local into 
a 45th entry.  It should compress fairly well, like its /usr/src 
do

Re: repost (chg-multi - backup to file and restore)

2003-07-07 Thread Paul Bijnens
Nicki Messerschmidt, Linksystem Muenchen GmbH wrote:
...[snip]...
/etc/amanda/finanzbuch/chg-multi.conf:
statefile /etc/amanda/finanzbuch/changer-status
firstslot 1
lastslot 10
slot 1 file:/backup/disk1/tape01
...
slot 10 file:/backup/disk1/tape10
How have set up these directories?

Following "man amanda", the directories should contain
a directory "data".  You probably have the data-directory
on the same level as tapeXX, instead of below (yes, the
example in the man page shows a way to emulate one tape
drive with the contents of the tapes next, but in your
changer, each tape should be in his own "drive").
I also needed to add the following parameters to
chg-multi.conf:
multieject 0
gravity 0
needeject 0
ejectdelay 0
(at least, without the gravity parameter, amcheck complained loud).

So you should have:
/backup/disk1/tape01/data/0*thefileontape*
instead of
/backup/disk1/tape01/0*thefileontape*
...[snip]...
Extracting files using tape drive chg-multi on host localhost.
Load tape finanzbuch_007 now
Continue [?/Y/n/s/t]? Y
EOF, check amidxtaped..debug file on localhost.
In that file you find the message:

  amidxtaped: time 0.254: slot 7: chg-multi: slot is empty

This gives a strong indication that your setup was wrong.

Try the following command too:

  $ amtape finanzbuch show
  amtape: scanning all 10 slots in tape-changer rack:
  slot 1: date 20030601 label finanzbuch_001
  ...
  slot 10: date 20030610 label finanzbuch_010
and tune your directory setup until this works fine.






Re: pre/post run commands

2003-07-07 Thread Eric Siegerman
On Mon, Jul 07, 2003 at 05:39:09PM -, Scott Petler wrote:
> I also saw the previous suggestion to try not even mounting 
> my /backup disk, that would be cool, but I don't see how I
> could set up my tapelist to do this

I think that was a misunderstanding.  If you're backing up
filesystems using dump, they don't need to be mounted.  But
you're asking about backing up *to* disk; the destination does
have to be mounted.

(Actually, perhaps one could chop a big disk into a bunch of
"tape-sized" partitions, and tell Amanda to back up to the raw
partitions by configuring chg-multi with the /dev/sdcX pathnames.
But even if you could make it work, I'm not sure it'd be worth
the bother...)

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
|  |  /
When I came back around from the dark side, there in front of me would
be the landing area where the crew was, and the Earth, all in the view
of my window. I couldn't help but think that there in front of me was
all of humanity, except me.
- Michael Collins, Apollo 11 Command Module Pilot



Re: your mail

2003-07-07 Thread Brian Cuttler
Toomas,

Thanks, I'd seen similar for doing things like putting the tape
offline after the amdump completed.

I know you can use wrappers for doing similar things on the
amanda client (when the client != server) but I've never quite
gotten that down correctly and I'm looking to start/stop a
database on an amanda client so the files are quiessed during
the dump.

What is the right way to handle surounding tasks on the amanda-client ?
(A brief example if someone doesn't mind too much...)


> > Instead of just running amdump from crontab, run something to a tune of:
> > mount /backupdisk && amdump YourConfig && umount /backupdisk

thanks,

Brian

---
   Brian R Cuttler [EMAIL PROTECTED]
   Computer Systems Support(v) 518 486-1697
   Wadsworth Center(f) 518 473-6384
   NYS Department of HealthHelp Desk 518 473-0773



[no subject]

2003-07-07 Thread Scott Petler

Thanks for the suggestion.  I suppose I would also have to do
this when using my "amcheck" in user backup's crontab.

I'll try this out...

I also saw the previous suggestion to try not even mounting 
my /backup disk, that would be cool, but I don't see how I
could set up my tapelist to do this

Scott

Toomas Aas <[EMAIL PROTECTED]> said:

> Hi!
> 
> > I am using amanda to back up to a hard disk on my system and would
> > like to protect the backed up disk from accidental erasure.  I thought
> > one way to do this would be to mount it then run amdump, and then umount 
it.
> > The disk is going to be vulnerable during the backup period, but "safe"
> > when not doing a backup or recover.  
> > 
> > Is there a way to do this?  
> 
> Instead of just running amdump from crontab, run something to a tune of:
> mount /backupdisk && amdump YourConfig && umount /backupdisk
> --
> Toomas Aas | [EMAIL PROTECTED] | http://www.raad.tartu.ee/~toomas/
> * I used to be indecisive but now I'm not sure.
> 



-- 





Re: Comperession/Tape Size Issues

2003-07-07 Thread Joshua Baker-LePain
On Mon, 7 Jul 2003 at 10:26am, Joshua D. Bello wrote

> I am currently experiencing problems with Amanda backup runs completing
> successfully, supposedly due to running out of tape.  I am using
> Amanda 2.4.3 on a FreeBSD 4.8-STABLE machine, backing up to 35/70GB
> DLT 7000 drive.  Compression is enabled on the drive, and we are also
> using compression within Amanda.  We are getting nowhere near the
> expected 70GB compressed capacity of the tapes.

Bad, bad, bad.  In trying to hardware compress already software-compressed 
data, it's going to expand.  Either:

Use software compression only, which allows amanda to better estimate tape 
usage (amanda will keep track of the compressed size of the FSs).  In this 
case, use the actual size of the tapes in your tapetype.

Or use hardware compression.  In this case, lie to amanda about how big 
your tapes are (you'll likely not get anywhere near 2X compression).  You 
save CPU cycles, but your tapelength will just be an estimate.

-- 
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University



Comperession/Tape Size Issues

2003-07-07 Thread Joshua D. Bello
I am currently experiencing problems with Amanda backup runs completing
successfully, supposedly due to running out of tape.  I am using
Amanda 2.4.3 on a FreeBSD 4.8-STABLE machine, backing up to 35/70GB
DLT 7000 drive.  Compression is enabled on the drive, and we are also
using compression within Amanda.  We are getting nowhere near the
expected 70GB compressed capacity of the tapes.

I would guess that something is misconfigured somehow, and I am simply
not catching it.  If somebody else has suggestions or information on how
to deal with these problems, it would be greatly appreciated.  Thanks in
advance!!

--Joshua D. Bello

Relevant info:

## mt status output ##

Mode  Density  Blocksize  bpi  Compression
Current:  0x1b:DLTapeIV(35GB)variable   85937IDRC
-available modes-
0:0x1b:DLTapeIV(35GB)variable   85937IDRC
1:0x1b:DLTapeIV(35GB)variable   85937IDRC
2:0x1b:DLTapeIV(35GB)variable   85937IDRC
3:0x1b:DLTapeIV(35GB)variable   85937IDRC
-
Current Driver State: at rest.
-
File Number: 0  Record Number: 0Residual Count 0

## Relevant lines of amanda.conf ##

define tapetype DLT7000 {
comment "Quantum DLT7000"
length 35000 mbytes # 35Gb tapes
filemark 8 kbytes   # as per all examples 
look like this
speed 10 mbytes # not sure about this just yet
#speed 2500 kbytes
}

## An example of the lines in disklist ##

ra  /   comp-root
ra  /varcomp-high
ra  /usr/local  comp-user
ra  /local0 comp-high



Re: pre/post run commands

2003-07-07 Thread Toomas Aas
Hi!

> I am using amanda to back up to a hard disk on my system and would
> like to protect the backed up disk from accidental erasure.  I thought
> one way to do this would be to mount it then run amdump, and then umount it.
> The disk is going to be vulnerable during the backup period, but "safe"
> when not doing a backup or recover.  
> 
> Is there a way to do this?  

Instead of just running amdump from crontab, run something to a tune of:
mount /backupdisk && amdump YourConfig && umount /backupdisk
--
Toomas Aas | [EMAIL PROTECTED] | http://www.raad.tartu.ee/~toomas/
* I used to be indecisive but now I'm not sure.



Re: large parts of /tmp/amanda-dbg/* disappear

2003-07-07 Thread Paul Bijnens
On 5/07/2003 13:15 Gene Heskett wrote:
I was under the impression that these were kept for tapecycle number 
of runs, so to have all of the 200306xx files go missing without 
amanda noticeing also surprised me.
No they are kept AMANDA_DEBUG_DAYS number of days, default 4.

To find out your number do:

   amadmin X version | grep AMANDA_DEBUG_DAYS

That is an option at configure time:

	./configure --prefix=... --with-debug-days=4

--
Paul Bijnens, XplanationTel  +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax  +32 16 397.512
http://www.xplanation.com/  email:  [EMAIL PROTECTED]
***
* I think I've got the hang of it now:  exit, ^D, ^C, ^\, ^Z, ^Q, F6, *
* quit,  ZZ, :q, :q!,  M-Z, ^X^C,  logoff, logout, close, bye,  /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt,  abort,  hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e,  kill -1 $$,  shutdown, *
* kill -9 1,  Alt-F4,  Ctrl-Alt-Del,  AltGr-NumLock,  Stop-A,  ...*
* ...  "Are you sure?"  ...   YES   ...   Phew ...   I'm out  *
***



amanda-users@amanda.org

2003-07-07 Thread Ralf Schenk
Sterpu Victor wrote:

I have succesfuly installed amanda.
However, on the servers I have installed drbd.
And it seems that amanda does not hork with drbd.
Or maybe amanda does not work with reiserfs partitions?
Does somewoane succesfuly tried this combination?
It's not drbd. It's reiserfs. You have to use tar to backup reiserfs 
partitions.

From my disklist:
...
server /home user-tar-incr-nohold local
...
From my amanda.conf:
...
define dumptype root-tar {
global
program "GNUTAR"
comment "root partitions dumped with tar"
compress none
index
exclude list "/usr/lib/amanda/exclude.gtar"
priority low
}
define dumptype user-tar-incr {
root-tar
comment "user partitions dumped with tar"
priority medium
strategy incronly
}
...
--
__
Ralf Schenk




Re: repost (chg-multi - backup to file and restore)

2003-07-07 Thread Paul Bijnens
Nicki Messerschmidt, Linksystem Muenchen GmbH wrote:
When I want to extract something I try:
amrecover -d chg-multi -C finanzbuch -s localhost -t localhost
I never tried it like that.
I just use a real device, not a chg-multi.
In "man amrecover", I find:
  If  you  want  amrecover  to use your changer, the tapedev must
  be equal to the amrecover_changer setting on the server.
What is your "amrecover_changer" setting in amanda.conf?

What happens if you do:

amrecover -d file:/backup/disk1/tape07 -C finanzbuch ...

(assuming the tape finanzbuch_007 is in tape07).

Why does amanda not recognize the changer and fetches the correct tape?
No idea, could be a bug.

What am I doing wrong? Can anyone save me some hair, because I'm still
pulling it from my head...
Instead of pulling your hair out, you could use a workaround, and
let other people pull their hair out, while locating the bug (if
it is).  You can count the hair that's left on my head on one hand 
(almost), so I've put it on my list to investigate, but don't hold
your breath, as I'm also married, father of 3 kids in a holiday period,
and have my fulltime job here too.

TIMTOWTDI, you know.

--
Paul Bijnens, XplanationTel  +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax  +32 16 397.512
http://www.xplanation.com/  email:  [EMAIL PROTECTED]
***
* I think I've got the hang of it now:  exit, ^D, ^C, ^\, ^Z, ^Q, F6, *
* quit,  ZZ, :q, :q!,  M-Z, ^X^C,  logoff, logout, close, bye,  /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt,  abort,  hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e,  kill -1 $$,  shutdown, *
* kill -9 1,  Alt-F4,  Ctrl-Alt-Del,  AltGr-NumLock,  Stop-A,  ...*
* ...  "Are you sure?"  ...   YES   ...   Phew ...   I'm out  *
***



repost (chg-multi - backup to file and restore)

2003-07-07 Thread Nicki Messerschmidt, Linksystem Muenchen GmbH
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi List,
I just downloaded amanda-2.4.4p1 and installedit, but after testing this
shiny new amanda I still got the same old problem with amanda and the
amanda changer. Here is what I've done:
amanda.conf
tpchanger "chg-multi"
amrecover_changer "chg-multi"
changerfile "/etc/amanda/finanzbuch/chg-multi.conf"
define tapetype TAPEFILE {
comment "Just so"
length 8000 mbytes
filemark 0 kbytes
speed 1784 kps
}

/etc/amanda/finanzbuch/chg-multi.conf:
statefile /etc/amanda/finanzbuch/changer-status
firstslot 1
lastslot 10
slot 1 file:/backup/disk1/tape01
...
slot 10 file:/backup/disk1/tape10

When I want to extract something I try:
amrecover -d chg-multi -C finanzbuch -s localhost -t localhost
and I get a prompt, where I can select what I want to restore. But when
ommitting "extract" I get the following:
amrecover> extract

Extracting files using tape drive chg-multi on host localhost.
The following tapes are needed: finanzbuch_007

Restoring files into directory /etc/amanda/finanzbuch
Continue [?/Y/n]? Y

Extracting files using tape drive chg-multi on host localhost.
Load tape finanzbuch_007 now
Continue [?/Y/n/s/t]? Y
EOF, check amidxtaped..debug file on localhost.
amrecover: short block 0 bytes
UNKNOWN file
amrecover: Can't read file header
extract_list - child returned non-zero status: 1
Continue [?/Y/n/r]? n
amrecover> quit
200 Good bye.


Why does amanda not recognize the changer and fetches the correct tape?
What am I doing wrong? Can anyone save me some hair, because I'm still
pulling it from my head...


Cheers and thanks
Nicki

- -- 
Linksystem Muenchen GmbH [EMAIL PROTECTED]
Schloerstrasse 10  http://www.link-m.de
80634 Muenchen Tel. 089 / 890 518-0
We make the Net work.  Fax 089 / 890 518-77
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/CSi06zWc+bXuIEMRAj3FAJ9PxNI5sqgCa1JaiDCDDbZP4G2B5gCfXY1y
cSWhK/S/oUZFK/SRtUdLCTw=
=suEd
-END PGP SIGNATURE-