RE: Transfer Rates - Dantz Help?

[Grein, Randy]

 What you lose is time. Regardless of what v42 was written to do (yes, it
could in theory be applied to any data stream) increased compression ratios
will take time. Sure the spec says 'on the fly', but does it really happen
that way? No! I don't see anyone attempting to do data compression on T1
lines for exactly that reason. Your idea of client selective compression
ratios would help that some, but is it enough to warrant the trouble and
expense? Probably not, the rest of the backup industry certainly doesn't
seem to be running in that direction.

I suspect our disagreement comes over the relative importance of media
capacity vs backup window. It's unfortunate but true that hard drive size
has eclipsed backup media size again, so we're stuck with most clients
needing autochangers. Once autochangers are assumed then media size becomes
less critical, and the backup window and backup speed becomes important.
Retrospect does a pretty good job of reducing the backup data set, almost as
good a job as my former favorite - Palindrome.

It may be of interest that several vendors have looked at on the fly data
compression for things like network traffic, but have always abandoned the
idea because of performance issues. 

-Original Message-
From: matt barkdull
To: retro-talk
Sent: 2/26/01 2:36 PM
Subject: RE: Transfer Rates - Dantz Help?

>Matt, if you think you're actually getting 4:1 real world compression
out of
>a modem, I suggest you read some of the research on the subject.

I never said that... What I did say:

>Yes, I know that advertised and what you really get are totally
>different, but all I know is that if something is advertised at 4:1,
>it will be more likely to get at least 2:1 than 2:1 is likely to.

If I attempt 4:1 compression and only get 2-3% on some files, but on 
some files I got 2-3:1, what did I lose or gain?

If I attempt 2:1 compression and only get 2-3% on some files, but on 
some other files I got 1.2 - 1.5:1, what is the advantage?

Keep reading before replying...

4:1 compression under V.42bis is an on the fly compression.  Granted 
the data rates under that specification are a lot less.  (up to 1.5Mb 
vs up to 320MB).  (V.42bis was also written for use on T1.)

What I don't understand is why there is not an option for greater 
compression even if the cost is speed.

For example, let's say I have 4 computers holding a total of 8GB to 
backup over the weekend and my tape drive is only 4GB without 
compression.  With 2:1 compression I am  guaranteed it will not fit. 
With 4:1 compression it might.  It all depends on the data.  I really 
don't care if it takes 24 hours to do it, because the backup goes 
over the weekend.  It should be an option.


BTW - if you backup JPEGs, GIFs, MPEGs, and several others you will 
not compress these files at all. In fact, any compression done on 
them usually results in a larger file.  These are compressed already 
with a compression scheme that is far better than anything else for 
the specialized purpose they do.  Yes, I know about the data losses 
with certain compression schemes, like JPEG will discard information. 
That is totally unacceptable with backup systems.

If you are backing up a normal desktop system, you should be getting
about
1.5:1 compression on average.  If you have systems with a lot of 
graphic files or already compressed files, then yes, the compression 
will be closer to 1:1 (non-compression).


The point is, that you try to achieve 200% and only get 150%, where 
as if you try for 400% and get 200%, you've done better.  If the 
sacrifice was speed, then have a checkbox list that says:

   O  Software Compression 4:1
   O  Software Compression 2:1
   O  Hardware Compression

And let the users decide.





--
--
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: Transfer Rates - Dantz Help?

[matt barkdull]

>Matt, if you think you're actually getting 4:1 real world compression out of
>a modem, I suggest you read some of the research on the subject.

I never said that... What I did say:

>Yes, I know that advertised and what you really get are totally
>different, but all I know is that if something is advertised at 4:1,
>it will be more likely to get at least 2:1 than 2:1 is likely to.

If I attempt 4:1 compression and only get 2-3% on some files, but on 
some files I got 2-3:1, what did I lose or gain?

If I attempt 2:1 compression and only get 2-3% on some files, but on 
some other files I got 1.2 - 1.5:1, what is the advantage?

Keep reading before replying...

4:1 compression under V.42bis is an on the fly compression.  Granted 
the data rates under that specification are a lot less.  (up to 1.5Mb 
vs up to 320MB).  (V.42bis was also written for use on T1.)

What I don't understand is why there is not an option for greater 
compression even if the cost is speed.

For example, let's say I have 4 computers holding a total of 8GB to 
backup over the weekend and my tape drive is only 4GB without 
compression.  With 2:1 compression I am  guaranteed it will not fit. 
With 4:1 compression it might.  It all depends on the data.  I really 
don't care if it takes 24 hours to do it, because the backup goes 
over the weekend.  It should be an option.


BTW - if you backup JPEGs, GIFs, MPEGs, and several others you will 
not compress these files at all. In fact, any compression done on 
them usually results in a larger file.  These are compressed already 
with a compression scheme that is far better than anything else for 
the specialized purpose they do.  Yes, I know about the data losses 
with certain compression schemes, like JPEG will discard information. 
That is totally unacceptable with backup systems.

If you are backing up a normal desktop system, you should be getting about
1.5:1 compression on average.  If you have systems with a lot of 
graphic files or already compressed files, then yes, the compression 
will be closer to 1:1 (non-compression).


The point is, that you try to achieve 200% and only get 150%, where 
as if you try for 400% and get 200%, you've done better.  If the 
sacrifice was speed, then have a checkbox list that says:

   O  Software Compression 4:1
   O  Software Compression 2:1
   O  Hardware Compression

And let the users decide.





--
--
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: Shut Down

[Philip Chonacky]

The computer will not sleep if the "waiting for backup" screen is active.



>matt barkdull submitted these questions, and the answers are important
>to me, too -- I haven't seen a response yet -- can anyone help?
>
>when 'Shut Down' is selected and Retrospect shutdown dialog comes up:
>>Will it kill the Energy Saver process?  I mean, if the machine is
>>set to shut down in the Energy Control panel at, say 10pm, and the
>>backup starts up just before that, will it prevent the shutdown?  <
>
>>If the machine is set to startup at a certain time, but it never
>>shut off and still has the Retrospect shutdown dialog, will it do
>>anything at all?  <
>
>I'm not in a position to run even a small test on this for myself 'cuz
>my backup disc is blown and I'm in process of obtaining new one ... but
>would like to get an answer to this question before its immediacy fades
>into the past -- wch happens QUICKLY, nowadays ...
>
>thanks kindly,
>
> - ilyes
>
>
>--
>--
>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.

-- 
___
Philip Chonacky, IT Manager
Barrett Companies
ph. (617) 577-9500
fx. (617) 577-1010
mailto:[EMAIL PROTECTED]


--
--
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: Transfer Rates - Dantz Help?

[Steve Axthelm]

At 09:52 -0900 2/26/01, matt barkdull wrote:
[snip]
>I know that the on-fly compression is difficult to maintain speed, 
>but it seems like better than 2:1 should be possible.  I'm not much 
>of a wiz at all with compression, however I see modems getting 
>v.42bis (4:1) on the fly, it seems like a little work and this 
>should be possible for client and server as well.
>
>Yes, I know that advertised and what you really get are totally 
>different, but all I know is that if something is advertised at 4:1, 
>it will be more likely to get at least 2:1 that 2:1 is likely to.

For my backups at least (mostly graphics) I doubt that the savings 
would amount to more than 2 or 3 percent. Modems only approach those 
numbers on text files.

>Alladin is cross platform.  Dantz covers the same platforms.
>
>Yes, most people use hardware compression, but this is mostly 
>because the hardware and software compression are likely to get the 
>same results.
>
>Why would anyone want to write their own compression?  I mean, a 
>license deal from Alladin, who's been doing it since the early days 
>of Mac, would seem like it would be far more cost effective.

Yep and their file format (or formats as it were) as far as I can 
tell are proprietary. If Dantz did implement compression, I for one 
would be much more comfortable with a open file format.

-- 
-Steve

---
Steve Axthelm
Mudpuppy Studios
[EMAIL PROTECTED]
503.227.1775


--
--
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: The "FINDER.DAT" bug with Retro 4.3

[Irena Solomon]

Hello,

I've included below the relevant part of the Retrospect 4.2 User's Guide
that discusses the Finder.Dat file and gives some background on what happens
when a Mac file is copied to a PC. This has also been added to the
Knowledgebase (this resource is *always* growing, and feedback is
appreciated!)

This feature exists in Retrospect to allow you to duplicate a file from a
Mac to a PC, and then to duplicate it back without losing any component of
that file; in this way Retrospect compensates for the differences in how the
two operating systems see files and their attributes.

Not all Mac files are dual-fork, which likely explains why you don't get the
message on all files.

Regards,

Irena Solomon
Dantz Technical Support
925.253.3050


>From p. 99, Retrospect 4.2 User's Guide:

Unlike files on Windows volumes, many Macintosh files are made up of two
parts, called forks: one fork includes data and the other includes
resources. When Retrospect copies a dual-fork Macintosh file to a Windows
client volume, it takes the following steps to separate the forks into
different files.

- It stores the data fork in a new file, which has the same name as the
original file.

- It creates a new folder named Resource.Frk, which is hidden and resides in
the same folder path as the data fork file.

- It stores the resource fork in a new file which resides in the
Resource.Frk folder and has the same name as the original file.

- It tracks fork-separated files in a hidden file named Finder.Dat, which
resides in the same folder path as the data fork file.

If you move one of these Macintosh files on a Windows computer, it is
unusable unless you also move the other files and folder. When you use a
Retrospect Browser to view a Windows client volume containing these split
Macintosh files, only a single file appears. When viewed from Windows, the
extra files appear (unless Windows is set to hide hidden files). When you
back up the files to a backup set or duplicate them to a Macintosh volume,
Retrospect integrates them into the single original file.


--
> From: Steve Maser <[EMAIL PROTECTED]>
> Subject: The "FINDER.DAT" bug with Retro 4.3
> 
> Hi all,
> 
> I've been able to see this one in action.  It's something you
> might want to be aware of.
> 
> If a user puts a PC-formatted ZIP disk into a Mac, the invisible
> file "finder.dat" is created on the disk (as normal).  Other
> invisible folders are created, but they aren't a problem.
> 
> If the user then puts the disk back into the PC and copies the
> *entire contents* of the disk to the hard disk of the PC, then the
> following happens:
> 
> Because the file "finder.dat" is present on the PC hard disk,
> Retrospect 4.3 will indicate that *some* (but not necessarily *all*)
> other files within that folder are "error -43 -- file/folder not
> found".
> 
> And *some -- but, again, not necessarily all -- subfolders* within
> that folder are skipped by Retrospect, too.
> 
> 
> The only workaround I've found is to be sure that all copies of
> "finder.dat" are deleted from the hard drive.  Retrospect does not
> see the "finder.dat" files when it scans the hard drives, so it can't
> be marked out from a selector to address the problem -- unfortunately.
> 
> According to a tech I talked to at Dantz, "this problem has been
> around for awhile" -- but it's not on the knowledgebase.
> 
> The only solution is to delete all copies of "finder.dat" from the
> PC.  The tech suggested "trying the Windows product".  He didn't know
> if this was going to be a problem with the OSX version of Retrospect.
> 
> FYI...
> 
> - Steve



--
--
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: Transfer Rates - Dantz Help?

[Thone, Bradley A (Sbcsi)]

The best "overall" compression I've ever seen has been about 1.5:1. That is,
a file that was 3 MB in size now is only 2 MB. Sure, I've seen better (and
worse), but on average, for the contents of a typical hard disk, compression
probably will be somewhere around 1.5:1. At least that's been my experience.
Please don't ask me to actually define "typical"...

Even PKZIP's EXTRA compression ("-ex") doesn't do much (if any) better than
it's standard compression option. But, the EXTRA compression can take
several times longer for only  a few % difference in .ZIP size from standard
compression. You gotta be really desperate to want to use the EXTRA
compression...

But that's way beside my point, and not beside my point. The thrust of my
argument is this: networks are slower than CPUs and hard disks. Somewhat
compressing the data (and not sacrificing the streaming of data to the
server) before sending it across a relatively slow link (even 100 Mb is
relatively slow compared to hard disk transfers) will almost assuredly
provide performance improvements. Fantastic compression is not required at
the workstation - just something.

I suppose that because the data stream were already slightly compressed, the
tape drive's hardware could possibly do very little or no compression. I
suppose also that as an alternative to shipping the compressed data stream
to the tape drive, the server could take the compressed data stream,
decompress it, then send it to the tape drive for the more traditional whack
at compression. My servers have gobs of CPU cycles just waiting to be put to
good use.

I'm sure Dantz could work out the details.

Brad.

-Original Message-
From: matt barkdull [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 26, 2001 12:52 PM
To: retro-talk
Subject: RE: Transfer Rates - Dantz Help?


A month or so ago I wrote a rant about how Dantz should work with 
Alladin and come up with a better compression scheme.

I know that the on-fly compression is difficult to maintain speed, 
but it seems like better than 2:1 should be possible.  I'm not much 
of a wiz at all with compression, however I see modems getting 
v.42bis (4:1) on the fly, it seems like a little work and this should 
be possible for client and server as well.

Yes, I know that advertised and what you really get are totally 
different, but all I know is that if something is advertised at 4:1, 
it will be more likely to get at least 2:1 that 2:1 is likely to.

Alladin is cross platform.  Dantz covers the same platforms.

Yes, most people use hardware compression, but this is mostly because 
the hardware and software compression are likely to get the same 
results.

Why would anyone want to write their own compression?  I mean, a 
license deal from Alladin, who's been doing it since the early days 
of Mac, would seem like it would be far more cost effective.



>It'd be really cool if the clients would compress the data before shipping
>it off to the (slow) network. I think we'd see better backup rates,
>especially since compression is so fast on today's computers.
>
>It wouldn't have to be much compression - kinda like PKZIP's "-ef" or "-es"
>switch (for FAST or SUPERFAST compression). Even a meager 10% compression
>would be a significant improvement.
>
>Decompressing at the server would be optional (Perhaps necessary to provide
>backward compatibility with restores to older clients that don't know what
>compression is. Then again the server would know the version of the client
>and whether the client supports compression.). I'd prefer optional, and let
>the tape drive hardware compression further compress the data if possible.
>
>Of course I'll leave the implementation details to Dantz. ;-)
>
>Brad.



--
--
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: Transfer Rates - Dantz Help?

[Grein, Randy]

Matt, if you think you're actually getting 4:1 real world compression out of
a modem, I suggest you read some of the research on the subject. Compression
is highly variable, depends on the data, and 4:1 is rarely achieved. What's
more it induces considerable latency, often exceeding the value of the
compression. The irony is that lower compression rates take less processing
time and power than attempting to achiieve higher compression.

Now latency isn't as big an issue for backup as it is for a highly dynamic,
realtime application like modems support. However, the data pipe is vastly
greater. Fast ethernet has a thousand times the bandwidth of a 56 k modem,
about twice the  uncompressed streaming rate of a 7000 series DLT drive.
What does this all mean? Basically if you have a fast ethernet connection
with no routers inbetween the host and station the hardware should support
uncompressed streaming to tape. Compressed files will probably not quite
stream, but to do software compression at the clients would require very
fast clients; it's one of the many specialized tasks that is easier to do in
hardware - at the tape drive. You're most likely constrained by disk access
speed anyway.

BTW, this is an old question, hardly unique to Dantz. Client compression has
been tried, and can be a useful tool under some circumstances, but it
usually causes as many problems as it solves. And you're right about
aquiring vs creating compression technologies. It usually doesn't make sense
to reinvent that particular wheel. Other methods of improving data feeds to
the tape drive include intelligent backup (something Retrospect is very good
at) and multiplexing data sources. This last option has it's proponents, but
tends to be rather cranky in practice - and restores are very slow.

-Original Message-
From: matt barkdull
To: retro-talk
Sent: 2/26/01 10:52 AM
Subject: RE: Transfer Rates - Dantz Help?

A month or so ago I wrote a rant about how Dantz should work with 
Alladin and come up with a better compression scheme.

I know that the on-fly compression is difficult to maintain speed, 
but it seems like better than 2:1 should be possible.  I'm not much 
of a wiz at all with compression, however I see modems getting 
v.42bis (4:1) on the fly, it seems like a little work and this should 
be possible for client and server as well.

Yes, I know that advertised and what you really get are totally 
different, but all I know is that if something is advertised at 4:1, 
it will be more likely to get at least 2:1 that 2:1 is likely to.

Alladin is cross platform.  Dantz covers the same platforms.

Yes, most people use hardware compression, but this is mostly because 
the hardware and software compression are likely to get the same 
results.

Why would anyone want to write their own compression?  I mean, a 
license deal from Alladin, who's been doing it since the early days 
of Mac, would seem like it would be far more cost effective.



--
--
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.

The "FINDER.DAT" bug with Retro 4.3

[Steve Maser]

Hi all,

I've been able to see this one in action.  It's something you 
might want to be aware of.

If a user puts a PC-formatted ZIP disk into a Mac, the invisible 
file "finder.dat" is created on the disk (as normal).  Other 
invisible folders are created, but they aren't a problem.

If the user then puts the disk back into the PC and copies the 
*entire contents* of the disk to the hard disk of the PC, then the 
following happens:

Because the file "finder.dat" is present on the PC hard disk, 
Retrospect 4.3 will indicate that *some* (but not necessarily *all*) 
other files within that folder are "error -43 -- file/folder not 
found".

And *some -- but, again, not necessarily all -- subfolders* within 
that folder are skipped by Retrospect, too.


The only workaround I've found is to be sure that all copies of 
"finder.dat" are deleted from the hard drive.  Retrospect does not 
see the "finder.dat" files when it scans the hard drives, so it can't 
be marked out from a selector to address the problem -- unfortunately.

According to a tech I talked to at Dantz, "this problem has been 
around for awhile" -- but it's not on the knowledgebase.

The only solution is to delete all copies of "finder.dat" from the 
PC.  The tech suggested "trying the Windows product".  He didn't know 
if this was going to be a problem with the OSX version of Retrospect.

FYI...

- Steve


-- 

Steve Maser ([EMAIL PROTECTED])| Thinking is man's only basic virtue,
Systems Project Coordinator  | from which all the others proceed.
Dept. of Mechanical Engineering  |  -- Ayn Rand


--
--
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: Transfer Rates - Dantz Help?

[matt barkdull]

A month or so ago I wrote a rant about how Dantz should work with 
Alladin and come up with a better compression scheme.

I know that the on-fly compression is difficult to maintain speed, 
but it seems like better than 2:1 should be possible.  I'm not much 
of a wiz at all with compression, however I see modems getting 
v.42bis (4:1) on the fly, it seems like a little work and this should 
be possible for client and server as well.

Yes, I know that advertised and what you really get are totally 
different, but all I know is that if something is advertised at 4:1, 
it will be more likely to get at least 2:1 that 2:1 is likely to.

Alladin is cross platform.  Dantz covers the same platforms.

Yes, most people use hardware compression, but this is mostly because 
the hardware and software compression are likely to get the same 
results.

Why would anyone want to write their own compression?  I mean, a 
license deal from Alladin, who's been doing it since the early days 
of Mac, would seem like it would be far more cost effective.



>It'd be really cool if the clients would compress the data before shipping
>it off to the (slow) network. I think we'd see better backup rates,
>especially since compression is so fast on today's computers.
>
>It wouldn't have to be much compression - kinda like PKZIP's "-ef" or "-es"
>switch (for FAST or SUPERFAST compression). Even a meager 10% compression
>would be a significant improvement.
>
>Decompressing at the server would be optional (Perhaps necessary to provide
>backward compatibility with restores to older clients that don't know what
>compression is. Then again the server would know the version of the client
>and whether the client supports compression.). I'd prefer optional, and let
>the tape drive hardware compression further compress the data if possible.
>
>Of course I'll leave the implementation details to Dantz. ;-)
>
>Brad.



--
--
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: Shut Down

[ilyes]

matt barkdull submitted these questions, and the answers are important
to me, too -- I haven't seen a response yet -- can anyone help?

when 'Shut Down' is selected and Retrospect shutdown dialog comes up:
>Will it kill the Energy Saver process?  I mean, if the machine is 
>set to shut down in the Energy Control panel at, say 10pm, and the 
>backup starts up just before that, will it prevent the shutdown?  <

>If the machine is set to startup at a certain time, but it never 
>shut off and still has the Retrospect shutdown dialog, will it do 
>anything at all?  <

I'm not in a position to run even a small test on this for myself 'cuz
my backup disc is blown and I'm in process of obtaining new one ... but
would like to get an answer to this question before its immediacy fades
into the past -- wch happens QUICKLY, nowadays ...

thanks kindly,

 - ilyes


--
--
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: Transfer Rates - Dantz Help?

[Thone, Bradley A (Sbcsi)]

It'd be really cool if the clients would compress the data before shipping
it off to the (slow) network. I think we'd see better backup rates,
especially since compression is so fast on today's computers.

It wouldn't have to be much compression - kinda like PKZIP's "-ef" or "-es"
switch (for FAST or SUPERFAST compression). Even a meager 10% compression
would be a significant improvement.

Decompressing at the server would be optional (Perhaps necessary to provide
backward compatibility with restores to older clients that don't know what
compression is. Then again the server would know the version of the client
and whether the client supports compression.). I'd prefer optional, and let
the tape drive hardware compression further compress the data if possible.

Of course I'll leave the implementation details to Dantz. ;-)

Brad.

-Original Message-
From: Irena Solomon [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 23, 2001 4:47 PM
To: retro-talk
Subject: Re: Transfer Rates - Dantz Help?


Yes, these are numbers before compression. The client does not compress data
before sending it across the network. Further, Retrospect has no way to know
what kinds of compression you're getting if you're using hardware
compression. All number reported reflect the raw data being copied from the
source.

Regards,

Irena Solomon
Dantz Technical Support
925.253.3050

Try our new Searchable Knowledgebase at:
http://partners.dantz.com:591/faq/


> From: David Ross <[EMAIL PROTECTED]>
> Subject: Re: Transfer Rates - Dantz Help?
> 
>> The performance is based on the raw number of MB transferred to the
backup
>> device from the source volume.
> 
> BEFORE software compression?
> 
> I ask since as I understand it remote clients compress before shipping
> to the Retrospect module that doing the writing to the device.
> 
> Thanks



--
--
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: Encryption protection

[Eric Ullman]

Good question, Todd.

Basically, Retrospect's SimpleCrypt encryption method is faster than DES,
but the tradeoff for speed yields a less robust encryption scheme.
Conceivably, it would take less time to decipher data that had been encoded
with SimpleCrypt than with DES (or some other strong encryption method).

Encryption should never be relied on as the sole means of keeping your data
from unwanted access. It should always be used in conjunction with physical
security measures. Any data important enough to worry about someone cracking
its encryption method is important enough to restrict access to.

One benefit of backing up computer data to compact, removable media is that
it is relatively easy to collect and store in a secure location. Don't
dismiss this advantage.

I hope this helps.

Eric Ullman
Dantz Development


Todd Reed <[EMAIL PROTECTED]> wrote:

> On a mailing list I inhabit, the quality of Retrospect's encryption
> was challenged as being inadequate.  The comment was that neither DES
> or Dantz' proprietary  Vernam cipher would be secure from a serious
> attempt to retrieve stolen backup data.
> 
> What's the scoop here? I've been running on the assumption that if I
> lost a tape under mysterious circumstances that the information would
> be unrecoverable.
> 
> How does SimpleCrypt compare to DES and how hard would someone have
> to try to break the encryption?



--
--
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: Shut Down

[Paul Fyfe]

At 11:27 PM -0900 22/2/01, matt barkdull wrote:
>What I want to know is what processes are shut down when I say "Shut 
>Down" and it goes to the Retrospect shutdown dialog?
>
>I mean, does it close all applications?
>
>Does it kill any of the extension processes like clocks, screen savers, etc.?
>
>Will it kill the Energy Saver process?  I mean, if the machine is 
>set to shut down in the Energy Control panel at, say 10pm, and the 
>backup starts up just before that, will it prevent the shutdown?
>
>If the machine is set to startup at a certain time, but it never 
>shut off and still has the Retrospect shutdown dialog, will it do 
>anything at all?

One thing that is significant: it does not unmount server volumes. I 
have trained my users to trash them before shutdown.

Paul Fyfe.


--
--
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.