On 08/25/10 11:00, Romer Ventura wrote:
Tapes are 120GB native capacity and 320GB with compression.
2.75:1 compression? Only if you have unusually compressible data. I
assume you meant 160GB native; still, 1.3:1 to 1.5:1 is a much more
likely overall compression ratio with real-world data.
But the short answer is, if you expect your fileserver to fill two
tapes, and your mailserver to fill one, and the pool your fileserver
tapes go in have a two-tape limit, then yes, you're going to need to
back up your mailserver to a separate pool unless you're willing to
increase that volume limit. And if your fileserver backup runs over two
tapes, you have a problem.
But then, you have a problem anyway with this plan. Because if your
fileserver takes two tapes to back up, and is backed up to a pool with a
two-tape limit, then you've got to erase each full backup before you can
start a new one. Then, if there's a problem with the new backup (even
if it just runs beyond the two-tape pool limit, which will cause it to
fail), you don't have a backup. And then if there's a problem on the
server before you can make a new backup, you're dead in the water.
This is how Microsoft managed to lose thousands of Sidekick customers'
data. Microsoft's Danger unit only had room for a single full backup,
and had to delete it in order to begin a new backup; then they cancelled
the new backup in progress, because the manager was impatient and didn't
want to wait the three days for the backup to complete; then the major
system update they were backing up in preparation for went south.
Any backup plan that calls for having only a single full backup that
must be purged to begin a new one, is a bad plan.
Prudent planning would call for your full backup pool to hold AT LEAST
sufficient tapes for two complete cycles of your Full backups, allowing
a 50% safety margin on the expected tape usage for each one. So, if you
*expect* your full backup to take two tapes, based on your expectations
of compression, allow for at least six tapes in your pool.
Remember, tape is cheap, and un-backed-up data may be irreplaceable.
--
Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355
Renaissance Man, Unix ronin, Perl hacker, Free Stater
It's not the years, it's the mileage.
------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
_______________________________________________
Bacula-users mailing list
