several incremental backup on one tape, then full back up on weekend

2001-08-02 Thread Yoshiaki Ueda

Hi,

I'm now trying to set up amanda-2.4.2p2 at Solaris 7 with DLT drives.
The DLT drive doesn't have changer feature.

I'd like to do something like:
-- level 1 dump on Monday thru Thursday night without tape change
-- 4 incremental back up jobs at one tape
-- weekly full dump on another one tape
-- 5 weeks cycle, so that total 10 tapes

How should I set dumpcycle, runspercycle and tapecycle keywords
in amanda.conf file?  And any requirements?

Thanks any response,
Yoshi

Yoshiaki Ueda
Cognex Corproation 



Re: full back up

2001-06-18 Thread Jens Krause

Hi John!

John R. Jackson wrote:

 I've tried with and without strategy noinc earlier - same behaviour.
 I will try skip-incr yes for preventing Amanda doing incrementals.

 If I've read the code correctly, you'll want skip-incr yes **in addition
 to** strategy noinc to get only full dumps.

Yes, you are right. That's what i've tried last week. I have set both
switches and it worked!
Amanda wasn't doing any levels bigger then zero, and she skipped
the disk /usr2 because of it's size (bigger than the room left in the
holdingdisk). In Amanda mail the disk was marked with FAILED.

Now i will try to add a second holdingdisk.

 Note that I'm not saying this is correct.  Just a workaround.  I suspect
 planner should have automatically assumed skip-incr yes for strategy
 noinc dumptypes.

OK, but if Amanda will working in this way, I can accept it.

 So - if Amanda will dump into the holdingdisk because of a wrong tape in
 drive - she will doing incrementals, right?

 That depends on several things.  It looks like you have reserve set to zero,

Yes, because i wanted to use all of the holdingdisk for full backups
and never doing some incrementals.

 so Amanda will go ahead and try full dumps into the holding disk.
 But my guess is you ran out of space and so it fell back to an incremental
 for /usr2.

Right! This was the behaviour I've observed.

 I'm not sure what skip-incr yes will do to this.  My guess
 is it would have failed this disk since there was not enough room.

Yups. This was exactly the result of my last weekly backup.
And this is ok.

Thanks again for your help.

Greetings,
Jens




Re: full back up

2001-06-16 Thread Jens Krause

John R. Jackson wrote:

 Not sure if you got your problem worked out with strategy noinc and
 Amanda trying to incrementals, but while helping someone else I noticed
 that if you also do skip-incr yes it should prevent Amanda from doing
 the incrementals.  I didn't test it, but that's my reading of the code.

 JJ

Hello John,

thanks again for your answer. I was in holidays for 3 weeks (Egypt -
wonderful!!!),
so I couldn't answer your emails before.

I've tried with and without strategy noinc earlier - same behaviour.
I will try skip-incr yes for preventing Amanda doing incrementals.
Next weekend I will see, if it works.
I will inform you about my results next week.

But I think, your first idea in your last email was right:
My holdingdisk seems to be too small. Our backups were growing the last
time, actually they have appr. 15 GB, but the holdingdisk only has 13 GB.
So - if Amanda will dump into the holdingdisk because of a wrong tape in
drive - she will doing incrementals, right?
That would be an explanation about the suddenly incrementals.

You asked for the amdump.nn-file. Here I can't see anything, but I've
put it together with the last Amanda email about an (not-wanted)
incremental.

Greetings,
Jens


==
Amanda-Email:

From [EMAIL PROTECTED]  Fri Jun 15 03:06:01 2001
Return-Path: [EMAIL PROTECTED]
Received: from henko.rgw-express.de ([EMAIL PROTECTED]
[193.103.162.132])
by rgw-express.de (8.11.4/8.11.4) with ESMTP id f5F160a32643
for [EMAIL PROTECTED]; Fri, 15 Jun 2001 03:06:00 +0200
Received: (from root@localhost)
by henko.rgw-express.de (8.10.2/8.10.1) id f5F160E20453
for root; Fri, 15 Jun 2001 03:06:00 +0200
Date: Fri, 15 Jun 2001 03:06:00 +0200
From: root [EMAIL PROTECTED]
Message-Id: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: tag AMANDA MAIL REPORT FOR June 15, 2001
X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/)

*** A TAPE ERROR OCCURRED: [cannot overwrite active tape
Tagessicherung.Mittwoch].
Some dumps may have been left in the holding disk.
Run amflush to flush them to tape.
The next tape Amanda expects to use is: Tagessicherung.Donnerstag.


STATISTICS:
  Total   Full  Daily
      
Estimate Time (hrs:min)0:14
Run Time (hrs:min) 1:19
Dump Time (hrs:min)1:36   1:35   0:01
Output Size (meg)9237.4 9187.4   50.0
Original Size (meg)  9237.4 9187.4   50.0
Avg Compressed Size (%) -- -- --(level:#disks ...)
Filesystems Dumped7  6  1   (1:1)
Avg Dump Rate (k/s)  1637.1 1646.2  812.0

Tape Time (hrs:min)0:00   0:00   0:00
Tape Size (meg) 0.00.00.0
Tape Used (%)   0.00.00.0
Filesystems Taped 0  0  0
Avg Tp Write Rate (k/s) -- -- --


DUMP SUMMARY:
 DUMPER STATSTAPER STATS
HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS  KB/s MMM:SS  KB/s
-- - 
focus/   0 14598721459872   --   65:25 371.9   N/A   N/A
gretel   /   0 29146242914624   --   13:303596.1   N/A   N/A
gretel   -t/informix 0   65216  65216   --0:125388.2   N/A   N/A
gretel   /usr2   1   51200  51200   --1:03 812.0   N/A   N/A
gretel   /usr5   0 45281284528128   --   10:147371.8   N/A   N/A
henko/   0  312224 312224   --4:561056.3   N/A   N/A
henko/opt0  127808 127808   --0:57.8   N/A   N/A

(brought to you by Amanda version 2.4.2p2)


==
Amdump.1:

amdump: start at Fri Jun 15 01:47:00 CEST 2001
planner: pid 19885 executable /usr/local/libexec/planner version 2.4.2p2
planner: build: VERSION=Amanda-2.4.2p2
planner:BUILT_DATE=Tue May 8 10:49:59 CEST 2001
planner:BUILT_MACH=Linux henko 2.2.19 #3 Wed Apr 4 09:43:03 CEST
2001 i686 unknown
planner:CC=gcc
planner: paths: bindir=/usr/local/bin sbindir=/usr/local/sbin
planner:libexecdir=/usr/local/libexec mandir=/usr/local/man
planner:AMANDA_TMPDIR=/tmp/amanda AMANDA_DBGDIR=/tmp/amanda
planner:CONFIG_DIR=/usr/local/etc/amanda DEV_PREFIX=/dev/
planner:RDEV_PREFIX=/dev/ DUMP=/sbin/dump
planner:RESTORE=/sbin/restore GNUTAR=/bin/gtar
planner:COMPRESS_PATH=/usr/bin/gzip
planner:UNCOMPRESS_PATH=/usr/bin/gzip MAILER=/usr/bin/Mail
planner:listed_incr_dir=/usr/local/var/amanda/gnutar-lists
planner: defs:  DEFAULT_SERVER=henko DEFAULT_CONFIG=DailySet1
planner:DEFAULT_TAPE_SERVER=henko
planner:DEFAULT_TAPE_DEVICE=/dev/null HAVE_MMAP HAVE_SYSVSHM
planner:LOCKING=POSIX_FCNTL SETPGRP_VOID DEBUG_CODE

Re: full back up

2001-05-16 Thread John R. Jackson

All was working well, but since a few weeks my weekly configuration is
trying to do a level 2 backup of the disk /usr2.  ...

Others are reporting problems with strategy noinc.  I'd need to see
the amdump.nn file that went along with Amanda doing something other
than a level 0.

Last week i forced a full backup of
this disk via
amadmin, but the last backup failed again with

FAILURE AND STRANGE DUMP SUMMARY:
  gretel /usr2 lev 0 FAILED [can't switch to incremental dump]

Again, I'd need to see the amdump.nn file.  As a guess, you might be
out of holding disk space.  That would cause Amanda to fail to do the
full dump and also not switch to an incremental (either because of the
force or strategy noinc).  Or it could be something else.

It might also be useful to grep for /usr2 in the log.MMDD.nn
file and see whether any other messages were present, but amreport just
didn't display them.

I have nothing changed on the Amanda server, in the configurations or
something else. So why is Amanda trying to do incrementals since a
few weeks?

What makes you think it's trying to do incrementals?  I didn't see any
evidence of that in the report you sent.

The can't switch to incremental dump message doesn't mean it tried to
do an incremental.  It means it couldn't do a full and while it normally
would have tried an incremental, something prevented that.

I agree there should be more messages about why it failed.

Jens Krause

John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]

P.S.  You might take a look at columnspec in amanda.conf.  It would
clean up the Amanda reports so the columns don't run together.



full back up

2001-05-14 Thread Jens Krause

Hello!

I've got a problem with my Amanda installation:

I am using Amanda version 2.4.2p2 on SuSE-Linux 6.3 (i386) - Kernel
2.2.19.

Amanda should always do only full backups daily (Mo to Fr), weekly
(every Sa)
and monthly (every 1st Day in month).
For that i have 3 configurations, and all have the same settings
(without configname
and no of tapes):

# general parameters
- dumpcycle 0 day  # the number of days in the normal dump cycle

# dumptypes
define dumptype global {
   strategy noinc
...

All was working well, but since a few weeks my weekly configuration is
trying to do
a level 2 backup of the disk /usr2. Last week i forced a full backup of
this disk via
amadmin, but the last backup failed again with

FAILURE AND STRANGE DUMP SUMMARY:
  gretel /usr2 lev 0 FAILED [can't switch to incremental dump]

First this behaviour occured with Amanda 2.4.2b2, so i updated to
2.4.2p2 last week. But Amanda is trying to continue to do incrementals.

Because of the description in amanda.conf (2.4.2b2)

# noinc- do level 0 dumps every time.
#  Unfortunately, this is not currently
#  implemented.  Use `dumpcycle 0'
#  instead.

I commented out this command, but nothing changes.

I have nothing changed on the Amanda server, in the configurations or
something else. So why is Amanda trying to do incrementals since a
few weeks?

Please reply to me directly, because i'm not subscribed in the list
anymore.

I have attached the Amanda-email my amanda.conf.

Greetings,
Jens Krause


-

Email:

Subject: woche AMANDA MAIL REPORT FOR May 13, 2001
X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/)

*** A TAPE ERROR OCCURRED: [label Tagessicherung.Freitag doesn't match
labelstr ^Wochensicherung.Woche[1-5]].
Some dumps may have been left in the holding disk.
Run amflush to flush them to tape.
The next tape Amanda expects to use is: Wochensicherung.Woche2.

FAILURE AND STRANGE DUMP SUMMARY:
  gretel /usr2 lev 0 FAILED [can't switch to incremental dump]


STATISTICS:
  Total   Full  Daily
      
Estimate Time (hrs:min)0:08
Run Time (hrs:min) 1:33
Dump Time (hrs:min)1:25   1:25   0:00
Output Size (meg)8437.5 8437.50.0
Original Size (meg)  8437.5 8437.50.0
Avg Compressed Size (%) -- -- --
Filesystems Dumped6  6  0
Avg Dump Rate (k/s)  1696.0 1696.0--

Tape Time (hrs:min)0:00   0:00   0:00
Tape Size (meg) 0.00.00.0
Tape Used (%)   0.00.00.0
Filesystems Taped 0  0  0
Avg Tp Write Rate (k/s) -- -- --


NOTES:
  planner: Forcing full dump of henko:/ as directed.
  planner: Forcing full dump of henko:/opt as directed.
  planner: Forcing full dump of gretel:/ as directed.
  planner: Forcing full dump of gretel:/opt/informix as directed.
  planner: Forcing full dump of gretel:/usr2 as directed.
  planner: Forcing full dump of gretel:/usr5 as directed.
  planner: Forcing full dump of focus:/ as directed.


DUMP SUMMARY:
 DUMPER STATSTAPER STATS

HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS  KB/s MMM:SS
KB/s
-- -

focus/   0 146146   --   60:17 403.7   N/A   N/A

gretel   /   0 28648322864832   --   13:163599.8   N/A   N/A

gretel   -t/informix 0   65088  65088   --0:106199.8   N/A   N/A

gretel   /usr2   0 FAILED
---
gretel   /usr5   0 38152003815200   --7:597961.3   N/A   N/A

henko/   0  307040 307040   --2:252120.8   N/A   N/A

henko/opt0  127808 127808   --0:482685.1   N/A   N/A

(brought to you by Amanda version 2.4.2p2)


-

amanda.conf:

#
# amanda.conf - sample Amanda configuration file.  This started off life
as
#   the actual config file in use at CS.UMD.EDU.
#
# If your configuration is called, say, csd, then this file normally
goes
# in @CONFIG_DIR@/csd/amanda.conf.
#


# general parameters
#
org woche# your organization name for reports
mailto root# space separated list of operators at your site
dumpuser root # the user to run dumps under

inparallel 5  # maximum dumpers that will run in parallel
netusage  1200 Kbps # maximum net bandwidth for Amanda, in KB per sec

dumpcycle 0 day  # the number of days in the normal dump cycle
runspercycle 0 day  # the number of amdump runs in dumpcycle days