I have had level 1 problems about 4 years ago. In that case, the level
1 behaved as a level 0, so level 1 in fact did a real full backup.
I have similar problems now again, similar, but not the same.
I have amanda 3.5.5 running which on a daily base makes cycled backup
on DDS-4 tapes of my Linux PC. This included a directory ~/pictures,
which was, because of its size, split over 5 different amanda disks (say
A-E). Disks A-D each defined 1 sub-directory (via an include), while
disk E did all remaining stuff by excluding the sub-directories defined
in A-D. This went all without any hitch and no problems.
However, recently I installed a new physical disk and transferred the
whole ~/picture tree to this extra disk, which was formatted vfat, as I
wanted to have access from Windows as well. I also thought it
better to have a different amanda.conf to enable a different
tapecycle just for ~/pictures. So a new 2nd amanda.conf was made in
its own directory and the corresponding disklist only contained the A-E
disks from the other amanda setup, where they were deleted. After I did
so, the level 1 problem started in the new setup. Looking at the
solutions of 4 years ago, I could not see the reason. As tape backups
take a long time, I made a test setup with virtual tapes (with the
wiki.zmanda as starting point) and started a number of tests. After
tweeting the various parameters I got a running amanda but with very
strange results.
My initial test disklist (with only the A-E ~/picture disks) was limited
to only 1 (A) to speed up testing, it takes a couple of minutes only.
No compression is used, because a better size estimate can be
done and pictures do not compress much anyhow. The 1st backup creates a
level 0 and the subsequent test a level 1 which is done a few minutes
later. Nothing is touching the ~/picture disk in the mean time.
For disk A (results are KB):
A: level 0 6,849,090 - level 1 40
So I was quite happy, however too early. The tests with all other
disks, which I tested one-by-one and with resetting the previous
indexfile and curinfo info in between are strange.
B: level 0 8,439,510 - level 1 3,717,090
C: level 0 6,870,230 - level 1 5,837,490
D: level 0 6,093,580 - level 1 4,058,520
E: level 0 10,240,370 - level 1 10,175,430
I repeated the tests for E, D, C & A. All level 0 backups
were identical. Level 1 for E was identical, for D & C level 1 were
different in size (5% & 20&), and for A it was correct again: only
40 KB.
The ~/picture disk is mounted as:
/dev/sdc1 /home/charles/pictures vfat
defaults,uid=1000,gid=100,umask=0022,nofail 0 0
And the disklist definitions for A-D are simply as:
fiume5.localnet Pictures_A /home/charles/pictures {
#
# pictures in the M10 directory
#
nocomp-generic
include "./A"
} 2
or B, C etc and "nocomp-generic" defined in amanda.conf.
After a couple of days looking at options, I am lost. So any suggestion
where or how to look for solutions are welcome. As far as I can see,
the new disklist and amanda.conf do not differ in essence from the
previous instalment when they were part of a single backup setup which
worked flawless (but with ~/pictures on a different linux formatted
disk). Strange.
Charles
--
Charles Stroom
email: charles at no-spam.stremen.xs4all.nl (remove the "no-spam.")
