Welcome! » Log In » Create A New Profile

Fw: again level 1 backup problems.

Posted by Charles Stroom 
Charles Stroom
Fw: again level 1 backup problems.
February 07, 2018 02:59PM
Hi,

I saw that my original reply was only to Jean-Louis and not to the list,
so I forward it now to the list as well.

With an additional question: would it solve the problem by using
another common Linux/Windows disk format like NTFS?

Charles



Begin forwarded message:

Date: Wed, 7 Feb 2018 18:43:30 +0100
From: Charles Stroom <charles@stremen.xs4all.nl>
To: Jean-Louis Martineau <JMartineau@carbonite.com>
Subject: Re: again level 1 backup problems.


Hi Jean-Louis,

before your email arrived, I was testing something different.
I copied the whole ~/pictures tree back to the Linux formatted disk,
and tested all 5 disks in disklist (separately, limited space on dump
area). They all behaved correctly. So it must be in the vfat and my
testing continued with the vfat disk.

I was indeed using the amgtar application. I changed that in
amanda.conf to program "GNUTAR" and added the line gnutar-list-dir ""
to amanda-client.conf and, as said, went back to the vfat ~/pictures
tree. Unfortunately, it still does not work, level 1 is a (near) full
backup.

For testing, I deleted the gnutar-list-dir "" line in
amanda-client.conf, so it generated the usual files
in /var/lib/amanda/gnutar-lists directory, but this did not help either.

Here are the data for an arbitrary file in ~/pictures:
charles@fiume5: >stat Waope_1.jpg
File: ‘Waope_1.jpg’
Size: 434286 Blocks: 896 IO Block: 32768 regular file
Device: 821h/2081d Inode: 366843 Links: 1
Access: (0755/-rwxr-xr-x) Uid: ( 1000/ charles) Gid: ( 100/ users)
Access: 2018-02-07 01:00:00.000000000 +0100
Modify: 2016-10-27 22:30:30.000000000 +0200
Change: 2018-01-10 22:55:00.000000000 +0100
Birth: -

Access time at all files is always "01:00:00.000000000" which is wrong,
but the Acces date seems OK. Modify and Change date/time stamps seem OK.

The relevant options(?) given to tar are:
for level 0: --incremental --newer 1970-01-01 0:00:00 GMT
for level 1: --incremental --newer 2018-02-07 17:14:52 GMT (latest run)

My tar is gnu 1.27, but I also tested with a recently downloaded 1.30.
No difference.

But why is 1 of the disks in disklist working? And the others are not?

Thanks for your help.

Cheers, Charles



On Wed, 7 Feb 2018 13:25:31 +0000
Jean-Louis Martineau <JMartineau@carbonite.com> wrote:

> You didn't say how you do the backup, you are using the GNUTAR
> program or the amgtar application? or ... ?
>
> Read
> https://marc.info/?l=amanda-users&w=2&r=1&s=GNU+tar+estimates+for+vfat+filesystems&q=b
>
> Try to set gnutar-list-dir to the empty string
> in /etc/amanda/$CONF/amanda-client.conf eg. gnutar-list-dir ""
> and use the program"GNUTAR" to backup the vfat filesystem.
>
> That will not be good for other unix filesystem, so for them, use the
> application amgtar and set the GNUTAR-LISTDIR property where you want
> it to store the files.
>
> Let me know if it works for your vfat, and I will add that feature
> to amgtar.
>
> Jean-Louis
>
> ________________________________________
> From: owner-amanda-users@amanda.org <owner-amanda-users@amanda.org>
> on behalf of Charles Stroom <charles@stremen.xs4all.nl> Sent:
> February 6, 2018 5:58:23 PM To: amanda-users@amanda.org
> Subject: again level 1 backup problems.
>
> 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.nlhttp://no-spam.stremen.xs4all.nl (remove
> the "no-spam.") This message is the property of CARBONITE, INC. and
> may contain confidential or privileged information. If this message
> has been delivered to you by mistake, then do not copy or deliver
> this message to anyone. Instead, destroy it and notify me by reply
> e-mail


--
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.")
This message was imported via the External PhorumMail Module
Sorry, only registered users may post in this forum.

Click here to login