Les Mikesell <email@example.com> wrote on 09/18/2012
> On Tue, Sep 18, 2012 at 1:18 PM, Timothy J Massey <firstname.lastname@example.org>
> > That is a good point, but if I ever have to do a full 3TB restore
> > 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
> > plan--or, at least, not my first line of such defense. That's
> > snapshots and virtualization provides. BackupPC is for
> > and the odds of having to do a full restore from BackupPC is
> 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... :)
> I'm not convinced that benchmarks replicate backuppc
> 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
> 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:
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
> > server, etc. But their loads are all very low across the
> I always think 'seek time' whenever there is enough delay to notice
> and anything that concurrently wants the disk head somewhere else
> 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.