OK, here is my 2 cents:

Dantz has been very helpful with clarifying the way that the Retrospect
product should work, however performance issues are so specialized to each
individual environment. The type of network your working with
(10base-100base, TCP/IP-AppleTalk), the other activities that are going on
during the scheduled backup time (heavy browser traffic, other platform
backups), are some issues.

One server can handle the load. The backup timeframe will play the biggest
factor, more than likely you will want to run backups during off-peak hours
(weekends, evenings). Getting people to leave their systems on during those
times may make complicate matters! We are currently backing up 350 Macintosh
computers of all varieties during the weekend (Fri. evening to Sun. morning,
using a 4 group rotating strategy. 1 group receives a full backup, the other
three receive an incremental backup. This works out well for a full month
cycle. Keep the data as long as you see necessary, storage space is cheap
compared to the cost of recreating data or maybe not being able to!

At one point I did hear talk of Retrospect becoming a multi-thread product,
which would be great!!! Running multiple simultaneous servers can work also
depending on how your network is configured, however if not configured
appropriately, this could compromise the performance of all the backup
servers. These are just my personal opinions, contact Dantz for the thoughts
of experts.

Derrick Lloyd
Windows Consulting Group Project Leader
Computing Services Department

-----Original Message-----
From: Reid Mullen [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 28, 2000 9:10 AM
To: retro-talk
Subject: Backup Strategies

I'm somewhat new to Retrospect and just have some questions about backup
strategies people are currently using.  We are currently testing the
trial version of Retrospect Backup Server 5.0 with Windows NT.  We have
probably about 600 Macintosh users, although initially we will probably
only backup about 100 of them.

First, could this be done on one computer or would the load be too
high?  The client Macs are anything from old Performas to new G4s.
Second, what are some good backup strategies?  I have looked through the
manual, but none of those strategies seem ideal.  I'm thinking we would
want to keep backup data around for about 2 months before it expires (is
removed).  I'm also thinking that I could just create 2 backup sets
which recycling done on alternating months.  This data could then be
backed up to tape on a nightly basis.  I'm not sure if this is a good
solution or not.

Some other questions I have are the following:

If I use a 2 backup set strategy, how will Retrospect know which set to
check for the latest list of files.  In addition, when I recycle one
backup set, will Retrospect know that it should get older data from the
older (non recycled) backup set?  Rather than an alternating backup
schedule like Retrospect uses (every 3 days, months...), it might be
better to tell the script to use one backup set for 2 months, recycle
it, then switch to using the other backup set.  This would save some HD
space over having two backup sets which basically contain the same
information (alternating days, weeks)

Also, Retrospect only seems to handle one backup at a time.  Is there a
way to change this, so that it could run, for example, 10 backups at the
same time?  Other products, such as Replica, have this functionality,
but they don't support Mac clients at this time.  Given that some of our
Macs are kind of old, it would be helpful to be able to run multiple
backup threads on the server, since it could probably keep up with
multiple client data streams.

I hope this makes sense and thanks,

To subscribe:    [EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:        <http://list.working-dogs.com/lists/retro-talk/>
Problems?:       [EMAIL PROTECTED]

To subscribe:    [EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:        <http://list.working-dogs.com/lists/retro-talk/>
Problems?:       [EMAIL PROTECTED]

Reply via email to