Thanks, and indeed my investigations into possible a/m/ctime problems
were a red herring. Something learned.
Regards, Charles
On Sun, 2 Mar 2014 18:48:03 -0500
Nathan Stratton Treadway natha...@ontko.com wrote:
On Tue, Feb 25, 2014 at 10:53:07 +0100, Charles Stroom wrote:
I than repeated
When installing suse 13.1, there is the option to encrypt the
particular LV in its entirety. That is what I selected. This was done
for several LVs used, not for the root volume and /boot. As my
knowledge of linux is not very deep, that is all I can tell you. On
the other hand, if it was only
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
On Mon, Feb 24, 2014 at 01:44:07 +0100, Charles Stroom wrote:
you say that files in the gnutar-lists contain the datestamp/stat
of the files backed-up? How can I see the contents of these files,
because they are binary files? Is there a specific am* command?
Sorry this reply is so late, but
On Tue, Feb 25, 2014 at 10:53:07 +0100, Charles Stroom wrote:
I than repeated the whole sequence, with the --atime-preserve=replace
added, and there is no change: again full incremental backup.
And than again but now with --atime-preserve=system and now this
works!
Right. If you include
On Sun, Mar 02, 2014 at 21:57:59 +0100, Charles Stroom wrote:
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.
You didn't say
On Sun, Mar 02, 2014 at 19:20:30 -0500, Nathan Stratton Treadway wrote:
On Sun, Mar 02, 2014 at 21:57:59 +0100, Charles Stroom wrote:
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
Testing my problem has taken nearly 2 weeks, also because my quick
tests with tar options but on smaller directories do not produce the
erroneous results as the full amdumps do, which take long times. The
tests were also rather haphazard.
I might try to identify the problems, but will do so more
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
I am now just testing tar, without amanda and I get the following
results (just following the gnu doc):
charles@fiume:~ tar --create --file=/tmp/wine_docs_0.tar
--listed-incremental=/tmp/wine_docs.snar wine_docs/
charles@fiume:~ ll -tr /tmp
..
-rw-r--r-- 1 charles users 379944960 Feb 25 10:27
Charles,
Can you post the output of the 'stat' command of one of the file before
the level 1 backup and after the the level 1 backup, to see what changed.
Jean-Louis
On 02/25/2014 04:53 AM, Charles Stroom wrote:
I am now just testing tar, without amanda and I get the following
results (just
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.
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
Hi Charles,
These files do contain file meta data in my understanding but they are
in a data format, as you notice. I am not sure how file info can be
obtained in a human readable format from the file.
Paul
On Mon, 2014-02-24 at 01:44 +0100, Charles Stroom wrote:
Hi Paul,
you say that
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
On Tue, Feb 25, 2014 at 12:58:21AM +0100, Charles Stroom wrote:
...
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
Jon and Paul, many thanks for your suggestions. I started off looking
at the gnutar-lists directory and found many entries dated from before
my cleaning operation (that included as per FAQ reset its databases so
as to start from scratch). So I reset it again and emptied also the
gnutar-lists. I
Hi Paul,
you say that files in the gnutar-lists contain the datestamp/stat
of the files backed-up? How can I see the contents of these files,
because they are binary files? Is there a specific am* command?
Regards, Charles
On Fri, 21 Feb 2014 19:06:40 -0800
Paul Yeatman
On Mon, Feb 24, 2014 at 12:44:23AM +0100, Charles Stroom wrote:
Jon and Paul, many thanks for your suggestions. I started off looking
at the gnutar-lists directory and found many entries dated from before
my cleaning operation (that included as per FAQ reset its databases so
as to start from
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
On Sat, Feb 22, 2014 at 12:52:28AM +0100, Charles Stroom wrote:
Hi all,
on 20 Feb, I have been running my first backup after cleanup the test
results (amanda 3.3.5 compiled on opensuse 13.1). As expected, the 13
DLEs were all level 0, exceeded the capacity of my DDS4 backup tape and
I
Hi all,
on 20 Feb, I have been running my first backup after cleanup the test
results (amanda 3.3.5 compiled on opensuse 13.1). As expected, the 13
DLEs were all level 0, exceeded the capacity of my DDS4 backup tape and
I needed 2 flushes to get it all on tape. Below the dump summary of the
Hi Charles,
This can happen from time to time although I have yet to see tar be the
reason for the blame. Also, the tar being used is the one on the client
so, presuming this is unchanged, it should be working the same as it was
on that client with the previous Amanda server and version.
Amanda
23 matches
Mail list logo
