|
Re: 77 hour backup of 850gb?
2006-07-03 04:30:13
Paul Bijnens <paul.bijnens AT xplanation DOT com> a
écrit sur 03/07/2006 10:11:48 :
> On 2006-07-03 09:34, Cyrille Bollu wrote:
> >
> > Jon LaBadie <jon AT jgcomp DOT com> a écrit sur 30/06/2006 15:47:24
:
> >
> > > > Sorry for asking but, why do you say backuping
directly to tape is
> > slow?
> > > >
> > > > I guess he's doing local backups (ie: The 700GB
are not sent over the
> > > > network every full backups).
> > > >
> > > > In this configuration what would be the benefit
of having an
> > holding disk?
> > > >
> > >
> > > See my note about his writing 80000 tiny tape files.
> > >
> >
> > This is correctly handled by Amanda when the "holdingdisk
no" variable
> > is set:
> >
> > Here's an extract from one of my amanda report:
> >
> > taper: tape daily-backup04 kb 181855648 fm 23 [OK]
> >
> > (with 23 DLE)
>
> But in this case you will be completely bypassing the holdingdisk!
>
> The backup process on the client (tar/dump + client gzip) is
> then connected with a TCP stream to the taper command. (
>
> That also means that your tape drive is now working at the speed
> that tar/dump+gzip+network can generate.
> Is this the cause of your tape drive's shoe-shining problem?
>
> Using a dumptype for with "tape_splitsize" AND a large
> "split_diskbuffer" will now at least buffer one chunk on
the disk
> and write that chunk on tape at a speed of
> min(holdingdiskspeed, tapedrivespeed).
>
Yep, I think I'll finally try that.
Though, I still worry a little about the I/O pressure that this will put
on my (single) RAID array (RAID5 6 SCSI-HD).
Cyrille
|
|
|
