In short, I would say, that

• Apple opens up its pro software like FCP X and Mac OS X Server to the consumer, by making it easier to learn than ever before. A great strategy to sell more boxes and devices, which surely leads to greater turnover, and probably to more profit, too, as consumers buy easy tools and need support on a very low level only (if at all), which Apple can provide for cheap.
• Apple dumps all network products, which’s sole purpose was to help sell more client boxes to professionals in the enterprise or workgroup, like Xserves, Xserve RAIDS, Final Cut Server, and probably -on the long run- other products like Xsan metadata controllers and Mac OS X Server. In fact, I don’t think there is a big need for any of these products anymore, since Apple clients integrate just fine with Active Directory environments, most file servers, and many storage devices.
• I don’t think that this necessarily means Apple doesn’t care for the pros anymore. I think that FCP X is already quite powerful, and multicam support, FCP X APIs/XML interfaces, SDI connectivity and the like are going to be added to FCP sooner or later. Yet, I think Apple’s main market for FCP X is the single user or small workgroup. If you look at FCP X’s media import options, you’ll see the option “Create proxy media”: If you also look at the Sharing options: you’ll see that FCP X includes an option to export files and probably metadata to CNN iReport. I bet that FCP X’s powerful metadata management capabilities and the option to generate proxies during media import, are a very good basis to add iCloud support to FCP X. I guess that for many very small workgroups it would be great to simply send a proxy version of a project to the iCloud, so that another team member can edit a sequence and send it back to the original FCP X machine which has access to hires files to render the final output. This might be a very good Final Cut Server replacement for very small teams.

Making tools like FCP simpler than before doesn’t necessarily mean, that it’s not suited for pros anymore. Okay, right now it is not, but I am sure, it will soon be.

Yes, Apple has dumped Final Cut Server, which is the base for many postpro environments, now. But FCSvr meant to most of its customers, that you needed Xsan in place (most resellers and consultants were simply not able to design these systems right), that Open or Active Directory needed to work fine and that your Mac and Windows clients needed to be integrated into this directory infrastructure (and again, most service providers could not do these things properly).

This means it was very difficult to get a Final Cut Server infrastructure working, especially as so few people know how to make storage, asset management, Open or Active Directory, filesystem permissions, portable home directories and video editing clients work together smoothly.

In my opinion for many small shops it would be a great step to cut out all this overhead and move FCSvr into the cloud by adding an option to FCP X.

On the other hand, FCSvr leaves a big gap in the market, which tools like CatDV might fill: many shops do not want to publish their data into the cloud.
Especially in Europe people don’t like to store their business data on servers hosted either in the US or anywhere else by a US company, which might sooner or later grant access to these data to any kind of secret service.
This leaves a need for a local DAM in enterprise environments.

Personally, I would like to have a much easier DAM tool than anything on the market, something that can be set up without needing a consultant, at least for small environments. For bigger environments, I would say that if you work with FCSvr, you will be able to keep your current infrastructure and just replace either the FCSvr server software or probably the whole FCSvr machine to get something else up and running.

As FCSvr is so open, it is totally easy to export media and metadata to any other system.

I had a look at the new FCP X project files and the way FCP X stores files on a central storage. Even without the Apple API I think that there is a way to extract data easily and build them into your own asset management.

Being a consultant, my approach to Apple’s latest announcements is this:

• I recommend people to use Windows servers for directory management.
• Don’t know if Xsan will really be free in Lion. Still Xsan is a great tool, but I might recommend people to use StorNext metadata controllers at least if people need rack-mountable hardware.
• Apple builds wonderful standalone machines, which can be integrated into enterprise environments. In fact, now that Apple focuses on its core business – building great machines which are easy to use – and doesn’t care much about the enterprise network stuff around it, there’s more money in the game for third party developers who build DAM systems. I bet we’ll see great third party solutions soon and overall Apple kit will better fit into enterprise environments than today.

I feel that Apple’s approach on the pro market might leave us all with better tools in the end.
Let’s see.

Here’s the presentation:

Since Apple has discontinued the Apple Xserve in January 2011, there seems to be a growing need for rack mountable server hardware in the Apple world, which is more powerful than the Mac mini Server and takes less rack space and consumes less power than the Mac Pro.

If you want to run file services, directory services, software update services, and other services for Macs, Windows, and Linux clients, you’ll find both Linux and Windows based solutions to do just that. On the other hand, the Mac Pro and the Mac mini Server seem to be great systems to serve many of these things, too.

Yet, if you read the announcement of ActiveSAN, it seems as if there was a high demand for a 1U rack mountable metadata controller for Xsan environments.
What the guys at ActiveStorage seem to do is build great server hardware incl. nice monitoring and setup tools, which make it easy to set up a Quantum StorNext metadata controller to handle your Mac-based Xsan clients.

If you are an Xsan or StorNext pro anyway and work in the command line most of the day, you can even replace your existing Apple Xserve MDC with a Linux-based StorNext MDC with a minimal downtime of your Xsan volume. This is what you need:

• Server hardware which is able to run a recent Linux version. Make sure you add enough RAM, redundant drives for the boot disk, a nice and OS supported FC card, dual Gigabit Ethernet. Note: You can also use a Windows OS instead, which is nice if you integrate with Active Directory, but whatever you do, make sure, the OS of choice supports the LUN size you use in your Xsan setup. The ActiveSAN hardware looks like a very nice solution to this.
• I would go for CentOS as the MDC’s OS, as it’s officially supported by Quantum and doesn’t cost you money. If you need support, I would go for RedHat. See http://downloads.quantum.com/SNMS/4.1/StorNext%204.1%20Supported%20Platforms_V2.pdf for a list of supported MDC platforms.
• Make sure to integrate your MDC into your directory environment. Both Active Directory and Open Directory are supported. You will need this to use ACLs (the only way to properly deal with permissions in most Xsan environments).

Before you start buying the hardware to build the new MDC, you need to make sure, that you don’t have named streams enabled in your existing Xsan environment.

To actually migrate the volume from the Xsan MDC to the SNFS MDC, roughly follow these steps:

• Make sure to use matching filesystem versions in the Xsan environment and on your StorNext controllers.
• Run cvfsck -w on the Xsan volumes.
• On the primary Xsan metadata controller, save the folder /Library/Filesystems/Xsan/config to a place we can access easily later on, like a USB stick, e.g.
• Shut down the Xsan metadata controllers.
• Set up the StorNext controllers. The easiest way is to use the same IP addresses as for the Xsan metadata controllers.
• After installing the StorNext filesystem and -optionally- the Storage Manager, copy our Xsan volume’s config file into the StorNext controller’s config folder.
• Open the config file and delete the lines with the options “NamedStreams”, “EnableSpotlight”, and “SpotlightSearchLevel”.
• Optionally, make the volume managed by adding the appropriate option to its config file.
• Make sure to run chown www:adic on the config file as well as chmod 664
• Run cvfsck on the volume.
• Start the volume and mount it.
• You are done.

If you want to add Xsan clients to your StorNext controller, you find a nice article at http://krypted.com/xsan/adding-xsan-clients-to-stornext-environments/.

While this migration is something that can be done very easily, you need to consider, that StorNext currently doesn’t support Spotlight searches, so you can’t easily use the Finder to search for content. If your users navigate through the filesystem or use a DAM like Final Cut Server, this is not an issue at all. (On the other hand, the StorNext MDC catches all filesystem events, so I guess it should be possible to write a client, which collects these events and tells a dedicated Mac machine to add new files to the filesystem’s central Spotlight DB).

Another caveat is that the automatic HSM process in Storage Manager, which moves data to tape and restores them to disk as needed, restores data whenever a file gets invoked by a client. You either need to turn off previews in Finder to prevent constant restores, or you better hide the filesystem from the Finder and let your users access the filesystem through FCSvr and its edit-in-place option only.

One of the best things that come with the migration from Xsan to StorNext is that you can add additional functions (part of SNFS and/or SNSM) like filesystem replication, Distributed Data Mover, HSM functionality, writing to tape, etc.

In addition, SNFS has documented optimization settings for image sequences, which is very interesting for film production.

On the other hand, if you already own an Xserve which runs your Xsan, I would say that this is a great hardware to do just that.

Although I have done the migration described here in the lab, and found it reasonably easy, I am curious to see ActiveSAN as soon as it’s there, because it looks like they made the process of building a new Xsan/StorNext environment so much easier.

This version includes the following changes:

• Better handling of files with file names including double spaces (thanks for the hint, Matt Geller)
• Automatically deals with non default PresSTORE Archive Indices (thanks to Lars Petter Ommundsen at Video 4)
• Better config tool handling
• updated manual to reflect fsevents support of PresSTORE 4

You can pick it up at http://www.andre-aulich.de/en/perm/connecting-final-cut-server-to-archiware-presstore.

I thought about adding these features, too:

• Preventing duplicates in the archive
• Writing tape ID back into an asset’s metadata in FCSvr
• Automatic creation of temporary Archive folder, responses, and metadata fields in FCSvr during config process

Yet, right now I think that these features need to be customized for each installation, so I decided not to add it to a standard tool like fiprecon.

If you need one of these features, please feel free to get in touch with me.

The demo will include metadata exchange between FCSvr and other DAMs, complex automations, and fsevents based data protection using Archiware PresSTORE.

Please register for free at http://www.archiware.com/index.php?hp=632 where you also find more information about the event itself.

Looking forward to seeing you there!

In this article I will explain how Xsan 2.2.x’s fsevents feature in conjunction with Archiware PresSTORE’s 4.x Synchronize module can help you creating a secure copy of your data during normal business hours without interrupting your real-time I/O operations.

A. The challenge

Why is it that so many people don’t create copies of their online data?

1. To copy a large volume’s data to tape or disk, you need to spend money for the backup device, and nowadays most production environments need to be as cost-effective as possible. So it’s tempting not to spend money for a backup, which in an ideal world you are never going to use anyway.
2. If the primary online volume fails, most people need to be able to work on the backup as soon as possible, probably even without much or any interruption. That’s why you usually need to have a copy of your online data on a second disk set in exactly the same form like on the primary volume. Using a proprietary backup format on the secondary disk set wouldn’t help you much in disaster scenarios, because you would need to restore your data before you could actually use them. If you consider, that after some time you don’t need instant access to project data anymore, this leads to a typical three tier setup as a minimum environment: primary online volume, secondary online volume, tape archive (with data which can be removed from the disk sets). This setup can be complex and expensive.
3. If you are willing to spend the money for a primary and secondary disk volume, as well as for a tape library, you need to make sure that the copy on your secondary disk set is as recent as possible. With very large volumes, scanning the volume for file changes takes a reasonable amount of time (like a couple of hours) which you probably don’t have very often, probably even not at the weekend. In addition, this scanning process can put so much load on your storage system, that you can’t scan your volumes during normal business operations without interrupting your real-time I/O. So with large volumes and constantly changing files, in many environments you would simply not find a backup window to create regular copies of your data.

Regarding point 1 I’d like to say that yes, in an ideal world you would never need to restore data from your backup. In the real world I’d say, that you would only not need your backup if you have a very good backup strategy. As soon as you don’t set up your backup, you would probably need it. I haven’t seen a single system without some kind of backup, versioning, etc. where people haven’t lost data sooner or later, no matter if it was by accidentally deleting files, file system corruption, or hardware issues with or without power failures.
Ah, and did I mention that you absolutely need a UPS for your whole storage system?

So whatever you do, you need a copy of your data. Some people argue that they still have their footage on tape, Professional disk, P2 media, etc. But what happens with your Photoshop files, FCP project files, Word documents, etc? And how long would it take to re-ingest/-transfer your footage to your storage system?
And what about metadata? If you use an asset management system like Final Cut Server, you need to relink your reingested material to the metadata available in your asset management’s database only. Not so easy, especially if you are in a hurry.
I treat the copy of my XDCAM, P2, etc. files as the new originals, as in most environments the original media (I mean e.g. the Professional disk) would simply not be stored forever, or at least not in an environment, which would guarantee media availability after some years.

So I would simply never recommend to design a production system which doesn’t include any kind of backup.

How you deal with point 2 depends on your environment. If you never work on time-critical projects, you might backup your data from your online volume directly to tape. Depending on your tape library, this can be as fast as copying files over to a second storage system.
If in a disaster scenario you think you would still have enough time to restore your data before you continue working on them, that’s a good approach.
Yet, you still need to scan your online volume for file changes, and you would probably not do that during normal business operation as this might interrupt your real-time I/O.
So not having a second disk based volume would only work in environments which either have not many data on their primary volume (so scanning the filesystem for file changes would be superfast), or they don’t need recent backups and are fine if they only create a nightly backup. But even then you need to make sure that your backup window is large enough, so that you can scan your whole volume and copy the file changes to tape.

If your budget allows for it, you should try to get (at least) a setup like this one:

B. Concepts

Let’s have a look at some concepts, which are going to help us implement the 3 tier setup shown in the picture above.

1. Secondary Online Disk

In point A.2. I said, that you would probably need to design a 3 tier storage environment, with primary online storage, secondary online storage, and tape based archive.
As the secondary online storage is supposed to be a most recent copy of the primary online storage, this raises the question how to mirror the two volumes.

The first thing that comes to my mind is using a block level hardware solution like e.g. Cloverleaf’s iSN. I’ve used it in a 24/7 broadcast environment and was not unhappy with it, but what happens if the file system breaks? This would affect both the primary and the secondary volume. To avoid this you could use snapshots, which are supported by iSN, but the whole thing gets really complex at some stage, and I’d like to keep things as simple as possible.

So I’d prefer to have two independent file systems and make sure, that I only copy files from one file system to the other. If one system breaks, I could then simply repair/recreate it and copy my data onto it.

What happens if the primary volume really fails? How do I access the second volume?

Let’s say your volumes are called XsanVolume1 and XsanVolume2. They share the same size.
If XsanVolume1 is mounted on all your servers and your clients, XsanVolume2 needs to be mounted on your backup/synchronize machine at least, because at least one machine needs access to both volumes to copy data from volume 1 to volume 2.
In case XsanVolume1 fails, you would use Xsan Admin to unmount XsanVolume1 from all servers and clients, mount XsanVolume2 on all servers and clients, and then e.g. use Remote Desktop or something alike to create a symlink on all machines from /Volumes/XsanVolume2 to /Volumes/XsanVolume1.
Test this with your specific applications before you try this in a disaster scenario, but this will work with most apps.

You could of course fully automate this, but I would recommend to prepare the tools for a manual failover. This way you would be able to first investigate the reason for the failure.

2. Filesystem Scan vs. Filesystem Events

The functionality that we need to create a copy of our primary volume on the secondary volume is a synchronization function. If we use PresSTORE, we can still decide to support versioning like in a backup, and this would not prevent us from working on the secondary volume directly if we needed to. But right now we just need a way to synchronize our two volumes.

As I said, scanning our primary volume for file changes since the last synchronization puts a reasonable amount of load on our system and would probably interrupt real-time I/O like ingest and playout, so a full scan of our volume should only happen at night, at the weekend, or whenever we find the time to do so. A full scan can easily take a couple of hours, depending on the number of files on your file system.

The solution to this sounds very easy: let’s use filesystem events instead. This means, that each time a file in our filesystem gets created, deleted, or modified, this event will be written into a database. When my next synchronization starts, it just reads the database and copies the modified data to volume 2.
No scanning necessary, and instead of let’s say 5 hours of scanning, the process takes a couple of seconds only.
Wow!

Since version 2.2 Xsan supports filesystem events. Apple doesn’t really tell you about it directly, but you can extract it from their knowledge base articles if you understand, that Spotlight uses filesystem events as its foundation.
In Xsan environments, every file modification will trigger a filesystem event on the machine which writes the file (if it’s a Mac) as well as on the active metadata controller. The only machine which catches all filesystem events on your Xsan volume is the currently active metadata controller.

3. How PresSTORE Synchronize 4.x uses Xsan 2.2.x Filesystem Events

Even PresSTORE 3.x supports filesystem events, so why do I need PresSTORE4.x? In version 3, the filesystem event needed to happen on the machine on which PresSTORE was running. So with PresSTORE 3 you would need to run your synchronization software on the currently active metadata controller to copy data from volume 1 to volume 2.
The data copy processes would put so much load on your MDC, that its latency during metadata access would increase until your clients might loose frames during ingest or playout.
The idea in version 4 is to run the Synchronize module on a normal client system and have a little tool running on the MDC, which does nothing but collecting all the filesystem events of your active Xsan volumes.
Whenever your Sync process starts on the PresSTORE machine, it will simply copy the minimal information from the MDC, check if it needs to move some data, and then do the dirty work without impacting the load of the active MDC.
You can say, that PresSTORE 3′s fsevents implementation was supposed to support local HFS+ volumes only, while version 4 now supports fsevents in Xsan environments, too.

How does it look like?
You just install the PresSTORE client software on your MDCs (remember that you need a valid license for each of them), then you set up a synchronize plan which syncs XsanVolume1 to XsanVolume2.
In the “Synchronize Options” section of the sync plan you now find the option to set up an fsevents server, which in Xsan environments has to be the currently active MDC:

In case your primary MDC goes down, just select the secondary MDC as fsevents server for your sync plan.

4. Apple’s Implementation of Filesystem Events in Xsan 2.2 (in my understanding) and how to deal with it

There’s the File System Events Programming Guide available on the Apple website, which describes the general fsevents mechanisms Apple uses in HFS+ and Xsan 2.2.
At this stage you might think that with fsevents support, PresSTORE would simply get a list of files which have changed and would then work through it.
That would be great. If you work in the fsevents team at Apple and read this article, please add this feature – that would be so awesome.

Anyway. What really happens if the Apple fsevents programming guide applies to the Xsan world, too, is this:

• Instead of receiving an event, that a file has changed, you get an event, that something within a folder has changed. So your application (like PresSTORE), still needs to scan this folder for file changes. In video environments this could be a folder with an image sequence (150.000 files?, no problem, that’s just 40 minutes made of 60 frames per second), so scanning all these files would take some time. If you work with Final Cut Server, most of the assets will be stored on the root level of one folder, so you also end up with many files in one folder. Each time you upload a txt file into Final Cut Server, you get an fsevent, that you need to scan the whole FCSvr Library. You can structure your Final Cut Server environment to better work with this fsevents strategy, but you can’t rely on FCSvr’s default settings. Be aware of this when you design your Xsan’s folder structure.
• When you have too many fsevents at the same time or within a short time frame, the fsevents mechanism can merge these events and point your application to the common point of the events in the folder hierarchy. In the worst case this can mean that the fsevent says “Scan your whole Xsan volume”. Your app could then still ignore the whole event, but hey, you’d like to protect your data, wouldn’t you?
• All applications which register for fsevents share the same buffer. The first application to work on the fsevents list is Spotlight, which seems to deal with it pretty well. If you use other fsevents application, they might slow down the process so much, that new events don’t fit into the buffer anymore. This means, you will not catch all the events, which again means, that a part of your data would not be protected. Yet, you should not run any software on the MDC anyway, so chances are very, very high, that you never run into this problem.

The main message here is that in very rare situations it might happen that the fsevents mechanism doesn’t catch all the file operations on your Xsan volume, so at least from time to time you would still need a full scan of your volume.
I would recommend to use fsevents for your Synchronize module during the day and during normal business operation, and then use full scans as often as possible. If this is once a week, I would feel secure.

C. To Do

While Archiware’s implementation of fsevents support in Xsan environments is simply great, the current version doesn’t automatically deal with Xsan Metadata Controller failover. The perfect solution would be if for any Xsan volume you could enter multiple MDCs as fsevents source in a PresSTORE Synchronize plan, and then PresSTORE would automatically detect which one is the currently active server. If you don’t have a split-brain problem with one of your volumes (or run software on one of the MDCs which writes data to your Xsan volume), there will always be a single MDC serving your fsevents, so this is something which would greatly improve the software.
If you think that you really need automatic failover detection in PresSTORE 4, please go ahead and file a feature request at Archiware.

Many of us would like to use Final Cut Server (FCSvr) as an archive solution to write high res media files to tape (or disks).
By default, FCSvr can write archives onto various file systems, but it can’t directly access tape drives.

Now download my little middleware tool fiprecon to connect Final Cut Server to Archiware PresSTORE in a way which can look like this:

Make sure to install fiprecon on your Final Cut Server system. The PresSTORE server can be a separate machine which fiprecon controls over the network, but fiprecon supports running FCSvr and PresSTORE on the same machine, too.

After the installation, run the config tool using

sudo /usr/local/fiprecon/bin/config.command

and enter the paths /usr/local/fiprecon/bin/postarchive.command and /usr/local/fiprecon/bin/prerestore.command as postarchive and prerestore script paths of your archive volume in FCSvr.

I recommend to set the retry count in FCSvr to 10 and the timeout setting to 300 seconds.

I wrote a detailed documentation about “Backup and Archive setups with Final Cut Server, Xsan, and PresSTORE”, which can be downloaded here and describes fiprecon in detail.

It also explains these topics:

• Archiving FCSvr assets on tape.
• Automatic archiving after x days
• Automatic archiving right after asset creation (great for moving video tape based archives into the digital world)

Please feel free to use both the tools and the documentation – they come for free.
If you need any customization, or any other kind of Final Cut Server consulting, please get in touch with me.

Looking forward for your feedback!

Besides other topics the presentation deals with

• Rough Cut Editing
• FCSvr CLI
• XML and data exchange with other MAMs
• Automatic fetching of news feeds incl. XML metadata
• Working with growing clips
• Automatic XDCAM ingest
• FCSvr Archiving to tape

The presentation contains a great deal of demo parts, so not every topic will be explained in detail in the linked PDF file.

If you got any questions regarding the topics dealt with in the presentation, or if you’d like to hire me for one of these things, please use my feedback form to get in touch with me.

One of the best ways to backup and/or archive your video data, is by using Quantum’s StorNext filesystem in conjunction with their StorNext Storage Manager.

StorNext is compatible with Apple’s Xsan filesystem, and it’s very easy to replace your existing Apple Xsan metadata controllers with Linux-based StorNext metadata controllers, which is a prerequisite if you want to implement Quantum’s StorNext Storage Manager.

What’s so special about the Storage Manager, though?

If you create files on your filesystem, there’s three ways for your backup and archive software to find out, that there are new files which need to be copied to a second storage device:

• The backup software can scan the filesystem for modified or freshly created files. This puts a reasonable amount of load on your storage, so this is an approach for environments with long backup windows. During real-time operations you usually don’t want to scan your central storage.
• The application, which writes a file, needs to inform the backup solution, that it has to back up a file. While this works between Final Cut Server and Archiware PressSTORE, e.g., this depends on the operability between your application and your backup/archive solution.
• The filesystem can send a filesystem event to your backup/archive app. This way your backup app doesn’t need to scan your whole filesystem and can write your data in a very efficient way.

Archiware PresSTORE supports filesystem events with HFS+ and Xsan 2.x volumes, so PresSTORE would be one way to back up your data without the need to scan your Xsan volumes for changed files.

Another way of doing this is the StorNext Storage Manager. The Storage Manager integrates with the StorNext filesystem, and can send freshly created or modified files to the backup and/or archive without scanning your central SAN volume.

In version 3.5.1 the Storage Manager runs on the active metadata controller, which under certain circumstances might cause so much load, that filesystem latency exceeds the critical limit for real-time operations. To deal with this, you can either schedule Storage Manager activity to run at uncritical times, or you use the brand-new StorNext Data Mover (part of StorNext 4.0), which means, that your primary MDC works as a MDC only, and a dedicated client machine actually moves files into the archive to keep your primary MDC responsive, even if there’s lots of Storage Manager activity going on.

Another great thing which comes with StorNext 4.0 is deduplication. Deduplication allows your filesystem to use less disk or tape space when it stores your data. If StorNext sees that a data block in a new file is the same like a data block in a file which is already part of the archive, then it doesn’t store that data block again, but instead creates a reference from the new file to the existing data block.
This is great for archive volumes, yet, on your primary (online) storage, this slows things down a bit, so you might want to turn on deduplication for your archive only, if you work in real-time environments.

If everything is set up properly using StorNext file system and Storage Manager, it allows you to work on your central storage without the necessity for backup/archive windows.

If you need help planning or implementing a StorNext based solution, please feel free to get in touch with me.

While this is quite easy, I’ve got some customers who want to replace their existing Apple Xserve RAIDs with 4Gb, redundant-controllers PROMISE RAIDs at the same time.

I choose the following way to do the whole thing:

• Upgrade your existing Xsan environment to the latest Mac OS X 10.4.x/ Mac OS X Server 10.4.x version and upgrade to Xsan 1.4.2.
• Do a quick cvfsck on your volume, if necessary invoke cvfsck -w.
• Now rename /Library/Filesystems/Xsan/config/XsanVolumeName.cfg to /Library/Filesystems/Xsan/config/XsanVolumeNameOld.cfg.
• In /Library/Filesystems/Xsan/config/fsmlist change XsanVolumeName to XsanVolumeNameOld.
• Fix the ICB mismatch by invoking cvfsk -w in interactive mode. This and the above two steps are explained at Xsanity.
• Now copy the MDC’s directory /Library/Filesystems/Xsan/config/ to an external device.
• Install Leopard on the MDC, upgrade it to the latest version, and install Xsan 1.4.2 on it, too. Enter a valid Xsan serial number in Xsan Admin (Xsan 2 license works with Xsan 1.4.2, too).
• Mount the existing volume to see if it still works. Now unmount it, stop the volume, and install Xsan 2.
• If you open Xsan Admin the Xsan Assistant starts up and asks you for some self-explaining data. After that your volume can be mounted again. Try if it still works and then deactivate and stop the volume again.
• Again, cfsck the volume.
• Now you can set up your new device, mount it using your old device’s original volume name and copy the data over to the new storage.
• After you copied the data to the new device, delete the old Xsan volume and remove it physically.
• Now install Leopard on all FC connected machines as well as Xsan 2 and integrate them with you new Xsan volume.

Hope this helps.

USE AT YOUR OWN RISK !!

]]> http://www.andre-aulich.de/en/perm/how-to-update-a-104xsan-142-mdc-to-105xsan-2-and-replace-the-raid-hardware-at-the-same-time/feed 0