I can just about bet you that Rick has RTFM and that is why he
mentions CPU. Retrospect's documentation states:
"For optimal backup performance, assign a relatively fast
Macintosh to run Retrospect."
Here the concept of "fast" doesn't necessarily imply fast CPU. A
"fast" computer will have a "fast" system bus which will be more
capable of greater I/O loads.
One problem with the manual is that it does not make that concept
absolutely clear, as in the same paragraph as the quote I posted it
is discussing not just I/O, but CPU as well. And apparently both you
and I are possibly mistaken in both our opinions as far as this
product is concerned based upon Brendan's knowledge of the product in
question. I understand the difference I/O makes, but apparently
Retrospect sees a sizable benefit from CPU.
The truth of the matter is that CPU, for most backup applications,
doesn't come into play near as much for the average backup user as
it does for someone using software encryption and/or software
compression.
Which is normally handled in hardware these days, as can be
encryption.
Agreed, although hardware encryption is slightly less prevalent than
is hardware compression, which is why I always leave room for
software encryption.
If you have a backup device with hardware compression, obviously
software compression isn't an issue. However, if he plans on
using encryption (not indicated in his message), CPU can make a
bit of a difference. In that case, throwing CPU and memory at it
is usually a good idea.
Note I stated "major factor". The major factor in backup is I/O
load, not CPU load, regardless of encryption or compression.
Point taken, I/O normally would be considered the major factor, but
CPU does deserve at least some consideration, and apparently more
than either you or I had given it.
We mostly see CPU speed making an impact on compression when it's
useless, that is when the CPu is trying to compress already
compressed data. Normally a moderate CPU will be adequate in other
situations. In this situation it demonstrates that the Backup
Policy, where it defined the type of data to be backed up, wasn't
read too closely and compressions should have been avoided.
In software compression situations (such as direct to disk backups),
a responsible admin should learn his tool enough to know how to
exclude certain data types and locations from the compression. No
matter what kind of machine someone has or what their strategy is,
nothing good can come from a person who doesn't open the manual
enough to find out how to handle that type of situation. Your point
is a good one.
Curtis
---
[This E-mail scanned for viruses by Declude Virus]
