Subject: [Fwd: Retrospect]

From: Mac Conin <[email-masked]>
Date: Wed, 12 Dec 2001 12:39:21 +0100

For your information only

asking for a beta client for linux dantz (retrospect)
wrote that the software will very soon be available.

Nicolas Thiriot wrote:
> 
> Bonjour,
> 
> Es ist nicht mehr möglich diese Beta Version zu bekommen jetzt. Unser
> Entwiklung Abteilung arbeitet für diesen Linux Client und dieser Client wird
> bald verfügbar sein.
> 
> Mit freundlichen Grüssen.
> 
> Nicolas Thiriot
> -------------------------------------------
> Nicolas Thiriot
> DACH Account Executive
> Dantz Development Corporation
> 77, rue du Faubourg Saint Denis
> 75010 Paris/France
> Tel : 00331 55 33 02 04
> Fax : 00331 55 33 02 09
> [email-masked]
> 
> www.dantz.com - www.dantz.com/de
> www.dantz.fr - www.betterbackup.com
> 
> Technical Support :
> * Germany : 0800 180 21 21
> * Switzerland-Austria : 00331 55 33 02 08
> * Swiss french speaking : 00331 55 33 02 05
> --------------------------------------------
> 

-- 

mit freundlichen grüssen

____________________________________________________________

Mac Conin                        Taubengasse 9
                                 D 50676 Koeln
CONIN - Agentur                  tel : +49-221-218 032
EUC Online Service GmbH          tel : +49-221-923 27 33
punktum postscript-Service       tel : +49-221-240 60 92
http://www.euc.de                fax : +49-221-239 651

---

From: Thomas Kaiser <[email-masked]>
Date: Wed, 12 Dec 2001 14:40:50 +0100

> wrote that the software will very soon be available.

Do you know whether Retrospect will support the native Netatalk format or
just plain linux?

The difference would be:

In the first case Retrospect would treat the two files that build one 'real'
mac-file (./file and ./.rsrc/file) as a single file including the finder
metadata like file type, creator, label, comment, etc. A file backed up in
this way would be easy to restore on a mac in a mac's native filesystem
(nice if the Netatalk server is the only linux box and it crashed
completely, so users will be able to access their data).

In the latter case two files would be backed up and if you want to restore
them on another platform you would also get two separate files (and have to
manually merge them back to a fully functional mac file)...

In addition, if a backup software 'knows' how to deal with Netatalk's file
format then it would be easy to backup/restore complete files (including
both the data and resource fork) avoiding the possibility to forget one of
both forks.

Thanks in advance,

Thomas

---

From: Mac Conin <[email-masked]>
Date: Thu, 13 Dec 2001 18:17:46 +0100

Howdy,

I'm not quite sure what type of software that will be. We Are now for a
time after that and the only announcement from dantz is 'it's a nearly
final beta'.

But let me guess:
In order to sell as much of their software I think it will be a
separate product for linux which means you'll get a retrospect backup
software as server license for linux. How that software will deal with
the appledouble files .... 

maybe someone other here knows more about the folks at dantz

-- 

best regards

Mac Conin                        Taubengasse 9
                                 D 50676 Koeln

---

From: Matthew Keller <[email-masked]>
Date: 13 Dec 2001 12:41:37 -0500

If the software is backing up data over ASIP/AFP, then it won't matter
if "it" has any concept of AppleDouble - Everything will be ducky. If
the software is backing up over it's own protocol installed on the Linux
box, then it will treat AppleDouble and other Netatalk metadata the same
as Linux does - As files/folders- Nothing special. Either way, it should
be fine.
	*Disclaimer: I know nothing about Dantz nor their products, and my
statements are general about they way things "should" be happen. This
product may, for example, not back up hidden files/folders (starting
with dots) - Then it would obviously break Netatalk files.

-- 

Matthew Keller
Enterprise System Analyst
Computing & Technology Services
Information Services Division
State University of NY at Potsdam
Potsdam, NY USA

http://mattwork.potsdam.edu/

---

From: Thomas Kaiser <[email-masked]>
Date: Thu, 13 Dec 2001 22:10:12 +0100

On 13 Dec 2001 12:41:37 -0500, Matthew Keller wrote:

> if "it" has any concept of AppleDouble - Everything will be ducky.

This is the way many sites do it (even large *NIX servers) to have the
backed up data accessible even if the server crashed totally...

The only problem seems to be the inability to setup ownerships and access
rights correctly in every case when restoring...

> If the software is backing up over it's own protocol installed on the Linux
> box, then it will treat AppleDouble and other Netatalk metadata the same as
> Linux does - As files/folders- Nothing special.

There is a third way, which I prefer.

Flashnet (<http://www.sgluk.com/flashsite/index.htm>) and DIMM (obviously
pages only available in german: <http://www.dimm.de/Backup/backup.htm>) or
ES-Backup (<http://www.ugsoft.de/products/esbackup/index2.html>) -- the
first for Xinet's Fullpress, the latter two for Helios' EtherShare -- which
"understand" the special meanings of the two different files and partly much
more also...

ES-Backup for example (I played with this software around a bit, so I have a
bit deeper knowledge about) can be configured to treat AFP-volumes different
than 'normal' *NIX-data. In this 'special-mode' it will always touch both
forks itself and (by using the dt commands that communicate with Helios'
desksrv process to keep the volumes desktop databases consistent) avoids
problems with IDs too.

Unfortunately there seems to be no software that supports Netatalk natively.
But perhaps the developers of DIMM or ES-Backup plan to port their softwares
to support netatalk if they see a demand for it?

> Either way, it should be fine.

Well, I'm very happy that Netatalk will have a solid database-driven
solution for persistant FIDs and DIDs soon. But from this moment on, we will
get a bit in trouble, when we handle files/folders (move, create, rename,
delete, etc.) besides the database (like it's happening when doing
backups/restore local on the server).

I'm doing some research on the potential pitfalls at the moment, but
unfortunately a friend of mine ran out of spare time (he will provide me
with a small utility to dump ids from the mac side) so results will be
delayed... 

Regards,

Thomas