Amanda-Users

Re: Dealing with a dump too big

2004-06-21 13:22:39
Subject: Re: Dealing with a dump too big
From: KEVIN ZEMBOWER <KZEMBOWE AT jhuccp DOT org>
To: amanda-users AT amanda DOT org
Date: Mon, 21 Jun 2004 13:19:02 -0400
Stefan, hi, thanks for your suggestions.

Here's the output before any changes are made:
amanda@admin:~ > amadmin DailySet1 disklist admin //db/  
<snip of info for admin //db/c$ and admin //db/e$>

line 100:
    host admin:
        interface default
    disk //db/f$:
        program "GNUTAR"
        exclude file "./inetsrv/"
        priority 1
        dumpcycle 3
        maxdumps 1
        maxpromoteday 10000
        strategy STANDARD
        compress NONE
        auth BSD
        kencrypt NO
        holdingdisk YES
        record YES
        index NO
        skip-incr NO
        skip-full NO

line 101:
    host admin:
        interface default
    disk //db/f$/inetsrv:
        program "GNUTAR"
        priority 1
        dumpcycle 3
        maxdumps 1
        maxpromoteday 10000
        strategy STANDARD
        compress NONE
        auth BSD
        kencrypt NO
        holdingdisk YES
        record YES
        index NO
        skip-incr NO
        skip-full NO

amanda@admin:~ > 

[Why can't I enter 'amadmin DailySet1 disklist admin //db/f$'? I get "amadmin: 
no disk matched", unless I trim it back to "amadmin DailySet1 disklist admin 
//db/".]

As Paul points out, the problem is a flaw in the way estimated sizes are 
computed: it ignores the excluded files and directories.

Won't your suggestion to:
amadmin DailySet1 force admin //db/f$
amdump DailySet1 admin //db/f$

just force admin //db/f$ to do a level 0 dump, but all the rest of the backup 
targets do whatever they were scheduled to do? This normally takes  4-6 hours 
on my system, and wouldn't complete before the normally scheduled backup. I am 
doing 'amadmin DailySet1 force admin //db/f$' for tonight's backup.

Thanks, again, for your suggestions.

-Kevin

>>> monitor AT oops.co DOT at 06/21/04 12:43PM >>>
Hi, Kevin,

on Montag, 21. Juni 2004 at 17:46 you wrote to amanda-users:

KZ> The disk F: on the NT server is indeed 13G in size, but I
KZ> didn't think that would be a problem, since I excluded
KZ> //db/f$/inetsrv, which is 9.1G. This filesystem, which I just
KZ> backup for the first time last run, backed up at level 0 just fine:

KZ> The pertinent sections of my disklist and amanda.conf files are:
amanda@admin:~ >> grep admin /etc/amanda/DailySet1/disklist   
KZ> admin   //db/f$ db-f-nocomp-medpri-tar-exclude-inetsrv  #DB
KZ> server, Drive F: excluding \inetsrv
KZ> admin   //db/f$/inetsrv nocomp-medpri-tar               #DB server, Drive 
F:\inetsrv\
amanda@admin:~ >> 

KZ> From amanda.conf:
KZ> # Special dumptypes for excluding directories
KZ> define dumptype db-f-nocomp-medpri-tar-exclude-inetsrv{
KZ>    nocomp-medpri-tar
KZ>    comment "Special for admin//db/f$, excluding /inetsrv/"
KZ>    exclude "./inetsrv/"
KZ> }

KZ> My questions are:
KZ> 1. What's the long term solution to this problem? Have I done
KZ> something wrong in the amanda.conf or disklist files?

The usage of excludes is a bit different when backing up smb-shares.
Please give me the output of

amadmin DailySet1 disklist admin //db/f$

which should tell us more about how AMANDA interprets your cascading
of exclusions ...

Execute this before and after you edited the following =>

You can only use ONE exclusion-option with smbclient ...

AFAIK this should be:

exclude ".\inetsrv\*"

in this case (Win uses backslashes ...)

KZ> 2. Is there anything I can do right now, before the nightly
KZ> normal run, to get a level 0 backup of just this share?

You can do this (after editing your exclusion):

amadmin DailySet1 force admin //db/f$
amdump DailySet1 admin //db/f$

-- 
best regards,
Stefan

Stefan G. Weichinger
mailto:monitor AT oops.co DOT at 







<Prev in Thread] Current Thread [Next in Thread>