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.")