This is what we do in our GIS lab. We automatically duplicate 
(nightly when no ones working and files are closed) many drives that 
contain our critical ArcView and ArcInfo data scattered across our 
network (combination Windows 95, 98, NT4) to a single map server 
(NT4) via Retro on a Mac (100base-T ethernet) that has several 27 GB 
hard drives. You just need to make sure that the subvolumes you 
create on the destination drives, representing the drives scattered 
across the network, contain enough free space.

The map server w/backup drives then gets backed up periodically to 
tape. This situation seems to keep our map techs happy, as they worry 
about data integrity once the GIS info has been written to tape, 
given Arc's unique handling of data structures, pointers, and 
workspaces. Restores for Arc GIS data have to be done very carefully, 
and being able to move data from a duplicated drive back to its 
original location is much preferred to restoring from tape. Took one 
Arc workstation meltdown, wrestling with the Arc data structure to 
devise this (hopefully) foolproof system.

One gotcha on many PC machines: the BIOS can't handle drives larger 
than, I believe 32GB without being upgraded. Not all PCs will allow 
you to upgrade their BIOS, or it isn't worth the time and effort to 
do so. Found out the hard way, which is why my B&W G3 has a nice 34GB 
Maxtor (which had a disclaimer "inside" the box about this possible 
limitation), and the PC has 27GB drives. Not often you can one-up the 
PC/NT support person, when you're the Mac guy in the lab. But in this 
situation with Retrospect, you sure can.

Jim Coefield


>Subject: Re: using large hard disk as backup desitination
>From: "Erik Ableson" <[EMAIL PROTECTED]>
>Date: Mon, 20 Dec 1999 17:42:55 -0500
>Hmmm - here's an alternate possibility:
>1.  Set up a folder for each client volume to be backed up
>2.  Set each folder as a volume using the subvolume option in Retrospect
>3.  Create a duplicate script for each of these.  Using the duplicate
>    function with replace entire HD, you will get a mirror of each volume on
>    the server - retrospect is smart enough to do an incremental duplicate
>    so these should run pretty quickly
>4.  Then backup the server locally to a handy tape device.
>This will require more active management and tracking as you won't be able
>to use Retrospect's advanced search features by client name since it will
>all be one data source, but if you organize your server structure carefully,
>you should be OK.  You also won't be able to use the smarts of the backup
>server scripts and will be stuck with scheduled ones (not critical for a
>smaller backup group tho').
>Erik Ableson
>NB - this only works if you have a clear controlled client group that you
>know exactly the available capacity and can ensure that you have sufficient
>space on the server.
>Ancillary issues are that if you have a mix of Windows and Mac clients there
>are some naming issues that may arise since the Mac can't handle names over
>32 characters, and if you decide to try this from a Windows box, you'll need
>to ensure that you have things set up to properly handle MacOS resource
>forks. Sigh - nothing's ever as simple as it first looks.

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

Reply via email to