RE: Holding disk (feature request)

[Douglas B. McKay]

Perhaps the process could queue the files in 650MB (or whatever) size
chunks which could then be copied to tape as soon as the first one on
the disk is complete.  If the tape drive ran faster than the system
could fetch the data from the clients, you could simply increase the
number of backup processes writing to the holding area.

My tape drives can write data faster than I can get it from the
network if the files are small (in fact, I often see reduced tape
capacities because of all of the small files).  If they're large
files, tape speed is probably the bottleneck.  I have seen nearly
200MB/min on a switched 100MB connection with my drives (OnStream
ADR50).

I still think it would be great to be able to get the client machines
to do the catalog compares and snapshot creations in parallel and just
have the server fetch the data and write it to tape.

As for disk space concerns, I purchased a 40GB 7200 RPM Ultra 100
drive yesterday for $177.  I wouldn't use IDE drives for network
storage, but as a buffer, I think it would work fine.

   ...Doug

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf
Of matt barkdull
Sent: Thursday, January 04, 2001 5:36 PM
To: retro-talk
Subject: Re: Holding disk (feature request)


>Just a thought, when does it get time to copy to tape, this seems
>good in theory but I guess it could only be efficient if you can run
>multiple backup sessions in parallel. I'm not sure about the problem
>with speed, I think tape drives can keep up with network speeds
>though I can't tell you that for certain.
>
>I do like the idea of the hard drive taking over as a fail over,
>"the backup must go on".


This might work well for clients with small amounts of data, but just
imagine trying to keep more disk space than your clients on the
server.

Didn't we just go through a discussion on file sizes?  So if you do a
backup to file, there is a limitation of 2GB(?) of that file.  If
they break that barrier, then the rest of the stuff is fairly easy I
would think.



--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:
Search:  

For urgent issues, please contact Dantz technical support directly at
[EMAIL PROTECTED] or 925.253.3050.

Re: Holding disk (feature request)

[Rudy Richter]

AFAIK the 2GB file size limit for backup to file was fixed in the mac 4.3
version.
-- 
Rudy A Richter 
Goddard Space Flight Center
Earth Science Technology Office (ESTO)
Code 710 Server Admin

301-286-4429

> 
> Didn't we just go through a discussion on file sizes?  So if you do a
> backup to file, there is a limitation of 2GB(?) of that file.  If
> they break that barrier, then the rest of the stuff is fairly easy I
> would think.



--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:
Search:  

For urgent issues, please contact Dantz technical support directly at
[EMAIL PROTECTED] or 925.253.3050.

Re: Holding disk (feature request)

[matt barkdull]

>Just a thought, when does it get time to copy to tape, this seems 
>good in theory but I guess it could only be efficient if you can run 
>multiple backup sessions in parallel. I'm not sure about the problem 
>with speed, I think tape drives can keep up with network speeds 
>though I can't tell you that for certain.
>
>I do like the idea of the hard drive taking over as a fail over, 
>"the backup must go on".


This might work well for clients with small amounts of data, but just 
imagine trying to keep more disk space than your clients on the 
server.

Didn't we just go through a discussion on file sizes?  So if you do a 
backup to file, there is a limitation of 2GB(?) of that file.  If 
they break that barrier, then the rest of the stuff is fairly easy I 
would think.



--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:
Search:  

For urgent issues, please contact Dantz technical support directly at
[EMAIL PROTECTED] or 925.253.3050.

Re: Holding disk (feature request)

[Michael Kennard]

Just a thought, when does it get time to copy to tape, this seems 
good in theory but I guess it could only be efficient if you can run 
multiple backup sessions in parallel. I'm not sure about the problem 
with speed, I think tape drives can keep up with network speeds 
though I can't tell you that for certain.

I do like the idea of the hard drive taking over as a fail over, "the 
backup must go on".

Thanks for this idea. I did try something like this for Internet 
backups and put to tape till the files got corrupted and I had to 
scrap the whole idea.

Lets see what dantz thinks.

Michael

>Since it seems we're on the subject of feature requests, speeds of backups
>over network to tape and so on, here's what I'd like to see added to
>Retrospect. I'll be talking about tapes because that's what I use, but I'm
>sure this would apply to any sort of backup set.
>
>Add an option that does backups to a holding drive instead of directly to
>tape. When the holding drive is full or the backup of the client is complete
>(whichever comes first), transfer the holding drive backup set to a tape
>backup set. After all is done and on tape, clear the holding drive.
>
>This would be kind of like doing a set transfer from a file backup set to a
>tape backup set, but in an automated way. This would accomplish a few things
>from my perspective.
>
>1) Parallel backups of multiple clients. I don't see how one could do
>parallel backups to tape efficiently, but to a holding disk is a different
>story. Once it's done the holding disk gets transferred to tape and cleared
>off for the next round of backups.
>
>2) Increase speed of backups. Local hard drive to local tape drive is much
>faster than remote client direct to tape. The tape drive can then run at its
>maximum speed if everything is done locally. Also allows for more efficient
>use of tape.
>
>3) If Retrospect needs more tapes, backups can still proceed to the holding
>drive rather than be halted completely until more tapes are available.
>
>So, what does everyone think? Good idea or not?
>
>--
>Seth D. Mattinen  [EMAIL PROTECTED]  http://roller.reno.nv.us/
>PGP Key: http://seth.mattinen.org/pgp.php
>Tomorrow holds such better days. Days when I can still feel alive.


--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:
Search:  

For urgent issues, please contact Dantz technical support directly at
[EMAIL PROTECTED] or 925.253.3050.

Re: Ricoh MP 7083 CDRW and HP 9500

[Joe Pokupec]

Thanks for the reply Eric. I absolutely agree and understand why I should
select one of the tried and true CD-R's. I've just become such a fan of the
Pyro 1394 external kit, I was hoping to find as many ways of implementing
it!

I did have an opportunity to try a friend's BOA FireWire CR-RW using
Retrospect (it is on your supported list) and found that it wrote at 1X
speed!! The drive itself supports 8X and worked fine using Toast, burning
650 meg at under 8 minutes... Unfortunately, Retrospect took almost an hour
to back up one single 650 mg CD... Is this simply how Retrospect handle
FireWire? Are there any any supported units that will actually burn at the
highest rate (8X or 12X)?

Thanks

Joe

> It's unlikely that we will qualify and write drivers for each possible CD-RW
> drive and external FireWire/USB bridged enclosure. There are just too many
> variables, and if we find problems with a drive's or bridge's firmware, it's
> unlikely that we be able to convince the device's manufacturer to fix the
> problem--with a likely response that their device works perfectly well
> without the other.
> 
> We encourage Retrospect users to purchase already-supported devices. Such
> devices are rigorously tested and will provide reliable restores.
> 
> http://www.dantz.com/index.php3?SCREEN=cdr_info
> 
> Best regards,
> 
> Eric Ullman
> Dantz Development



--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:
Search:  

For urgent issues, please contact Dantz technical support directly at
[EMAIL PROTECTED] or 925.253.3050.

Holding disk (feature request)

[Seth D. Mattinen]

Since it seems we're on the subject of feature requests, speeds of backups
over network to tape and so on, here's what I'd like to see added to
Retrospect. I'll be talking about tapes because that's what I use, but I'm
sure this would apply to any sort of backup set.

Add an option that does backups to a holding drive instead of directly to
tape. When the holding drive is full or the backup of the client is complete
(whichever comes first), transfer the holding drive backup set to a tape
backup set. After all is done and on tape, clear the holding drive.

This would be kind of like doing a set transfer from a file backup set to a
tape backup set, but in an automated way. This would accomplish a few things
from my perspective.

1) Parallel backups of multiple clients. I don't see how one could do
parallel backups to tape efficiently, but to a holding disk is a different
story. Once it's done the holding disk gets transferred to tape and cleared
off for the next round of backups.

2) Increase speed of backups. Local hard drive to local tape drive is much
faster than remote client direct to tape. The tape drive can then run at its
maximum speed if everything is done locally. Also allows for more efficient
use of tape.

3) If Retrospect needs more tapes, backups can still proceed to the holding
drive rather than be halted completely until more tapes are available.

So, what does everyone think? Good idea or not?

-- 
Seth D. Mattinen  [EMAIL PROTECTED]  http://roller.reno.nv.us/
PGP Key: http://seth.mattinen.org/pgp.php
Tomorrow holds such better days. Days when I can still feel alive.



--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:
Search:  

For urgent issues, please contact Dantz technical support directly at
[EMAIL PROTECTED] or 925.253.3050.

RE: Catalog 0ut of sync on NT server

[Thone, Bradley A (Sbcsi)]

Here's a message I posted on 11/9/00...
 
Upon re-reading what I wrote, I'd like to amend #2 by stating that the
server in question was a DL580, not a DL380. 
 
Anyway, try a different SCSI adapter, rather than using Compaq's built-in
SCSI adapter.
--- begin old message -

Just FYI.

Just a couple notes for the list (and Dantz).

1. Attaching a Compaq DLT tape library to a Compaq ProLiant 6500 server's

built-in SCSI adapter doesn't work with BackupExec. I haven't tried it with

Retrospect, but would expect similar results. BackupExec couldn't talk

reliably talk to the library.

2. Attaching a Compaq AIT tape library (SSL-2020) to the built-in SCSI

adapter of a Compaq DL380 server doesn't work, either. Retrospect cannot

talk reliably to the library. It almost works. Backups may occur, but the

Devices window simply behaves oddly, and Retrospect has trouble erasing

tapes, or find tapes to erase or use.

Solutions in both cases was to install an Adaptec 2940UW SCSI adapter and

connect the library to the Adaptec.

Dantz may wish to stick this information in some tech DB or something.

I'd probably recommend that admins with Compaq servers be wary of the

built-in SCSI adapters of Compaq servers, or at least test them thoroughly

before relying on them...

-Original Message-
From: Rob Davies [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 04, 2001 4:07 PM
To: 'Retro-talk'
Subject: Catalog 0ut of sync on NT server




I have a Compaq DL380 server with a separate disk array attached via two
(long) SCSI3 cables. 1GB RAM & plenty of HD space.

Server has 35/70 DLT drive internal 

Symptoms: 
scripted backup of two volumes (C & D drives). 
scans C drive, backs it up ( 200MB/min typical), verifies backup, commences
backup of D, stops before writing anything to tape and complains 'catalog
out of sync with backup set'.

Reports watcher says its an error -106 'data overwrite attempt', but the
Dantz site doesn't list  error -106. 
all attempts at recatalog fail - no errors reported - it just sits at 0K
found - as if it cannot see anything on the tape.

DLT drive has been replaced, without any change in the symptoms. 

further symptoms: 
1. when tape is ejected and re-inserted (Retrospect still running) it does
not see the tape in 'configure/devices', even after refreshing the scan (the
drive is visible, though). Quiting Retrospect and relaunching it results in
tape becoming visible. 

2. rescripted the backup to do the 'my computer' container, without compare,
and ran it. it resolved the container into two volumes, and backed up ~100MB
before Blue Screen. Event log complained of 'dirty heads' (though the 'clean
heads'  light on the drive was not lit). Cleaned the heads & tried again.
Successful backup.

Then tried a normal backup with compare. It did the C drive (& verified),
but complained 'catalog out of sync' when it tried to write D drive data to
tape. Recatalog fails - as it sits 'building catalog' 'Completed 0 files
zero KB' until I stop it

ASPI is installed. 
I suspect hardware issues but NT backup works(!) 
Any ideas on what to try next would be very much appreciated. 

Thanks, 

Rob Davies 
TSG-SSO  COMPAQ 
(Technical Services Group - Server Support Operations) 
desk phone # 61+ (2) 9342 7997; fax # 61+ (2) 9342 7566 
available between 7:30am & 4pm weekdays 

Server belongs to Cable & Wireless Optus 









--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:
Search:  

For urgent issues, please contact Dantz technical support directly at
[EMAIL PROTECTED] or 925.253.3050.

Catalog 0ut of sync on NT server

[Rob Davies]

Title: Catalog 0ut of sync on NT server






I have a Compaq DL380 server with a separate disk array attached via two (long) SCSI3 cables. 1GB RAM & plenty of HD space.

Server has 35/70 DLT drive internal


Symptoms:
scripted backup of two volumes (C & D drives). 
scans C drive, backs it up ( 200MB/min typical), verifies backup, commences backup of D, stops before writing anything to tape and complains 'catalog out of sync with backup set'.

Reports watcher says its an error -106 'data overwrite attempt', but the Dantz site doesn't list  error -106. 
all attempts at recatalog fail - no errors reported - it just sits at 0K found - as if it cannot see anything on the tape.

DLT drive has been replaced, without any change in the symptoms.


further symptoms: 
1. when tape is ejected and re-inserted (Retrospect still running) it does not see the tape in 'configure/devices', even after refreshing the scan (the drive is visible, though). Quiting Retrospect and relaunching it results in tape becoming visible. 

2. rescripted the backup to do the 'my computer' container, without compare, and ran it. it resolved the container into two volumes, and backed up ~100MB before Blue Screen. Event log complained of 'dirty heads' (though the 'clean heads'  light on the drive was not lit). Cleaned the heads & tried again. Successful backup.

Then tried a normal backup with compare. It did the C drive (& verified), but complained 'catalog out of sync' when it tried to write D drive data to tape. Recatalog fails - as it sits 'building catalog' 'Completed 0 files  zero KB' until I stop it

ASPI is installed.
I suspect hardware issues but NT backup works(!)
Any ideas on what to try next would be very much appreciated. 


Thanks,


Rob Davies
TSG-SSO  COMPAQ
(Technical Services Group - Server Support Operations)
desk phone # 61+ (2) 9342 7997; fax # 61+ (2) 9342 7566
available between 7:30am & 4pm weekdays


Server belongs to Cable & Wireless Optus

RE: Anyone used Retrospect on medium-large systems?

[Thone, Bradley A (Sbcsi)]

Well, that's not *entirely* true. Retrospect scales with some difficulty,
though I'm learning to work around some of its shortcomings, and ranting
about some others.

I have about 1000 clients, currently being backed up by 3 Macs.

I am converting the 3 Mac servers into 4 NT servers, not because I need 4
NTs to do the work of 3 Macs, but because the 3 Macs weren't enough to begin
with. It may be the case that 4 NT servers won't be enough, since the
snapshot phase is so time-consuming. We'll see.

My clients are (were, actually) installed by a bunch of desktop technicians
that sometimes can't type a password correctly to save their lives, so
adding clients to the server can be challenging sometimes...

Also, some of the clients are upgrades of the 1.1 client, upgraded to 5.0 or
5.1. Others are fresh installs of 5.0 or 5.1x or 5.15.

Dantz provides no method (or at least no documented and supported method) of
either uninstalling existing clients or installing new clients in a
non-interactive fashion.

Dantz' area of the registry is an admin's nightmare. Dantz has piled all of
the client's configuration settings into one registry value called "Config",
which is in Hex to boot. I've not worked around this, nor will I be able to
without some really difficult work.

When installing Retrospect client on a workstation, the installer grabs the
current computername, and works that into the "Config" value in Dantz' area
of the registry. This means that when a workstation is renamed, the
Retrospect client does not get renamed similarly, so the computername and
client name are out-of-sync. This is a serious problem when a restore for a
computer is requested by COMPUTERNAME, but the backup is being performed
under a different CLIENT NAME!

So, for starters, here is a short, incomplete list of things I'd like Dantz
to fix (yes, I mean fix):

1. Document and support silent installs of the Retrospect client. For those
of you who are interested, I documented my approach to silent
non-interactive installs on 11/15/00, posting to this forum. I've learned
some more since then, so if you have questions, feel free to email me, or
post if the interest warrants.

2. Break out the "Config" value in the registry so that admins can configure
(via registry imports of .REG files) the Retrospect clients. I'd like to
ensure that backups get highest priority. I'd like to ensure users get
notified after backups or after seven days of no backups, etc. Via some
quick testing, I've determined that byte 29 describes the state of the "x
days of no backup" notification. The value of "x" is located at byte 33.
Furthermore, buried in that same value "Config" is the client name, the
access password (encrypted), etc. Not very useful to admins.

3. "Genericize" the clients Please stop "personalizing" the clients with
the computername, etc. Licensing is enforced at the server now. The client
no longer needs personalized with a serial number, license number,
computername, or anything else.

Thanks for listening to yet another rant, Lee. ;-)

Brad.

-Original Message-
From: Jon Stevens [mailto:[EMAIL PROTECTED]]
Sent: Saturday, December 30, 2000 6:14 PM
To: retro-talk
Subject: Re: Anyone used Retrospect on medium-large systems?


on 12/30/2000 3:25 PM, "ian" <[EMAIL PROTECTED]> wrote:

> So... the question is, since I am planning to look at the market for
> backup software for bigger systems, would it be reasonable for me to
> include Retrospect in the candidate list? Is anyone on the list backing
> up systems on this scale?

Hell yes. 

Retro is just as easy to use on a small network as a large one.

You just need to scale your hardware appropriately. In other words, don't
backup a 100 person network to a cd-r using a 66mhz 486 and localtalk. :-)

-jon



--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:
Search:  

For urgent issues, please contact Dantz technical support directly at
[EMAIL PROTECTED] or 925.253.3050.


--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:
Search:  

For urgent issues, please contact Dantz technical support directly at
[EMAIL PROTECTED] or 925.253.3050.

RE: Faster catalog matching (was RE: Anyone used Retrospect onme dium-large systems?)

[Thone, Bradley A (Sbcsi)]

Does the solution have "RISC" as part of it?

 ;-)

Brad.

-Original Message-
From: Craig Isaacs [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 03, 2001 4:23 PM
To: retro-talk
Subject: Faster catalog matching (was RE: Anyone used Retrospect on
medium-large systems?)



> > - with a lot of computers, the Retrospect catalog files can become
> > large,
> > and doing the comparisons between catalog and the current client
> > filesystem structure  prior to backing up each client can take a long
> > time.

We are working diligently on this issue. It will be faster in the next
release (scheduled for this year).

Craig



--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:
Search:  

For urgent issues, please contact Dantz technical support directly at
[EMAIL PROTECTED] or 925.253.3050.


--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:
Search:  

For urgent issues, please contact Dantz technical support directly at
[EMAIL PROTECTED] or 925.253.3050.

Re: best way to run retrospect with multiple stations on network

[matt barkdull]

What are you getting now for the backup times on the local machine?

That's a pretty good indication of the top speed of your system 
usually.  If the log shows 15MB/Min, just take the total amount 
backed up and divide it by 15MB and you will get the total minutes it 
takes.

So, for 8-10GB you are talking about 9 to 11 hours to back it up at 15MB/min.

I'm getting right around 100MB/Min for mine.



>Hi,
>
>thanks for your email. Yes its a total of 6-8gb for all dtp machines - i am
>deliberately forcing my users to keep the required backup files to a limit
>of 2GB each - so you think that one server should be able to handle all
>that.
>
>What i was thinking initially was to use the 7200/75 for backing up my
>appletalk clients onto tape - that is max of 2Gb total overnight an dthen
>having a another server hadnle the 8gb over the 100base - Dont thik one
>server could handle both over night or am i wrong?
>
>regards
>David



--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:
Search:  

For urgent issues, please contact Dantz technical support directly at
[EMAIL PROTECTED] or 925.253.3050.

Re: Ricoh MP 7083 CDRW and HP 9500

[Eric Ullman]

Hi Joe,

It's unlikely that we will qualify and write drivers for each possible CD-RW
drive and external FireWire/USB bridged enclosure. There are just too many
variables, and if we find problems with a drive's or bridge's firmware, it's
unlikely that we be able to convince the device's manufacturer to fix the
problem--with a likely response that their device works perfectly well
without the other.

We encourage Retrospect users to purchase already-supported devices. Such
devices are rigorously tested and will provide reliable restores.

http://www.dantz.com/index.php3?SCREEN=cdr_info

Best regards,

Eric Ullman
Dantz Development


Joe Pokupec <[EMAIL PROTECTED]> wrote:

> Sam's and Costco are carrying CD RW. I bought the HP 9500 to use with my
> Pyro FireWire external case and this works find with Toast, however,
> Retrospect will not recognize it. I know it is only supported on the Windows
> version.
> 
> I'm thinking of getting the Ricoh MP 7083 if Retrospect supports this but
> couldn't find any reference on the Dantz site.
> 
> Has anyone experimented with Retrospect and the Pyro FireWire case?



--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:
Search:  

For urgent issues, please contact Dantz technical support directly at
[EMAIL PROTECTED] or 925.253.3050.

Re: best way to run retrospect with multiple stations on network

[David Chokwenda]

Hi,

thanks for your email. Yes its a total of 6-8gb for all dtp machines - i am
deliberately forcing my users to keep the required backup files to a limit
of 2GB each - so you think that one server should be able to handle all
that. 

What i was thinking initially was to use the 7200/75 for backing up my
appletalk clients onto tape - that is max of 2Gb total overnight an dthen
having a another server hadnle the 8gb over the 100base - Dont thik one
server could handle both over night or am i wrong?

regards
David

> From: matt barkdull <[EMAIL PROTECTED]>
> Reply-To: "retro-talk" <[EMAIL PROTECTED]>
> Date: Wed, 3 Jan 2001 12:17:01 -0900
> To: "retro-talk" <[EMAIL PROTECTED]>
> Subject: Re: best way to run retrospect with multiple stations on network
> 
> Is that 6-8Gb each?
> 
> If so, unless you don't mind sitting there all night long swapping
> tapes, you should first look into a higher capacity drive.
> 
> You should be able to backup all 5 machines in that 12 hours over
> 100BaseT fairly easily, but it will depend more on the speed of the
> tape drive.  I suggest getting away from DAT and going something like
> DLT or better.
> 
> If you are talking about a total of 8-10 GB, then it should be no
> problem at all.  The 7200/75 should be able to do it just fine.
> Figure on that machine you are probably getting right around
> 15-20MB/min.  About  10 GB of data would take roughly 11 hours.
> 
> To speed things up you'll need a faster tape drive and faster SCSI,
> I'd also recommend using TCP/IP if you can.
> 
> 
> 
>> Hi,
>> 
>> I am a relatively new user, have retrospect network pack version 4.0 I have
>> two sets of clients on my LAN that I wish to be able to backup and would
>> apprecaite your suggestions.
>> 
>> 1-group of powerbook users and office machines that have combined storage of
>> 2GB.
>> 
>> 2-I have 4 dtp stations that need about 6-8GB stored
>> 
>> I have dedicated a machine 7200/75 with dat drive 4GB. Do you think that
>> this station is able to handle my client set 1 during a daily evenign
>> session of 12 hours, running over appletalk?
>> 
>> It appears i would have to set up a second server for my dtp users - my dtp
>> server and clients run on 100 base network - since there are such large
>> files taht are created through scanning jobs etc, and no pne wants
>> retrospect to interfere with work during the day what would you suggest is
>> the best option for backing my dtp clients up?
>> 
>> Thanks for any help
>> Regards
>> David
>> ---
>> David Chokwenda
>> Pre Press/ Systems Admin
>> Action Magazine
>> Mukuvisi Environemnt Centre
>> Hillside ext/Glenara Ave. South
>> Harare
>> Zimbabwe
> 
> 
> 
> --
> --
> To subscribe:[EMAIL PROTECTED]
> To unsubscribe:  [EMAIL PROTECTED]
> Archives:
> Search:  
> 
> For urgent issues, please contact Dantz technical support directly at
> [EMAIL PROTECTED] or 925.253.3050.



--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:
Search:  

For urgent issues, please contact Dantz technical support directly at
[EMAIL PROTECTED] or 925.253.3050.

Re: huge catalogs and slow snapshots

[Michael Kennard]

I'm actually the lone mac support in a large organisation. I would 
never give up my mac but the company uses PeeCees and I need to 
support that world as well. So I need to find the best solution for 
support without making it too obvious that I'm terribly biased. How 
many times have I said "get a mac" but I also get the same version 
for PC as well.

It's funny how the latest and greatest isn't always the best solution 
as evidenced by Retrospect for PC. I think the Mac version is 
actually a good product.

Michael

>Michael Kennard <[EMAIL PROTECTED]> wrote:
>
>>  I much prefer a Mac any day.  <
>
>Trust yr heart, Michael ...  ;-)
>I started with a Tandy, was intimately familiar with DOS -- even Edlin
>-- in pre-Windows days ... but:
>
>the ease of troubleshooting a Mac, ease of installing/removing yr own
>RAM and cards (especially in the G4s), the savings in not having to send
>the machine out for repairs, ability to know where to find any file
>(including System files) immediately without having to sort out a
>billion subdirectories then guessing at the cryptic naming scheme, being
>able to use the G4 as server, the mind-boggling speed of the G4s
>compared with PCs (closest thing to telepathy-with-a-machine I've ever
>experienced!), and the fact that G4s DON'T CRASH (at least, mine hasn't
>in over 8 months, daily use, except twice when I had NetsCom's memory
>set too low THAT app kept locking me up), Retrospect's stunning speed
>and reliability when backing up my (admittedly small) 27gigs of hard
>drives -- I wouldn't part with my Mac, not for a dozen FREE
>anything-elses ...
>
>Given a choice, it hardly seems logical for anyone to WILLINGLY opt for
>an inadequate yesterday-machine  :-)


--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:
Search:  

For urgent issues, please contact Dantz technical support directly at
[EMAIL PROTECTED] or 925.253.3050.