[MDhaliwal]

I used to use Iron Mountain, when I worked in an office environment. We’d just schedule them to come by daily in the morning to pickup one of their metal boxes that’s barcoded. We’d let them know when we were going to be closed so that they wouldn’t come and so forth. They’d also drop back the old boxes on the date we specified when they were originally picked up. Never had too much of an issue. There are other companies that provide this service, but this is probably the most common and a great practice for true disaster recovery; something that too many folks neglect.

[MDhaliwal]

If your looking to manipulate 100TB of data, I’d be looking into Atempo’s Time Navigator or BakBone’s NetVault. Both scale very well and work very well in cross platform environments. You’ll also get consolidated/synthetic fulls, which will cut your backup time big time.

Both products let you add in pre and post flight scripts to each backup job, or even hosts, so you can really customize your backup in many aspects.

If your looking at hardware, Exabyte has good performance, support and excellent pricing. You can get something in their LTO 3 Magnum line and that will be able to handle many a TB! If Exabyte isn’t your flavor, you can look at IBM or any other vendor. I’ve run IBM gear before, as well, and found it to be rock solid reliable.

How do you envision all of this working together?

Michael

[MDhaliwal]

Fair enough.

As long as the server can resolve itself properly in DNS, its usually OK. You can use something like scutil to statically assign the FQDN to the server. If it can use that same name in both locations, then your limiting any configuration issues that might arise.

The average Xsan probably won’t want to be moved, though. Multiple Xserves, multiple Xserve RAID units, fibre switches, gigabit switches, wiring, etc…that’s quite a bit to move around multiple times!

Ideally, you’d probably want to talk to an Apple rep who could provide you with a test deployment to see, like at one of the Apple offices. This way you could kick the tires on the Xsan without having to set it up multiple times, etc.

[MDhaliwal]

[QUOTE BY= rhcw] Don’t forget that as well as setting the streamguard and device scan correctly on all the switch ports you need to also be careful how you set the XSERVE RAID cache settings etc. This only became an issue with 1.5 FW and Admin. If you get this wrong then you will see RSCN behaviour when you shut down clients and reboot clients. [/QUOTE]

Which setting are you talking about? The only setting I can think of that can degrade performance a bit that was introduced in Xserve RAID firmware 1.5 would be the Host Cache Flushing, which you set per controller and can re-enable itself on hardware reboot.

[MDhaliwal]

[QUOTE BY= rhcw] [QUOTE BY= maccanada] IP addressing – yes there are several files living in /Libray/Filesystems/Xsan/config with IP addresses in them. Changeip was never designed for an Xsen environment so changing IPs can get messy. Like you say, best to make sure the initial IP is a permanent one.
~Ian[/QUOTE]

Are we saying that changeip will work but will do you no good if it is an MDC on which you are changing the IP after the fact?

On a related subject, lets say you set the IP to 10.0.0.2 and use a DNS that is good for the off-site location where you are pre-building. What bad things happen when you finally install on site and leave the IP alone but have to change the DNS to the one that is correct for the new network?[/QUOTE]

changeip hasn’t been expanded to change the Xsan config files, just the server itself.

Out of curiosity, why build the MDC offsite? Just wondering. Ideally, you don’t want to move it.

[MDhaliwal]

A lot of people miss this step or forget which port gets what kind of treatment. Pretty much, you have two types of ports, initiators and targets. Initiators are all of your clients, controllers, etc. Targets are your storage devices, such as Xserve RAID units, tape devices, etc.

Think of it this way…

If a client reboots or goes offline, do you care? You have redundant MDCs and a desktop may be running something like software update. You want to know ASAP if your storage goes offline, since you’ve just lost part of your volume. So suppress the messages you don’t care about, i.e. use I/O Stream Guard on the ports connected to the Xserves and PowerMacs.

[MDhaliwal]

So, I’m guessing this NAS head is an Xserve?

The methodology for this would be, take an Xserve and make it into an Xsan client. You can make this into an Open Directory and then bind that into your existing AD. Mount the Xsan volume R/W and use WGM to set the permissions you’d like on the shares, just not using ACLs (IIRC that’s a no-no). Think of the Xsan volume as a big disk attached to your Xserve and proceed as you normally would, just be aware of the ACLs and that small files will probably bog down the SAN a bit.

As long as the AD integration is done right, your properly bound and the AD auth node is listed above the OD node, the Xserve should accept AD authentication for your shares. This really isn’t much different than a normal AD integration.

[MDhaliwal]

Cool post. Always nice to see people putting real world experiences to help out other folks. Its the only way to really learn!

So, yeah, a second MDC is really what you need. You can also use cvgather to grab up that Xsan config. It’ll tar it up nicely for you. This is exceptionally valuable when troubleshooting an Xsan deployment.

Qlogic is a very nice switch company to work with. I’ve always liked the 5200 for small to medium sized Xsan deployments as they include the 10Gb uplink, for stacking. This way, for smaller shops, your not blowing all of your allocated budget on a switch that you won’t fill for years to come.

Ideally, leave your OD installation on its own. If you don’t have the cash for extra Xserves, you can deploy and OD on the MDC. I usually suggest doing opposites. Take the secondary MDC and make it the ODM. Take the high priority MDC and make that the ODR. This way you have high availability to all services you need for the Xsan. As long as your not planning on plugging large amounts of users into that LDAP directory, you should be OK. Usually, the OD is just being used for Xsan users in this case.

Just my $0.02.

[MDhaliwal]

Yes, NetInfo running locally is pretty normal here.

Try using dscl to read out the LDAP user info from a user that works and a user that doesn’t work. Something could pop out if you compare the records.

[MDhaliwal]

Are you able to use dscl to read the LDAP info from your client? Any pertinent logs on the server or client?

[MDhaliwal]

Really depends on how you want this done. If you have helpers and you want them to be able to mimic you identically without the need to explain how to re-import different data, then imagaing the system isn’t a bad idea.

Personally, I had an OD Master blow up due to ‘circumstances’ when I wasn’t in. I had a help desk application running on that server as well. I used the third drive in the Xserve to install a fresh OS with the updates I wanted, copied my help desk database to a fresh install of the application, told the Xserve to be a replica of the newly promoted Master, promoted the Xserve back to master and demoted the former replica (now master) back to replica…I can draw stick figures to make this more clear!

Yeah, this is a few extra steps, but it saves you disk space on backing up extraneous files, but it was pretty quick and pain free. I guess the real question is, how long did it take for the Master to replicate to the OD Replica? If its a matter of minutes, then you should be set. My OD was running inside of an AD and didn’t have 400 records in it.

With all that said, grab the OD Backup script (if your not on 10.4.x) and make sure you have a proper copy of your OD to put on tape and store offsite, incase of a real disaster!

[MDhaliwal]

[QUOTE BY= tbone] The VXA finally died.[/QUOTE]

Wow, that was the feel good ending of the year, huh?

Though the hardware died, were you ever able to tell if it was Retrospect improperly using your hardware or just bad hardware?

[MDhaliwal]

It appears that this feature was left out of the bundled version in 10.4.0 Tiger. Not sure of anything else to use, that’d be considered ‘safe’, though I’ve had some fun just manually deleting out info I don’t want stored on my server any longer!

They could always include these features later….

[MDhaliwal]

I haven’t used either product in conjunction, but what does the folks at Dantz/EMC have to say about this?

Have you tried any other software solutions? If you experience similar symptoms on a different machine, with the same setup, or even better, with a different backup software piece, you can better evaluate which part is actually failing.

As I understand, Retrospect using a constant query of the hardware to keep its connection live to the tape device you have. In contrast, BRU only queries the device when it’s necessary to do so. If you ever tested BRU on that machine, these two opposite ways of handling hardware will battle each other.

You say that the tape device works without issue on a PowerMac G5, which is leading me to believe that its not a problem with your hardware, tape at least. Though OS X doesn’t have built in tape drivers, are you able to see the the device in the System Profiler when this issue occurs? I can see my FC tape library listed under SCSI on my backup server, so I would think you should be able to see yours under FireWire. If you can see it there, but not in Retrospect, it’s probably a Retrospect issue. Of course, if you can’t in either, it could simply be that Retrospect has locked up the device and it has gone offline, which I’ve seen happen with other solutions.

[MDhaliwal]

I was faced with a similar situation months ago. I was in the process of getting a new backup and disaster recovery plan designed, but needed a quick, reliable way to backup user data.

What’d I do? I grabbed a few 1TB LaCie FireWire 800 drives! Ok, so it won’t win any awards for being revolutionary, but using Carbon Copy Cloner to replicate user data over FireWire 800 was fast, convenient and easy to do. You can even schedule the jobs to run, giving you a nice level of automation, in case someone forgets to kick off the task, or such.

I was easily backing up 1TB of data overnight in my environment, without running into live hours.

Hope this helps!

[Author]

Posts