My amanda backup seems now to be working normally. This evening, the 4th scheduled amdump finished properly.
And of course, as usual, principally it was a matter of RTFM. Pondering about why my previous amanda (3.3.2) setup was working on my previous suse 11.4 and not any more now in suse 13.1, I noticed that the few DLEs which behaved normally were on unencrypted volumes, while in 11.4 everything was unencrypted. I started to read the tar manual again but found nothing about tarring encrypted volumes. However only now I noted the remarks about " there are a number of cases where relying on device numbers can cause spurious redumping of unmodified files. For example, this occurs when archiving LVM snapshot volumes", and I do have LVMs on a RAID2 configuration! Although I did have LVM/Raid2 on 11.4 as well where all was working, I added the "no-check-device" (via amgtar) and this seems now to have cured the problem. So far, 3 scheduled amdumps (after the initial first run with all level 0) have been withperformed and all level 1 DLEs behaved as it should. Strange that in fact the encryption seems to make the difference, not the LVM/Raid. I had seen this remark on device numbers before, but my knowledge is too limited to have grasped the effects. I remained puzzled nevertheless about all my tests, where all (simulated) level 1s were working normally, all without the "no-check-device". Even manual tar tests with amanda DLEs were working, but then not working in the next scheduled amdump. Until I realised that all my tests were done one after the other, but the amdump was done after the PC was rebooted (this is my personal PC, which is shutdown every night). So I repeated my manual tar tests, and indeed, they worked even without the "no-check-device", but failed if I did a reboot in between. But I still keep my fingers crossed. Regards, Charles On Wed, 26 Feb 2014 23:13:32 +0100 Charles Stroom <[email protected]> wrote: > and this evening the first scheduled backup and it failed miserably > with exactly the same symptoms as before: all level 1 DLEs are equal > in size to a level 0, with the exception of only 2 DLEs (and heaven > may know why!) > > I think I give up. > > Regards, Charles > > > On Wed, 26 Feb 2014 00:54:09 +0100 > Charles Stroom <[email protected]> wrote: > > > As said, I changed to tar 1.27 and now the problem has > > disappeared. I cleaned all what was necessary and started with a > > full backup on all DLEs. There was some strange tar message on the > > single dle at the external client stremen ("... /usr/local/bin/tar > > exited with status 2 .."), but as this was a dle which worked > > normally also with the previous version of tar on stremen, I > > decided to revert that single dumptype to not > > using /usr/local/bin/tar (1.27). > > > > I forced all fiume (the server/client) dle to level 1 and did a > > subsequent amdump. All worked fine, and the single stremen dle was > > also ok on level 0. > > > > Then I forced everything to level 1, including stremen and did a 3rd > > amdump. Everything OK! The small problem with 1.27 tar on stremen > > will have to wait. I checked a file with stat at various stages, > > but the times are not affected by tar 1.27 at all, they don't > > change a bit. > > > > Because tar 1.26 worked without problems in my previous suse 11.4 > > with kernel 2.6.37, but does not want to work with my current suse > > 13.1 with 3.11.10 kernel, I suppose there is some incompatibility > > between them. > > > > I keep my fingers crossed. Again many thanks for the assistance. > > > > Regards, Charles > > > > > > > > > > On Tue, 25 Feb 2014 17:48:13 +0100 > > Charles Stroom <[email protected]> wrote: > > > > > Jean-Louis, > > > > > > It's getting complicated, because in my previous post below I > > > reported that with option "--atime-preserve=system" a level 1 tar > > > incremental worked. However, some time later it didn't work any > > > more, so it is really "unpredictable". > > > > > > I have repeated part of below with some stat in between. Results > > > are in attachment tar_1.26_incremental. It seems that in the > > > first create tar changes atime. > > > > > > Because I got no good results so far, I have installed the latest > > > 1.27 tar from gnu, which is in /usr/local/bin and repeated the > > > results from above. With 1.27 no times are changed at level 0 or > > > level 1. Results in attachment tar_1.27_incremental. > > > > > > Both tests actually did (now) a proper incremental tar as can be > > > seen from the the size of the created files: > > > -rw-r--r-- 1 charles users 379238400 Feb 25 17:23 wine_docs_0.tar > > > -rw-r--r-- 1 charles users 71680 Feb 25 17:24 wine_docs_1.tar > > > -rw-r--r-- 1 charles users 13405 Feb 25 17:24 wine_docs.snar > > > -rw-r--r-- 1 charles users 1785 Feb 25 17:28 > > > tar_1.26_incremental -rw-r--r-- 1 charles users 379238400 Feb 25 > > > 17:36 wine_docs_0_1.27.tar -rw-r--r-- 1 charles users 71680 > > > Feb 25 17:36 wine_docs_1_1.27.tar -rw-r--r-- 1 charles users > > > 13405 Feb 25 17:36 wine_docs_1.27.snar -rw-r--r-- 1 charles users > > > 2100 Feb 25 17:39 tar_1.27_incremental > > > > > > > > > I am now continuing with amanda, but testing takes much longer. > > > But my best bet now is to use 1.27 and I will use amgtar to do > > > achieve that. > > > > > > Regards, Charles > > > > > > > > > > > -- > > Charles Stroom > > email: charles at no-spam.stremen.xs4all.nl (remove the "no-spam.") > > > -- > Charles Stroom > email: charles at no-spam.stremen.xs4all.nl (remove the "no-spam.") -- Charles Stroom email: charles at no-spam.stremen.xs4all.nl (remove the "no-spam.")
