Backup Central

From the canary;

Someone using tapes which do have a fixed, finite size, is going to get
bitten, but so far my messages appear to be going to a black hole.

Whenever planner advances the backup level to a level 4, the rest of
the system treats it as if it was a level 0.

I can raise the BUMPMULT to prevent that I suppose, but wouldn't it make
more sense to fix it? I get the impression there is a modulo 4 someplace
in the middle.

Last night planner set /home to level 4. But In
/tmp/amanda-dbug/server/Daily,
[root < at > coyote Daily]# grep level *.20101112*.debug|grep /home
shows the dumplevel as 0 in all returns. And no returns contain planner
hits as planner does not say 'level', just the number.

Moving to /tmp/amanda-dbg/client/Daily, that same grep shows the estimate
calls only:
[root < at > coyote Daily]# grep level *.20101112*.debug|grep /home
amgtar.20101112005020008.debug:Fri Nov 12 00:51:26 2010: amgtar: estimate time for /home level 0: 65.394
amgtar.20101112005020008.debug:Fri Nov 12 00:51:26 2010: amgtar: estimate size for /home level 0: 20135930 KB
amgtar.20101112005020008.debug:Fri Nov 12 00:51:47 2010: amgtar: estimate time for /home level 3: 15.648
amgtar.20101112005020008.debug:Fri Nov 12 00:51:47 2010: amgtar: estimate size for /home level 3: 3414990 KB
amgtar.20101112005020008.debug:Fri Nov 12 00:52:08 2010: amgtar: estimate time for /home level 4: 15.496
amgtar.20101112005020008.debug:Fri Nov 12 00:52:08 2010: amgtar: estimate size for /home level 4: 3316150 KB
sendsize.20101112005019.debug:Fri Nov 12 00:50:20 2010: sendsize: getting size via application API for /home /home level 0
sendsize.20101112005019.debug:Fri Nov 12 00:50:20 2010: sendsize: getting size via application API for /home /home level 3
sendsize.20101112005019.debug:Fri Nov 12 00:50:20 2010: sendsize: getting size via application API for /home /home level 4
sendsize.20101112005019.debug:Fri Nov 12 00:50:20 2010: sendsize: running: "/usr/local/libexec/amanda/application/amgtar estimate --message line
--config Daily --host coyote --device /home --disk /home --level 0 --level 3 --level 4 --exclude-list /GenesAmandaHelper-0.6/excludes --check-device
no"
sendsize.20101112005019.debug:Fri Nov 12 00:52:08 2010: sendsize: estimate size for /home level 0: 20135930 KB
sendsize.20101112005019.debug:Fri Nov 12 00:52:08 2010: sendsize: estimate size for /home level 3: 3414990 KB
sendsize.20101112005019.debug:Fri Nov 12 00:52:08 2010: sendsize: estimate size for /home level 4: 3316150 KB
sendsize.20101112005019.debug:Fri Nov 12 00:52:08 2010: sendsize: estimate time for /home all level: 107.406

But it actually did the whole 20 gigabyte level 0. gzipped to 12. ?????

--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
All work and no pay makes a housewife.

It probably did a level 0 because it was time to do it. What's the
dumpcycle? When was the last level 0?
Post the amdump.1 log file.

Gene Heskett wrote:
From the canary;

Someone using tapes which do have a fixed, finite size, is going to get
bitten, but so far my messages appear to be going to a black hole.

Whenever planner advances the backup level to a level 4, the rest of
the system treats it as if it was a level 0.

I can raise the BUMPMULT to prevent that I suppose, but wouldn't it make
more sense to fix it? I get the impression there is a modulo 4 someplace
in the middle.

Last night planner set /home to level 4. But In
/tmp/amanda-dbug/server/Daily,
[root < at > coyote Daily]# grep level *.20101112*.debug|grep /home
shows the dumplevel as 0 in all returns. And no returns contain planner
hits as planner does not say 'level', just the number.

Moving to /tmp/amanda-dbg/client/Daily, that same grep shows the estimate
calls only:
[root < at > coyote Daily]# grep level *.20101112*.debug|grep /home
amgtar.20101112005020008.debug:Fri Nov 12 00:51:26 2010: amgtar: estimate time for /home level 0: 65.394
amgtar.20101112005020008.debug:Fri Nov 12 00:51:26 2010: amgtar: estimate size for /home level 0: 20135930 KB
amgtar.20101112005020008.debug:Fri Nov 12 00:51:47 2010: amgtar: estimate time for /home level 3: 15.648
amgtar.20101112005020008.debug:Fri Nov 12 00:51:47 2010: amgtar: estimate size for /home level 3: 3414990 KB
amgtar.20101112005020008.debug:Fri Nov 12 00:52:08 2010: amgtar: estimate time for /home level 4: 15.496
amgtar.20101112005020008.debug:Fri Nov 12 00:52:08 2010: amgtar: estimate size for /home level 4: 3316150 KB
sendsize.20101112005019.debug:Fri Nov 12 00:50:20 2010: sendsize: getting size via application API for /home /home level 0
sendsize.20101112005019.debug:Fri Nov 12 00:50:20 2010: sendsize: getting size via application API for /home /home level 3
sendsize.20101112005019.debug:Fri Nov 12 00:50:20 2010: sendsize: getting size via application API for /home /home level 4
sendsize.20101112005019.debug:Fri Nov 12 00:50:20 2010: sendsize: running: "/usr/local/libexec/amanda/application/amgtar estimate --message line
--config Daily --host coyote --device /home --disk /home --level 0 --level 3 --level 4 --exclude-list /GenesAmandaHelper-0.6/excludes --check-device
no"
sendsize.20101112005019.debug:Fri Nov 12 00:52:08 2010: sendsize: estimate size for /home level 0: 20135930 KB
sendsize.20101112005019.debug:Fri Nov 12 00:52:08 2010: sendsize: estimate size for /home level 3: 3414990 KB
sendsize.20101112005019.debug:Fri Nov 12 00:52:08 2010: sendsize: estimate size for /home level 4: 3316150 KB
sendsize.20101112005019.debug:Fri Nov 12 00:52:08 2010: sendsize: estimate time for /home all level: 107.406

But it actually did the whole 20 gigabyte level 0. gzipped to 12. ?????

Don't use tar-1.24 or 1.25, they don't works with amanda according to:
http://www.mail-archive.com/bug-tar < at > gnu.org/msg02993.html

Jean-Louis

Gene Heskett wrote:
On Sunday, November 14, 2010 02:48:23 am Jean-Louis Martineau did opine:


It probably did a level 0 because it was time to do it. What's the
dumpcycle? When was the last level 0?
Post the amdump.1 log file.

Gene Heskett wrote:

From the canary;

Someone using tapes which do have a fixed, finite size, is going to
get bitten, but so far my messages appear to be going to a black
hole.

Whenever planner advances the backup level to a level 4, the rest of
the system treats it as if it was a level 0.

I can raise the BUMPMULT to prevent that I suppose, but wouldn't it
make more sense to fix it? I get the impression there is a modulo 4
someplace in the middle.

Last night planner set /home to level 4. But In
/tmp/amanda-dbug/server/Daily,
[root < at > coyote Daily]# grep level *.20101112*.debug|grep /home
shows the dumplevel as 0 in all returns. And no returns contain
planner hits as planner does not say 'level', just the number.

Moving to /tmp/amanda-dbg/client/Daily, that same grep shows the
estimate calls only:
[root < at > coyote Daily]# grep level *.20101112*.debug|grep /home
amgtar.20101112005020008.debug:Fri Nov 12 00:51:26 2010: amgtar:
estimate time for /home level 0: 65.394
amgtar.20101112005020008.debug:Fri Nov 12 00:51:26 2010: amgtar:
estimate size for /home level 0: 20135930 KB
amgtar.20101112005020008.debug:Fri Nov 12 00:51:47 2010: amgtar:
estimate time for /home level 3: 15.648
amgtar.20101112005020008.debug:Fri Nov 12 00:51:47 2010: amgtar:
estimate size for /home level 3: 3414990 KB
amgtar.20101112005020008.debug:Fri Nov 12 00:52:08 2010: amgtar:
estimate time for /home level 4: 15.496
amgtar.20101112005020008.debug:Fri Nov 12 00:52:08 2010: amgtar:
estimate size for /home level 4: 3316150 KB
sendsize.20101112005019.debug:Fri Nov 12 00:50:20 2010: sendsize:
getting size via application API for /home /home level 0
sendsize.20101112005019.debug:Fri Nov 12 00:50:20 2010: sendsize:
getting size via application API for /home /home level 3
sendsize.20101112005019.debug:Fri Nov 12 00:50:20 2010: sendsize:
getting size via application API for /home /home level 4
sendsize.20101112005019.debug:Fri Nov 12 00:50:20 2010: sendsize:
running: "/usr/local/libexec/amanda/application/amgtar estimate
--message line --config Daily --host coyote --device /home --disk
/home --level 0 --level 3 --level 4 --exclude-list
/GenesAmandaHelper-0.6/excludes --check-device no"
sendsize.20101112005019.debug:Fri Nov 12 00:52:08 2010: sendsize:
estimate size for /home level 0: 20135930 KB
sendsize.20101112005019.debug:Fri Nov 12 00:52:08 2010: sendsize:
estimate size for /home level 3: 3414990 KB
sendsize.20101112005019.debug:Fri Nov 12 00:52:08 2010: sendsize:
estimate size for /home level 4: 3316150 KB
sendsize.20101112005019.debug:Fri Nov 12 00:52:08 2010: sendsize:
estimate time for /home all level: 107.406

But it actually did the whole 20 gigabyte level 0. gzipped to 12.
?????


Another run tonight is very confusing. I let synaptic install tar-1.24,
and in tonights email from amanda there are several things that don't make
any sense in terms of the level stated vs the level performed.

Using tar-1.24, and 3.2.0-svn-3621 the levels the planner decided to use
are the levels performed, but they are reported as level 0's despite the
output sizes obviously being nothing more than the directory listing of say
10kb.

I think I am going to backup a version a night until the mistakes
disappear. But I'll start with 3.2.0.svn.3608 since I believe I saw this
the first time at that snapshot. Then 3603, 3599, 3577. Earlier than that
I start doing fresh tarballs.

amdump.1 from this messed up run is attached.

On Monday, November 15, 2010 07:21:15 am Jean-Louis Martineau did opine:

Don't use tar-1.24 or 1.25, they don't works with amanda according to:
http://www.mail-archive.com/bug-tar < at > gnu.org/msg02993.html

Jean-Louis

Which with careful reading, explains why the dumps have been so darned
small the last 2 days. So I just forced tar-1.23 back in. Thanks Jean-
Louis. In fact, I think I'll run my catchup script, set for dumpcycle +1
repeats as insurance. Humm, errors out, the directory it keeps a log file
in had gone missing. Fixed, running.

I wonder how long it will take to get a 1.26, and then get it into pclos
repo's...

--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
We reject: kings, presidents, and voting.
We believe in: rough consensus and working code.
-- Dave Clark