RE: Backup takes way to long

[Craig Isaacs]

> > >The problem is that Retrospect spends over 90% of the time "Matching"
> > >files from the clients to the catalog and very little time backing up
> > >(writing to the tape). My network throughput is not fantastic, yet not
> > >bad. I noticed that during the "Matching" period my CPU usage is 100%.

In addition to modifying your strategy (since one backup set per month
probably won't provide the level of safety you want), you might want to look
at changing computers from a PII to a PIII. The matching process is very CPU
intensive and scales based on CPU performance.

The interesting thing about backup systems is that there are so many places
for potential performance issues: network, backup drive, OS, I/O, etc. It's
rare (and wonderful!) when you can change one component and have a huge
impact on backup performance.

Craig

-
Craig Isaacs
Dantz Development Corporation
www.betterbackup.com



--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:
Problems?:   [EMAIL PROTECTED]

Re: Backup takes way to long

[Ben Mihailescu]

Hi Pam,

Thanks, that's the conclusion I kind'a came to as well. I just took over the
job about a few months ago and the going rule was to do a full backup on the
first weekend of the month with incremental backups to the end of the month,
then start the cycle again. I guess we should start shortening the time
between new backup sets since the it seems to be the only way we could pick
up all the boxes in one night.

Thanks again, Ben

Pam Lefkowitz wrote:

> > My current backup set has 7 members (tapes) and
> >the catalog file (compressed) is about 142MB.
> >The problem is that Retrospect spends over 90% of the time "Matching"
> >files from the clients to the catalog and very little time backing up
> >(writing to the tape). My network throughput is not fantastic, yet not
> >bad. I noticed that during the "Matching" period my CPU usage is 100%.
> >
>
> Hi Ben,
>
> It sounds to me like you could use a bit of a redesign of your backup
> strategy. What kind of scripting have you in place? In other words, I'm
> guessing you do a full backup on, say Friday night. After that you do
> incremental backups. So, how many days/weeks do you go before you start
> the next backup set? And how often are you doing a recycle/new backup?
> Your 142MB catalog and 7 member DLT set seem pretty hefty for backing up
> only 60 machines.
>
> >I would like to shorten as much as I can this "matching" time and use my
> >14 hours allotted to backing up for doing the actual work. Does anybody
> >know what can I do software/hardwarewise to achieve this?
> >
>
> If you run your backups a week at a time you ought to be able to reduce
> your backup time as Retrospect won't have to go through so much data in
> the catalog.
>
> Basically, a full/recycle backup followed by incrementals to round out
> the week and then offsite the set when you start a new full/recycle
> backup the next weekend should help reduce your backup time.
>
> Pam
>
> --
> --
> To subscribe:[EMAIL PROTECTED]
> To unsubscribe:  [EMAIL PROTECTED]
> Archives:
> Problems?:   [EMAIL PROTECTED]



--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:
Problems?:   [EMAIL PROTECTED]

Re: Backup takes way to long

[Pam Lefkowitz]

> My current backup set has 7 members (tapes) and
>the catalog file (compressed) is about 142MB.
>The problem is that Retrospect spends over 90% of the time "Matching"
>files from the clients to the catalog and very little time backing up
>(writing to the tape). My network throughput is not fantastic, yet not
>bad. I noticed that during the "Matching" period my CPU usage is 100%.
>

Hi Ben,

It sounds to me like you could use a bit of a redesign of your backup 
strategy. What kind of scripting have you in place? In other words, I'm 
guessing you do a full backup on, say Friday night. After that you do 
incremental backups. So, how many days/weeks do you go before you start 
the next backup set? And how often are you doing a recycle/new backup? 
Your 142MB catalog and 7 member DLT set seem pretty hefty for backing up 
only 60 machines. 

>I would like to shorten as much as I can this "matching" time and use my
>14 hours allotted to backing up for doing the actual work. Does anybody
>know what can I do software/hardwarewise to achieve this?
>

If you run your backups a week at a time you ought to be able to reduce 
your backup time as Retrospect won't have to go through so much data in 
the catalog. 

Basically, a full/recycle backup followed by incrementals to round out 
the week and then offsite the set when you start a new full/recycle 
backup the next weekend should help reduce your backup time.

Pam


--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:
Problems?:   [EMAIL PROTECTED]