I had the same dilemma, and came up with some reasonable solutions 
(if you have adequate drive space elsewhere on your network). Beauty 
of this, is you have two duplicates. I'm assuming that the servers 
you are referring to aren't your Retrospect server machine--that you 
are using Retro on one machine to do the backups on separate server 

Goes like this:

Solution 1)
Set up two duplicate scripts. The first one will mirror your main 
server drive to a second machine (a subvolume on that second 
machine's hard drive works fine). Set this script to go off first.

Then create a second script to duplicate the subvolume on the second 
machine to duplicate back to the second drive on the server. Make 
sure the time for the second script is set to go off after the first 

Solution 2)
If you have two servers with two drives in each, you also could 
duplicate one server's main drive to the second drive on the second 
server, and vice versa for the second machine.

Solution 3)
Alternatively, you can put the second drives on another machine, and 
just run a duplicate script from your server to it's new location. 
Then when/if you need the drive, if your main server drive fails or 
crashes (or you have some other hardware failure), you can just 
re-hook it up to your main server and away you go, or use the second 
machine as a backup server while you rebuild your main server's 
drive, or replace it if it's failed. This also has the advantage of 
only hitting your main server once for a duplicate.

Be forwarned that file sharing privileges will not be maintained 
during duplicates, as the permissions are always relative to the root 
of a certain drive (in this case your main drive)--I don't believe 
that even naming the drives the same thing will maintain those 
privileges. I have replaced drives on computers, and named them the 
same thing as they originally were, and then restored the drive via 
Retrospect, and when I run a regular backup script to tape, I always 
have to go back and forget the old drive, and add the new one to the 
script. I believe that Retrospect looks deeper into the drives 
identity than just it's name and the computer it is on to recognize 
it on a network (is this right Dantz?).

So if you are using Apple's Users & Groups with file sharing for, say 
NetPresenz ftp to use with a web server, then you're out of luck, and 
will have to reset those permissions manually. Found out this the 
hard way. Now, if someone else has found a good way to maintain those 
file sharing privileges during duplicates, I'd love to know! :-).

And yes I know that running AppleTalk and file sharing on a server is 
not a good thing (if you have OS 9 you can use TCP/IP file sharing 
and turn AppleTalk off), but until I either upgrade to another ftp 
server that doesn't use file sharing, or upgrade WebStar to v4.x 
which has a decent ftp server built in, I'm stuck with NetPresenz to 
allow access to my servers. And I like NetPresenz--wish that 
Stairways Software would have continued developing it!

Jim Coefield

>Subject: Duplicating volumes
>From: "Garret J. Cleversley" <[EMAIL PROTECTED]>
>Date: Wed, 07 Jun 2000 10:36:30 -0400
>I tried to use the duplicate volume command but it won't duplicate a volume
>on the same machine??  I have two drives in my servers and planned on just
>using the duplicate command but retrospect won't allow it. Is there another
>way or am I looking to another program?

To subscribe:    [EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:        <>
Problems?:       [EMAIL PROTECTED]

Reply via email to