_____________________________________________________________________
Robert P. McGraw, Jr.
Manager, Computer System EMAIL: rmcgraw AT purdue DOT edu
Purdue University ROOM: MATH-807
Department of Mathematics PHONE: (765) 494-6055
150 N. University Street FAX: (419) 821-0540
West Lafayette, IN 47907-2067
> -----Original Message-----
> From: owner-amanda-users AT amanda DOT org [mailto:owner-amanda-users AT
> amanda DOT org]
> On Behalf Of Jon LaBadie
> Sent: Wednesday, April 26, 2006 11:25 AM
> To: amanda-users AT amanda DOT org
> Subject: Re: tape split question
>
>
> On Wed, Apr 26, 2006 at 10:30:42AM -0400, McGraw, Robert P. wrote:
> > I am running Amanda 2.5.0 on a Solaris 10 host. This is the first time I
> > have tried the tape_splitsize to backup a large filesystem.
> >
> > My dump type looks a follows:
> > define dumptype users-tar-span {
> > global
> > comment "backup of users using tar with spanning"
> > program "GNUTAR"
> > tape_splitsize 30 Gb
> > maxdumps 10
> > exclude list "/pkgs/amanda/etc/amanda/exclude/user_exclude"
> > }
> >
> > In /var/amanda/archive/amdump I have
> >
> > taper: r: end zorn./export/fssnap/users.20060425201728.0 part 6064,
> > splitting chunk that started at 62085120kb after 10208kb (next chunk
> will
> > start at 62095328kb)
> > taper: reader-side: got label archive:000068 filenum 6066
> > taper: r: end zorn./export/fssnap/users.20060425201728.0 part 6065,
> > splitting chunk that started at 62095360kb after 10208kb (next chunk
> will
> > start at 62105568kb)
> > taper: reader-side: got label archive:000068 filenum 6067
> >
> > I killed the backup and the email output from the run showed the
> following:
> >
> > taper: tape archive:000067 kb 172276416 fm 18 writing file: short
> write
> > taper: retrying zada:/export/data.0 on new tape due to: [writing file:
> > short write]
> > taper: mmap not available: using fallback split size of 10240kb to
> buffer
> > zorn:/export/fssnap/users.0 in-memory
> > taper: tape archive:000068 kb 173468288 fm 7872 [OK]
> > taper: Received signal 15
> >
> > The filesystem that I am trying to backup with the tape split is 300GB.
> > After 12 hours the 300GB file system had only written about 60GB. I
> assume
> > the problem is the "mmap not available" and the split size of 10GB
> >
>
> Was that a configure error not able to detect your mmap function?
> Or if you really don't have mmap, what system/OS is this?
> fssnap sounds like Solaris which certainly has mmap.
[McGraw, Robert P.]
For now I have increased my holding disk size to be greater than the largest
file system.
I am not sure if mmap is in Solaris 10 but I would think so. I can do a man
mmap and I get the man page.
I just ran configure.sh and let if find what is needed.
The doc says
--with-mmap force use of mmap instead of shared memory suppory
I guess I could run configure with --with-mmap and see what happens.
>
>
> > QUESTIONS:
> >
> > 1) The above log seems to show that the tape_splitsize is 10G and not
> the
> > 30G that I indicated in the tape_splitsize. Is this correct? Other than
> the
> > tape_splitsize what other parameter do I need.
>
> If I read that correctly, the "fallback" splitsize was 10MB, M, not G.
[McGraw, Robert P.]
I saw that after I sent the email.
>
> >
> > 2) My backup was running slow and and noticed that
> zorn./export/fssnap/users
> > was not in the HOLDING DISK so it must be reading the backup directly
> from
> > the disk. My holding disk is 200GB and the filesize that I am backing up
> is
> > 300GB. Do I need to have my HOLDING DISK size as large as the file
> system
> > that I am backing up when using the tape_splitsize?
>
> If the dumpsize is larger than available holding disk,
> the dump goes directly to tape.
>
> Sounds like a number of things might be contributing to bad performance.
[McGraw, Robert P.]
Thanks for your reply.
Reply
>
> --
> Jon H. LaBadie jon AT jgcomp DOT com
> JG Computing
> 4455 Province Line Road (609) 252-0159
> Princeton, NJ 08540-4322 (609) 683-7220 (fax)
smime.p7s
Description: S/MIME cryptographic signature
|
