On Mon, Sep 01, 2003 at 02:41:22PM -0700, Stefan Keel wrote:
> Hey everyone,
>
> I'm having a little difficulty with my setup after my first attempts, and
> wondered if anyone might have some advice for me. Here are a some of the
> things that I'm encountering...
>
> A general overview:
>
> I have four disks to backup, all SMB shares on an NAS...
>
> They are, with their approximate sizes...
> //mrima1/HistologyCon 4.5GB
> //mrima1/MRI 37GB
> //mrima1/users 35GB
> //mrima1/VIL_Library 7GB
>
> The tapes I'm backing up to are 40GB.
Based on a later line it seems like they are twenty, not forty.
And unless MRI and users compress (Software or Hardware) to
less than twenty GB, you will never be able to back them up.
> I have to go the poor man's approach, and have configured amanda to use the
> chg-manual script.
>
> From my understanding, I have to run amdump manually if I'm using the
> chg-manual script. Does anyone know why this is the case? If I use the
No, manual means you need to change the tapes manually.
> chg-manual script, then can I still setup amanda to do a weekly full backup,
> and nightly incremental?
I don't see where one affects the other.
However, be aware that the normal way to run amanda is each amdump run is
a mixture of some level 0's and some incrementals. Not a weekly full backup
of everything and incrementals the other days.
> Next problem is the chg-manual script itself. When it asks for the next
> tape,
> it doesn't accept the next tape. For example...
>
> I have nine tapes that I'm using for my backup...
>
> DailySet1-001 through DailySet-009. The backup starts running on the first
> tape (DailySet1-001), and when it's full, chg-manual sends me an email and
> asks me for the next tape. When I insert the next tape (DailySet1-002) into
> the drive, it reads for a minute, then spits it back out and sends me another
> email asking me for the next tape. It continues to do this repeatedly, each
> time increasing the slot number.
What do the debug logs say about the tapes it "spits out"?
> I'm using the chg-manual script with 2.4.4p1. The only changes I've made to
> it are the quotes around the grep command on line 33, and then I uncommented
Yes, Line 33 needs quotes.
> the second request() function to send email asking for the next tape. I've
> also changed the lastslot=9 on line 70 since I only have 9 tapes to work
> with.
>
> What have I missed? Do I need to declare what tapes are in what slot
> somewhere? For example...
I haven't used chg-manual. What happens if you set 'lastslot=1'?
I wonder how well the request() function you uncommented has been tested.
I presume the first fails when run from cron because there is no "tty"
attached to the program. Perhaps you could change the original request
function to write to /dev/console (or its equivalent) and make sure you
have a writable console window open.
> Lastly, the dump sequence doesn't appear to be working in the order defined
> in
> my amanda.conf file. Where I have...
>
> dumporder "sssS"
>
> ...I would assume that the dump woud do the disks in this order, based on
> size
> from smallest to largest...
Maybe the incrementals of the large ones are smaller and it is doing
incrementals
of them.
> The following is a copy of the latest email report that amanda sent from my
> most recent attempt. Any suggestions would be greatly appreciated.
>
> ----- Begin AMANDA MAIL REPORT -----
>
> These dumps were to tape DailySet1-003.
> *** A TAPE ERROR OCCURRED: [[label DailySet1-004 or new tape not found in
> rack]].
> Some dumps may have been left in the holding disk.
> Run amflush to flush them to tape.
> The next 4 tapes Amanda expects to used are: DailySet1-004, DailySet1-005,
> DailySet1-006, DailySet1-007.
>
> FAILURE AND STRANGE DUMP SUMMARY:
> vilbu //mrima1/MRI lev 0 FAILED [out of tape]
> vilbu //mrima1/MRI lev 0 FAILED ["data write: Connection reset by
> peer"]
> vilbu //mrima1/VIL_Library lev 0 FAILED [can't switch to incremental
> dump]
> vilbu //mrima1/users lev 0 FAILED [can't switch to incremental dump]
> vilbu //mrima1/MRI lev 0 FAILED [dump to tape failed]
>
>
> STATISTICS:
> Total Full Daily
> -------- -------- --------
> Estimate Time (hrs:min) 0:14
> Run Time (hrs:min) 6:14
> Dump Time (hrs:min) 1:00 1:00 0:00
> Output Size (meg) 3823.0 3823.0 0.0
> Original Size (meg) 4418.8 4418.8 0.0
> Avg Compressed Size (%) 86.5 86.5 --
> Filesystems Dumped 1 1 0
> Avg Dump Rate (k/s) 1083.7 1083.7 --
>
> Tape Time (hrs:min) 1:00 1:00 0:00
> Tape Size (meg) 3823.0 3823.0 0.0
> Tape Used (%) 19.6 19.6 0.0
> Filesystems Taped 1 1 0
> Avg Tp Write Rate (k/s) 1083.7 1083.7 --
>
> USAGE BY TAPE:
> Label Time Size % Nb
> DailySet1-003 1:00 3823.0 19.6 1
>
>
> FAILED AND STRANGE DUMP DETAILS:
>
> /-- vilbu //mrima1/MRI lev 0 FAILED ["data write: Connection reset by
> peer"]
> sendbackup: start [vilbu://mrima1/MRI level 0]
> sendbackup: info BACKUP=/usr/bin/smbclient
> sendbackup: info RECOVER_CMD=/usr/bin/smbclient -f... -
> sendbackup: info end
> \--------
>
>
> NOTES:
> planner: Adding new disk vilbu://mrima1/users.
> planner: Adding new disk vilbu://mrima1/VIL_Library.
> driver: WARNING: could not create /mnt/dump/20030829: Permission denied
Sounds like it could not work with its holding disk.
Better figure out this one.
> planner: Full dump of vilbu://mrima1/HistologyCon promoted from 5 days
> ahead.
> planner: Full dump of vilbu://mrima1/MRI promoted from 6 days ahead.
> taper: tape DailySet1-003 kb 19819264 fm 2 writing file: No space left on
> device
Here is the line that leads me to think the tape is a 20GB tape. It was
filled when it had written 19.8GB. In the middle of writing a dump.
Above it says "data connection reset by peer". I'm speculating here.
You can't write to your holding disk (permission denied message above).
So you have to write to tape directly with no holding disk.
One of your dumps (MRI I think) fails because the tape fills
(the "no space left" message). Amanda has to abort that dump and
start over again from the start of MRI - remember no holding disk,
so all those 10 or 19GB of MRI that were sent over the network
were not saved anyplace. Amanda sends you email asking for a new
tape. You are hardly as fast as a tape changer. By the time you
get the new tape inserted, the client has gotten tired of waiting
so it drops the session ("connection reset" message). Amanda notes
this and has nothing else to do with the tape so spits it out and
considers it used (shows the next 4 tapes to be used message).
Might be other things, but that is a guess.
--
Jon H. LaBadie jon AT jgcomp DOT com
JG Computing
4455 Province Line Road (609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
|
