Well,
This is where I'm confused. I don't know Amanda very well (I can "get
around" in it enough though), and I particularly cannot stand tape back ups.
Most frustrating things I've ever had to deal with, but I have to.
As far as I know, the way we have it set up should work. The /home directory
being split into two, it is being split into two dumps where part1dump is
defined as being the drive device sd0d being dumped with using the first
exclude: exclude "./[abcdefghijkl]*"
Part 2 dump is defined as /home with exclude "./[mnopqrstuvwxyz]*"
I never set this up in the first place and am having to figure it out.
Someone else had configured the dumps this way, and I understand the concept
of it, but the Amanda error of disk offline is not very descriptive.
I'm actually doing a test right now, where I have completely separated our
regular Daily dump cycle from a test dump, using only configuration for the
directory/disk that I am having problems with. It just finished its dump,
and failed, indicating disk offline. In my test, I am not using any exclude
at all, and am only dumping as a highdump.
I set only the following in the disklist to perform this test:
delta sd0d highdump -1 fast # /home
And the highdump is a defined standard in amanda.conf as:
define dumptype highdump {
comment "High priority dump"
global
priority high
This should not have failed if it were the excludes that were the problem.
So now I have to try to figure out what else is causing this disk offline
error. The amanda system and logs are not showing enough info to figure out
the cause of the problem. I have not been able to do any level of dumps for
this disk in about 2 weeks now. <------- not good
Tim
----- Original Message -----
From: "Jon LaBadie" <jon AT jgcomp DOT com>
To: "support" <support AT nas DOT net>
Sent: Tuesday, August 06, 2002 2:15 PM
Subject: Re: What could cause disk offline error?
On Tue, Aug 06, 2002 at 10:02:32AM -0400, support wrote:
> Am having troubles with two disks being backed up. All other disks are
> working ok, but I get these two failing as "disk offline" errors.
>
> Shows up in log as:
>
> got result for host delta disk /home: 0 -> -1K, 1 -> -1K, -1 -> -1K
> got result for host delta disk sd0d: 0 -> -1K, 2 -> -1K, -1 -> -1K
>
> Seems to be that it cannot get the size, and am wondering if that is the
> issue? (and what might fix it)
>
> My defined dumps for these disks are:
>
> define dumptype part1dump {
> comment "Delta part 1"
> global
> priority high
> exclude "./[abcdefghijkl]*"
> }
> define dumptype part2dump {
> comment "Delta part 2"
> global
> priority high
> exclude "./[mnopqrstuvwxyz]*"
>
> Whereas I'm splitting a /home directory into two parts, as it is a large
> size to attempt one backup. The exclude format seems to work ok. I tested
it
> by doing an ls -ld ./[abcdefg]* at the prompt, and it did perform a
correct
> listing of directories.
If I got it correct, you are putting /home in your disklist TWICE.
I don't know if that is possible/impossibl/might cause problems ...
Maybe someone else can answer but it doesn't seem right.
One potential problem I forsee is recovery, When you go to recover
something from the /home entry, which one will it choose?
Could there be a problem with both being "dumped" at the same time?
Have you specified a common "spindle" number in your disklist to
prevent this?
Will gnutar follow symlinks on the same file system? If so, perhaps
you could create directories /home/AtoL and /home/MtoZ. Each of the
new directories could contain symlinks to the real home dirs. Then
you can backup two different directories and skip the exclude stuff.
Actually, it will with the -h option but will seek to other fs's.
OTOH I'm pretty sure the login procedures let the "home" dir be a
symlink. You could put the real dirs in /home/AtoL ... and put
symlinks in /home.
--
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)
|
