Mario Jorge Nunes Filipe wrote:
> 
> Max wrote:
> >
> > Did you make sure that you have an entry like
> >
> > tapetype DAT
> >
> > before all the tapetype definitions.  Also, you should have a line
> > that says something like
> >
> > tapedev "/dev/nst0"
> >
> > If this doesn't help, e-mail me your amanda.conf file and I'll see if
> > there are any obvious problems.  You can also try contacting the
> > amanda mailing list (see http://www.amanda.org).
> 
>         I think that both those requirements are present. In any case i'm
> sending you both amanda.conf and diklist because i have another
> question. When i tell it to do a backup it ends up saying that it's out
> of tape but it cannot incrementally backup the disk. On one the docs it
> says that when the tapes gets to the end the rest goes to the holding
> area. In my case that never happens.
> 
>         Do you think you can give me a hand with this. Thanks!
        
        Ooopss ! Forgot to include the files. Here they go

-- 
        Mario Filipe 
        [EMAIL PROTECTED]
        http://neptuno.sc.uevora.pt/~mjnf
#
# amanda.conf - sample Amanda configuration file.  
#
# If your configuration is called, say, "DailySet1", then this file
# normally goes in /etc/amanda/DailySet1/amanda.conf.
# 
# for explanation of the parameters refer to amanda(8) and
# /usr/doc/amanda/WHATS.NEW.gz 

org "Evunix1"           # your organization name for reports
mailto "mjnf"           # space separated list of operators at your site
dumpuser "root"         # the user to run dumps under
#
inparallel 1            # maximum dumpers that will run in parallel
netusage  600           # maximum net bandwidth for Amanda, in KB per sec

# a filesystem is due for a full backup once every <dumpcycle> days
dumpcycle 4 weeks       # the number of days in the normal dump cycle
tapecycle 4 tapes       # the number of tapes in rotation

bumpsize 20 MB          # minimum savings (threshold) to bump level 1 -> 2
bumpdays     1          # minimum days at each level
bumpmult     4          # threshold = bumpsize * (level-1)**bumpmult

#runtapes     9         # explained in WHATS.NEW
#tpchanger "no-changer" # the tape-changer glue script, see TAPE.CHANGERS
tapedev "/dev/nst0"     # Linux @ tuck, important: norewinding
# tapedev "/dev/nrst8"  # or use the (no-rewind!) tape device directly

tapetype DAT            # what kind of tape it is (see tapetypes below)
labelstr "^EVUNIX[0-9][0-9]*$"  # label constraint regex: all tapes must match

diskdir "/var/backup/holding"           # where the holding disk is
disksize 1100 MB                        # how much space can we use on it
#diskdir "/dumps/amanda/work"   # additionaly holding disks can be specified
#diskdir "/mnt/disk4"
#disksize 1000 MB               #       they are used round-robin


# Amanda needs a few MB of diskspace for the log and debug files,
# as well as a database.  This stuff can grow large, so the conf directory
# isn't usually appropriate.

infofile "/var/lib/amanda/Evunix1/curinfo"      # database filename
logfile  "/var/log/amanda/Evunix1/log"          # log filename

# where the index files live
indexdir "/var/lib/amanda/Evunix1/index"

# tapetypes
#
# Define the type of tape you use here, and use it in "tapetype" above.
# Some typical types of tapes are included here.  The tapetype tells amanda
# how many MB will fit on the tape, how big the filemarks are, and how
# fast the tape device is.
#
# For completeness Amanda should calculate the inter-record gaps too, but it
# doesn't.  For EXABYTE and DAT tapes this is ok.  Anyone using 9 tracks for
# amanda and need IRG calculations?  Drop me a note if so.

define tapetype QIC-60 {
    comment "Archive Viper"
    length 60 mbytes
    filemark 100 kbytes         # don't know a better value
    speed 100 kbytes            # dito
}

define tapetype DEC-DLT2000 {
    comment "DEC Differential Digital Linear Tape 2000"
    length 15000 mbytes
    filemark 8 kbytes
    speed 1250 kbytes
}

# [EMAIL PROTECTED]
# in amanda-users (Thu Dec 26 01:55:38 MEZ 1996)
define tapetype DLT {
    comment "DLT tape drives"
    length 20000 mbytes         # 20 Gig tapes
    filemark 2000 kbytes        # I don't know what this means
    speed 1500 kbytes
}

define tapetype SURESTORE-1200E {
    comment "HP AutoLoader"
    length 3900 mbytes
    filemark 100 kbytes
    speed 500 kbytes
}

define tapetype EXB-8500 {
    comment "Exabyte EXB-8500 drive on decent machine"
    length 4200 mbytes
    filemark 48 kbytes
    speed 474 kbytes                    
}

define tapetype EXB-8200 {
    comment "Exabyte EXB-8200 drive on decent machine"
    length 2200 mbytes
    filemark 2130 kbytes
    speed 240 kbytes                    
}

define tapetype HP-DAT {
    comment "DAT tape drives"
    length 1900 mbytes          # these numbers are not accurate
    filemark 100 kbytes         # but you get the idea
    speed 500 kbytes
}

define tapetype DAT {
    comment "DAT tape drives"
    length 2000 mbytes          # these numbers are not accurate
    filemark 100 kbytes         # but you get the idea
    speed 100 kbytes
}

define tapetype MIMSY-MEGATAPE {
    comment "Megatape (Exabyte based) drive through Emulex on Vax 8600"
    length 2200 mbytes
    filemark 2130 kbytes
    speed 170 kbytes            # limited by the Emulex bus interface, ugh
}

define tapetype QIC-3080 {
    comment "QIC 3080"
    length 2000 mbytes
    filemark 64 kbytes
    speed 250 kbytes
}

# dumptypes
#
# These are referred to by the disklist file.  The dumptype specifies
# certain "options" for dumping including:
#       index           - keep an index of the files backed up
#       compress-fast   - (default) compress on the client using fast algorithm
#       compress-best   - compress using the best (and slowww) algorithm
#       no-compress     - don't compress the dump output
#       srvcompress     - Compress dumps on the tape host instead of client
#                         machines.  This may be useful when a fast tape host
#                         is backing up slow clients.
#       record          - (default) record the dump in /etc/dumpdates
#       no-record       - don't record the dump, for testing
#       no-hold         - don't go to the holding disk, good for dumping
#                         the holding disk partition itself.
#       skip-full       - Skip the disk when a level 0 is due, to allow
#                         full backups outside Amanda, eg when the machine
#                         is in single-user mode.
#       skip-incr       - Skip the disk when the level 0 is NOT due.  This
#                         is used in archive configurations, where only full
#                         dumps are done and the tapes saved.
#       no-full         - Do a level 1 every night.  This can be used, for
#                         example, for small root filesystems that only change
#                         slightly relative to a site-wide prototype.  Amanda
#                         then backs up just the changes.
#
# Also, the dumptype specifies the priority level, where "low", "medium" and
# "high" are the allowed levels.  These are only really used when Amanda has
# no tape to write to because of some error.  In that "degraded mode", as
# many incrementals as will fit on the holding disk are done, higher priority
# first, to insure the important disks are dumped first.

define dumptype evunix-user {
    comment "Dump da evunix"
    options compress-best, compress, index, no-hold
    priority high
}

define dumptype always-full {
    comment "Full dump of this filesystem always"
    options no-compress
    priority high
    dumpcycle 0
    maxcycle 0
}

define dumptype comp-user-tar {
    program "GNUTAR"
    comment "partitions dumped with tar"
    options compress-fast, index, exclude-list "/etc/amanda/exclude.gtar"
    priority medium
}

define dumptype comp-root-tar {
    program "GNUTAR"
    comment "Root partitions with compression"
    options compress-fast, index, exclude-list "/etc/amanda/exclude.gtar"
    priority low
}

define dumptype user-tar {
    program "GNUTAR"
    comment "partitions dumped with tar"
    options no-compress, index, exclude-list "/etc/amanda/exclude.gtar"
    priority medium
}

define dumptype high-tar {
    program "GNUTAR"
    comment "partitions dumped with tar"
    options no-compress, index, exclude-list "/etc/amanda/exclude.gtar"
    priority high
}

define dumptype root-tar {
    program "GNUTAR"
    comment "Root partitions dumped with tar"
    options no-compress, index, exclude-list "/etc/amanda/exclude.gtar"
    priority low
}

define dumptype comp-user {
    comment "Non-root partitions on reasonably fast machines"
    options compress-fast
    priority medium
}

define dumptype nocomp-user {
    comment "Non-root partitions on slow machines"
    options no-compress
    priority medium
}

define dumptype holding-disk {
    comment "The master-host holding disk itself"
    options no-hold
    priority medium
}

define dumptype comp-root {
    comment "Root partitions with compression"
    options compress-fast
    priority low
}

define dumptype nocomp-root {
    comment "Root partitions without compression"
    options no-compress
    priority low
}

define dumptype comp-high {
    comment "very important partitions on fast machines"
    options compress-best
    priority high
}

define dumptype nocomp-high {
    comment "very important partitions on slow machines"
    options no-compress
    priority high
}

define dumptype nocomp-test {
    comment "test dump without compression, no /etc/dumpdates recording"
    options no-compress, no-record
    priority medium
}

define dumptype comp-test {
    comment "test dump with compression, no /etc/dumpdates recording"
    options compress-fast, no-record
    priority medium
}
# sample Amanda2 disklist file, derived from CS.UMD.EDU's disklist
#
# If your configuration is called, say, "DailySet1", then this file
# normally goes in /etc/amanda/DailySet1/disklist.
#
# File format is:
#
#       hostname diskdev dumptype
#
# where the dumptypes are defined by you in amanda.conf.


# At our site, root partitions have a different dumptype because they
# are of lower priority; they don't contain user data, and don't change
# much from the department prototype.  In a crunch, they can be left for
# last or skipped.

#hostname hda2 comp-user
evunix hdb1 evunix-user
#evunix hda6 evunix-user
#evunix hda8 evunix-user
#evunix hda1 evunix-user

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to