NTFS Alternative Data Streams

[pronto]

Hi Community,

 

how does Retrospect deal with ADS (Alternative Data Streams) informations? We are using a third party AFP-server (ExtremeZ-IP) on Windows and this put the Apple EAs (Extended Attributes) directly in the ADS instead of creating the common AppleDouble file. Now it would be interessting how Retrospect take notice about the existing ADS and if we get them back in case of a restore. Normally the EAs on Apple files are unnecessary or caused by cosmetic nature (colored labels on folders for example) but in some cases, like postscript fonts, the data of the file isn't stored in the data fork but in the ressource fork and therefor in an extended attribut and therefor in the ADS on a ExtremeZ-IP based AFP server. Do we running in a problem...?

 

Thx & Bye Tom

[Ramon88]

We have used ExtremeZ-IP for about 5 years and never ran into trouble when restoring files using Retrospect.

 

You can easily test this by backing up (ExtremeZ-IP) server based material and restoring it to an OSX client.

 

Unrelated however, we recently switched back to a stand alone Mac Mini as a server because it wasn't that expensive (compared to ExtremeZ-IP ocer a couple of years) and is waaaay faster when using Spotlight (unless they solved that bug during the last year). For storage we used an iSCSI target controlled by ATTO Xtend SAN iSCSI initiator. :-)

[pronto]

we are coming from Helios and this was really a very expensive way to establish an AFP server but it works perfectly until Snow Leopard was coming. At this point Helios want a lot of money for an update (for us round about 5.000 Eur, and keep in mind, for an update) but some of the known SL bugs aren't fixed till this day. So we switched to ExtremeZ-IP which comes with a very charming price comparing to Helios.

 

We discussed also the possibility to work with an Apple Server but we decided against it. The major problem is Apples dictatorial hardware branding. If you need a new hardware at the wrong time, unfortunately directly after a new Mac OS release was launched, you have to work with this new OS version and they don't give a damn if there is still a SMB or an AFP bug unfixed or not. We learned this lession with Snow Leopard. Since OSX a new operating was never so critical like Snow Leopard...

 

I will try a restore with some folders who have some EAs respectively some ADS.

 

Bye Tom

[Ramon88]

Fortunately for us, we don't need a lot of server power for OSX, so we got a simple 2010 model of the Mac Mini. Uses less than 10W when idle, maybe 25W peak. We only use it for OSX archive storage. So nothing fancy is needed. OS can be updated for only a couple of bucks (we use regular OSX, not the Server version).

 

We thought Helios was way to expensive and I don't think there are many alternatives left but ExtremeZ-IP. For what it is, it's quite good. But because of lacking Spotlight performance we dumped it. Of course we use a Windows 2008 R2 server for SMB file sharing, AD etc.

 

Our solution probably isn't the answer for you guys. But you have to be wary when Apple updates their OS (Lion anybody) and you will be sure to get problems with ExtremeZ-IP compatibility with OSX which can take ages to get solved, if ever.

 

It would have been so much more convenient if Apple and Microsoft would have teamed up and made sure AFP over TCP would have been working out of the Windows 2008 box.

 

Well, maybe it will happen as Apple seems to stop making Xserve systems. But that's probably wishful thinking.

[Cygnis]

You can easily test this by backing up (ExtremeZ-IP) server based material and restoring it to an OSX client.

Interesting. I just tried this today, and the restored files had incorrect modification dates, and had lost the Mac 'creator program' attribute (or whatever it is called; the piece of data that distinguishes a Photoshop TIFF from a generic TIFF, for example). Duplicating between the server and Mac clients seems to have similar results. (Can't remember whether it was duplicating from server to Mac or from Mac to server that gave me the problems, but I think it was both.)

 

Did you ever encounter this? Any idea on how to solve it? To be honest, I never expected this to work properly (given that Retrospect presumably uses a different NTFS<->HFS method to ExtremeZ-IP), but now that you've mentioned having it work for you, I'm curious.

 

We're using ExtremeZ-IP 7 on a Win 2003 Small Business Server. Our Macs run OSX 10.5.8.

 

As expected, restoring Mac client data back to the Mac client works just fine, as does restoring ExtremeZ-IP data back to the server (then copying to the Mac via ExtremeZ-IP).

Edited January 10, 2011 by Guest

[Ramon88]

Unfortunately I don't remember it that well... But we had never trouble restoring Mac client backup files to the Windows Server based share (running ExtremeZ-IP) and copying that back to the Mac client. We actually rarely did restore files directly to Mac based clients, but almost always to a network share.

[Cygnis]

But we had never trouble restoring Mac client backup files to the Windows Server based share (running ExtremeZ-IP) and copying that back to the Mac client. We actually rarely did restore files directly to Mac based clients, but almost always to a network share.

Ah, thanks for clarifying this. I thought you had meant directly restoring ExtremeZ-IP data to a Mac client destination, rather than via a server volume.