The more I read about this, the more confused I get. I noted in my previous email that DLE home-charles behaved properly when it was dumping in level 1. For testing and to see what is actually running I am now using amdump on a single DLE as: /usr/sbin/amdump --no-taper daily_dds4 fiume.localnet home-charles
no tape, goes faster. The ps showed: root 7728 7723 2 00:13 ? 00:00:04 /bin/tar --create --file - --directory /home/charles --one-file-system --listed-incremental /var/amanda/gnutar-lists/fiume.localnethome-charles_1.new --sparse --ignore-failed-read --totals --exclude-from /tmp/amanda/sendbackup.home-charles.20140225001323.exclude . amanda 7729 7727 0 00:13 ? 00:00:00 sh -c /bin/tar -tf - 2>/dev/null | sed -e 's/^\.//' amanda 7730 7729 0 00:13 ? 2>00:00:00 /bin/tar -tf - root 7911 4644 0 00:15 pts/1 2>00:00:00 grep --color=auto /bin/tar However, although the report said that home-charles was a level 1 dump, it was actually a complete dump, so again wrong Jon was mentioning the "--atime-preserve" option, but that does seem to be used. Reading about tar at the gnu org web site I found that: "Incremental dumps depend crucially on time stamps, so the results are unreliable if you modify a file's time stamps during dumping (e.g., with the ‘--atime-preserve=replace’ option), or if you set the clock backwards." And than there is a discussion about "a special O_NOATIME option from the underlying operating system" (I think that is what Jon was referring to) and how unreliable this all is. My tar is 1.26, and the tar on my old 11.4 suse was 1.26 as well. I am wondering if I am hitting a problem in the installed kernel. It would be a pity, because currently amanda backup is of no use as it nearly does a complete backup every time. Thinking, Charles On Mon, 24 Feb 2014 01:46:52 -0500 Jon LaBadie <[email protected]> wrote: > Had another thought. All the files you back up are read; > by tar! Can you check your logfiles for the options tar > uses, both when doing the actual dumps and during the > estimate phase. > > Gnutar has a "--atime-preserve" option. Tar notes the a/mtime > stamps and after backing up the file it resets the atime. You > can do something similar with the touch command. > > "atime-preserve" can take one of two "modes", "replace" or > "system". Some kernels have a system call that allows setting > atime/mtime without changing ctime (only allowed for root). > If the mode is "system" tar tries to use that feature. But > if the kernel does not have that feature (I don't know its > name) then the "replace" mode is used. But this mode definitely > resets ctime to the current time. And I think that new ctime > would cause the file to be backed up again the next amdump. > > According to my tar manpage, the "--listed-incremental" option > is incompatible with "--atime-preserve=replace". > > Jon > -- > Jon H. LaBadie [email protected] > 11226 South Shore Rd. (703) 787-0688 (H) > Reston, VA 20190 (609) 477-8330 (C) -- Charles Stroom email: charles at no-spam.stremen.xs4all.nl (remove the "no-spam.")
