Les Mikesell <lesmikesell@gmail.com> wrote on 09/18/2012 03:34:56 PM:

> On Tue, Sep 18, 2012 at 1:18 PM, Timothy J Massey <tmassey@obscorp.com> wrote:
> >
> > That is a good point, but if I ever have to do a full 3TB restore from
> > BackupPC, the 12 hours a (properly performing) BackupPC will take is not my
> > biggest issue.  I don't look at BackupPC as my bare-metal disaster recovery
> > plan--or, at least, not my first line of such defense.  That's what
> > snapshots and virtualization provides.  BackupPC is for file-levelrestores,
> > and the odds of having to do a full restore from BackupPC is small.
> Off topic, but if you haven't already, have a look at ReaR for linux
> bare-metal restores.

Will do.  You were the one that turned me on to Clonezilla, and I'm always open to new tools...  :)

ReaR is not exactly the most Google-friendly search term (on so many levels...), so for others (and to confirm):  http://relax-and-recover.org/

Sadly, *so* many of my servers are Windows...

> I'm not convinced that benchmarks replicate backuppc activity very
> well.  It seems more likely to have the small writes splattered
> randomly over the disk than a test run creating new files and aside
> from the extra seeking it is likely to have your disk buffers full of
> stuff that isn't what you want next.  If you have spare RAM around
> could you try cramming a lot more in to see how much it helps?

Nope:  these boards have a maximum of 4GB.  Again:  embedded.

And we've had this debate before.  Of 4GB of RAM, 3.2GB of RAM is cache!  Do you *really* think that more will help?  I doubt that the entire EXT4 filesystem on-disk structure takes 3GB of disk space!  I've demonstrated that in previous experiments:  going from 512MB to 4GB made *zero* difference.  I doubt going beyond 4GB is going to change that, either.

> Yes, but raw disk space isn't that expensive anymore - just the real
> estate to park them...

Yup.  Hence the embedded.

> > > Are you sure the target has no
> > > other activity happening during the backup?
> >
> > I am sure they *are* seeing other activity:  they're file servers, mail
> > server, etc.  But their loads are all very low across the board.
> I always think 'seek time' whenever there is enough delay to notice -
> and anything that concurrently wants the disk head somewhere else is
> going to kill the throughput.

I think you are way overstating this.  The disks on the clients spend a good chunk of their time *idle* even when a backup is going on.  Like I said, you can look at the physical drive lights and they pulse in fits and starts.  No matter how badly you might think that seeking is hurting performance, there is a *ton* more performance to be gotten out of the clients' disks.

The guest servers are not hurting for resources.  They are not part of the problem.  The problem seems to be contained completely inside of the BackupPC server.

Tim Massey

Out of the Box Solutions, Inc.
Creative IT Solutions Made Simple!

      22108 Harper Ave.
St. Clair Shores, MI 48080
Office: (800)750-4OBS (4627)
Cell: (586)945-8796