I think you actually mean OSI (the Open Systems Interconnect). I remember having to deal with that to get DECnet working across multiple networks, including X.25. Fun times trying to remember the correct NSAPs...

It's quite easy to use, comes with your laptop and provides good copy and paste between the equations that you are entering and other applications. The downside is that the library of functions isn't that complete since it's orientated towards actually producing graphs. As with everything, I guess it depends on what you are doing...

It can be found in /Applications/Utilities/Grapher.app.

This is basically how Time Machine works. Don't forget that the poster is using Final Cut, which means that he is using Mac hardware. Even though there is a Drobo in the backend, depending on how that is connected into the environment, a Time Machine backup will do exactly what you've laid out here. For online replication over distance, just use rsync over ssh, making sure that you preserve all the hard links. Mac OS X already has done the heavy lifting working out what needs to be saved, so you can just copy the backup volume.

Recovery off that volume couldn't be easier too. Just rebuild a server at the remote location and connect up the Time Machine remote backup and you then can just copy data off, knowing that you got the latest version of your environment at about roughly two hours before it got hosed. In fact, worst case would have to take into consideration the lag between the new data being written and copied over to the Time Machine volume (Time Machine runs every hour and I'm assuming about an hour for moving large new video files over to the backup volume), plus whatever the time taken is to copy the data across your pipe. I would make a SWAG at you being okay up to about two to three hours out of sync, although you really need to test the hell out of this setup to guarantee recovery.

Finally, you may want to consider archival copies of your data and purge from your main online repository. Once something has been broadcast, "freeze" it and dump it too a near or offline archive. For something that will be more user friendly, although more complex to setup, you should have something like everything broadcast for the past seven days "online", the past month on "near line" and the rest goes onto tape archived somewhere. Of course, depending on the volume of data, type of requests for older information, frequency of requests, etc you should change these values as appropriate.

This sounds like a fun project!

You've just described a large part of what I did at my last place of employment. My job title included a lot of nasty buzzwords to get HR to pay me a reasonable wage, but basically it entailed me designing large scale system and storage environments.

A lot of people wondered why myself and a colleague went to so many meetings. The reason was that periodically, there would be a meeting about a new business requirement which meant that, for example, we needed to perform 5 billion transactions a seconds and the system should never go down. After a (fairly short) series of meetings with the business and business analysts, a couple of development VMs, a production cluster and a DR system was purchased for a fraction of what they originally budgeted.

Basically the majority of my role was to trap this type of stupidity early enough in the cycle so that it wasn't a major political hurdle in getting things changed. Now that I left, I do actually wonder what kind of things are now getting approved...

-jax.

OpenVMS needed PAKs for the number of interactive users, networking (especially DECnet Phase IV/V routing), clustering, volume shadowing and probably a bunch of other stuff. These were not additional bits of software but included in the core OS. As an indication of how much DEC valued these components, the clustering code (CNXMAN) is NOT included with the source license, although DEC claimed patent issues.

For example, the cost for unlimited users and clustering (the MCOE stuff in modern, HP terms) was EXTREMELY expensive, so much so that not only was the software more expensive than the hardware in some cases, but resale value was almost zero without the original PAKs.

Enterprise features: if you can't afford them, you aren't doing something important enough to need it. That's how the University's got screwed back in the early 90's...