Amanda-Users

AW: DUMP and GNUTAR fail if backup > about 50GB

2006-02-08 07:59:38
Subject: AW: DUMP and GNUTAR fail if backup > about 50GB
From: "Sebastian Koesters" <skoesters AT sino DOT de>
To: <gene.heskett AT verizon DOT net>, <amanda-users AT amanda DOT org>
Date: Wed, 8 Feb 2006 08:50:19 +0100
Thanks for your answer!

I checked if there are any timeouts but i found nothing. The network is fine
and the Server has an uptime of 287 Days.

I only want to backup a single directory with about 20 subdirs. Its not
possible to split it up. Like mainDir1 with subdirs 1 - 10 and MainDir2 with
subdirs 11 - 20 so i must backup it in one maindir with the 20 subdirs.

Is there a way to tell amanda to plit it?

Thanks!

-----Ursprüngliche Nachricht-----
Von: owner-amanda-users AT amanda DOT org [mailto:owner-amanda-users AT amanda 
DOT org] Im
Auftrag von Gene Heskett
Gesendet: Mittwoch, 8. Februar 2006 07:58
An: amanda-users AT amanda DOT org
Betreff: Re: DUMP and GNUTAR fail if backup > about 50GB

On Wednesday 08 February 2006 01:15, Sebastian Koesters wrote:
>Hi
>
>I have to backup about 80GB of Data from one Server.
>
>As Program i tried DUMP and GNUTAR but if amanda wants to make a level
> 0 Backup it always fails.
>
>These dumps were to tape DailySet166.
>The next tape Amanda expects to use is: DailySet161.
>
>FAILURE AND STRANGE DUMP SUMMARY:
>  pst        /pst RESULTS MISSING
>
>
>STATISTICS:
>                          Total       Full      Daily
>                        --------   --------   --------
>Estimate Time (hrs:min)    1:12
>Run Time (hrs:min)         1:12
>Dump Time (hrs:min)        0:00       0:00       0:00
>Output Size (meg)           0.0        0.0        0.0
>Original Size (meg)         0.0        0.0        0.0
>Avg Compressed Size (%)     --         --         --
>Filesystems Dumped            0          0          0
>Avg Dump Rate (k/s)         --         --         --
>
>Tape Time (hrs:min)        0:00       0:00       0:00
>Tape Size (meg)             0.0        0.0        0.0
>Tape Used (%)               0.0        0.0        0.0
>Filesystems Taped             0          0          0
>Avg Tp Write Rate (k/s)     --         --         --
>
>USAGE BY TAPE:
>  Label             Time      Size      %    Nb
>  DailySet166       0:00       0.0    0.0     0
>
>
>
>DUMP SUMMARY:
>                                     DUMPER STATS            TAPER
> STATS HOSTNAME     DISK        L ORIG-KB OUT-KB COMP% MMM:SS  KB/s
> MMM:SS  KB/s --------------------------
> --------------------------------- ------------ pst          /pst     
>     MISSING --------------------------------------
>
>But if Amanda wants to make a Level 1 or 2 or.... (about 30 GB)
> everything works fine. How is this possible? Is there any size
> limiting with gnutar and dump?!
>
>Regards Sebastian

So far as I know, any limits are in the associated filesystems unless 
you are using a pretty jurassic version of tar.  Supposedly 1.13-19 and 
1.13-25 are good, and while I haven't explored a single dle of that 
size range by any means, 1.15-1 is also good here. 1.13 plain is 
borked, as is any version of 1.14.

In the event of that large a single dle, its preferable to break it up 
into subdirs of manageable size because this lets amanda's scheduler 
work much more effectively at keeping the day to day sizes of the 
backups consistent by shuffling the schedule somewhat.  You'll still 
get your guaranteed level 0 sometime in dumpcycle days though.

dump is of course another horse entirely.  I don't use it so I won't 
expound on it other than to say I prefer tar, precisely for the reason 
in the previous paragraph.  Dump will not allow a filesystem to be 
broken up into directories in that manner.

One other item comes to mind, and thats timeouts, either in the settings 
for those in your amanda.conf, or in the network connection involved.

-- 
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules.  I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.