OK thanks for this. I must apologize to the list for the subject line. I
suspect that whoever configured their system commented out the amcheck line
in their crontab--but I don't have a way of verifying this.
I will summarize to the list:
1. An email address that a human would read when a failure occurred needed
to be set.
I have no idea what happened to the amcheck emails. The AMANDA emails
were going
to an account no one checked for a few months.
2. The chg-disk device went without being reset for over two months.
It needed to be reset so that changer-slot would have a value. (But see
1.)
I don't know what caused the changer-slot file to become empty.
The command they needed to run was
/usr/lib/amanda/chg-disk -reset
in their configuration directory.
3. They didn't know--or bother to read--that to recover the files, you list
the first couple of lines (they configured a custom compression with bzip2):
AMANDA: SPLIT_FILE 20100222 guass.engr.ccny.cuny.edu /home1/skgottipati
part 8/
11 lev 0 comp cust program /bin/tar client_custom_compress /bin/bzip2
To restore, position tape at start of file and run:
dd if=<tape> bs=32k skip=1 | /bin/bzip2 -d | /bin/tar -xpGf -
4. Concatenating split files so that they could be unzipped and extracted
with tar seems to present a breathtaking challenge. We'll see how far they
get. (I will leave the list out of this, of course.)
Again, my apologies for distracting the list with this. I did learn about
VTapes--many thanks.
FL
On Fri, Sep 10, 2010 at 3:35 PM, Charles Curley <
[email protected]> wrote:
> On Fri, 10 Sep 2010 11:43:32 -0400
> Florian Lengyel <[email protected]> wrote:
>
> > I'm not familiar with vtapes, but in any case their amanda.conf file
> > has
> >
> > dumpcycle 1 day # the number of days in the normal dump cycle
> > runspercycle -1 # the number of amdump runs in dumpcycle days
> > # (4 weeks * 5 amdump runs per week -- just weekdays)
> > tapecycle 25 tapes # the number of tapes in rotation
> > # 4 weeks (dumpcycle) times 5 tapes per week (just
> > # the weekdays) plus a few to handle errors that
> > # need amflush and so we do not overwrite the full
> > # backups performed at the beginning of the previous
> > # cycle
> >
> >
> > (not sure why runspercycle is -1)
>
> From the amanda.conf man page:
>
> A value of -1 means guess the number of runs from the tapelist(5)
> file, which is the number of tapes used in the last dumpcycle
> days / runtapes.
>
> http://wiki.zmanda.com/man/amanda.conf.5.html
>
>
> >
> > and they have
> >
> > runtapes 5 # number of tapes to be used in a single run of amdump
> > tpchanger "chg-disk" # the tape-changer glue script
> > tapedev "file:/home1_data/backups/DailySet3/slots" # the no-rewind
>
> Is that correct? I have
>
> tapedev "file:/media/backs/amanda/DailySet1"
>
> and a bunch of "slot*" directories in DailySet1. Reading this, I would
> expect your slot* directories to be in the subdirectory "slots".
>
>
> > tape device to be used
> > changerfile "/etc/amanda/DailySet3/changer"
> > changerdev "@DEFAULT_CHANGER_DEVICE@"
>
> Odd. On my 2.5.1 configuration, changerdev is set to "/dev/null". On my
> 3.1.0 system it isn't set at all, and it defaults to "/dev/null".
>
> http://wiki.zmanda.com/man/amanda-changers.7.html
>
>
>
> >
> > The file
> >
> > /etc/amanda/DailySet3/changer
> >
> > does not exist.
>
> You may not need it, in which case I'd take it out entirely or give it
> a dummy value. On one of my systems (2.5.2p1, ancient), my entry points
> to a non-existent file, in an extant directory. On a 3.1.0 system, I
> don't have it at all. Both use vtapes.
>
>
>
>
> --
>
> Charles Curley /"\ ASCII Ribbon Campaign
> Looking for fine software \ / Respect for open standards
> and/or writing? X No HTML/RTF in email
> http://www.charlescurley.com / \ No M$ Word docs in email
>
> Key fingerprint = CE5C 6645 A45A 64E4 94C0 809C FFF6 4C48 4ECD DFDB
>
