At 16:40 16.04.2007, Jean-Louis Martineau wrote:
Because most user use tar on linux, and it's new that the blocksize is 1024.
This makes sense. What are the disadvantages of a tar backup?
You can change client-src/sendbackup-dump.c:
AM_SIZE_RE("DUMP: [0-9][0-9]* blocks", 512)
to
AM_SIZE_RE("DUMP: [0-9][0-9]* blocks", 1024)
I also fixed the bug in the latest 2.5.1p3 snapshot available from
http://www.zmanda.com/community-builds.php
I'll try it on my test system.
Jean-Louis
Sebastian Henrich wrote:
Mmh, why I'm the only person who ran into these problems?
What should I do now? amanda-2.5.2b1 is in beta phase and I thinks
it's no good idea to use it in a productional environment. Is there
a possible workaround?
Thank for helping me
Sebastian
From the debug file:
sendbackup: time 2612.878: 62: size(|): DUMP: 17753400
blocks (17337.30MB)
amanda parse the number of block but it think they are blocks of 512
bytes.
This problem is fixed only in amanda-2.5.2b1 (The MB value is used).
Jean-Louis
Sebastian Henrich wrote:
My OS is openSUSE 10.1.
server:~ # tar --version
tar (GNU tar) 1.15.1
server:~ # dump
dump 0.4b41 (using libext2fs 1.38 of 30-Jun-2005)
The last dendbackup.*.debug is attached.
Thanks
Sebastian
At 13:50 13.04.2007, Jean-Louis Martineau wrote:
The orig-kb is the size reported by the backup tool (tar, dump, ...)
It's possible that amanda doesn't parse the output correctly.
What's your OS? backup tool?
Could you post a sendbackup.*.debug file?
It's probably already fixed in a newer version.
Jean-Louis
Sebastian Henrich wrote:
Here is the result after deleting full-comp und incr-comp.
DUMP SUMMARY:
DUMPER STATS TAPER STATS
HOSTNAME DISK L ORIG-kB OUT-kB COMP% MMM:SS KB/s
MMM:SS KB/s
-------------------------- ------------------------------------
-------------
server /home 0 2229585 2833801 127.1 10:58 4307.9
15:19 3083.2
server /profile 0 4557175 4541611 99.7 21:07 3583.6
24:46 3055.3
server /daten 0 1221325 1796309 147.1 4:44 6321.5
9:46 3065.4
server /intorg 0 188995 199786 105.7 1:22 2427.2
1:07 2971.2
server /literatur 0 662255 1051091 158.7 2:36 6737.3
5:39 3097.9
server /projekte 0 8876700 11223553 126.4 43:33 4295.4
60:48 3076.9
Once again the data seems to grow while it's written to the
tape. But I think I figured out the problem. During the
calculation of the estimates everything seems to be ok and all
sizes are like the real ones on the disk. The problems start
with the dumper. The dumper doesn't compare his result with the
real sizes but with the real sizes divided by two because of
the default compression set to 0.50. A compression to 50% isn't
possible on all the disks and that why the data seems to grow.
My question is now, is this a bug of version 2.4.5? At the
moment I don't get packages for openSUSE 10.1 from SuSE or the
amanda homepage with the newest version. Perhaps I should try this next?
Thanks again
Sebastian
At 22:20 12.04.2007, Jean-Louis Martineau wrote:
I don't understand.
Did you set a 'comprate' in your dumptype? You should remove it.
Amanda will learn the compresion ratio after a few run.
For all 'info' file, you can remove the value in the
'full-comp' and 'incr-comp' line.
Jean-Louis
Sebastian Henrich wrote:
Here is the log.
Sebastian