and welcome. Thank you for joining us today. I think you're going to find this a very useful session especially in your market where you need to do backups. My name is Chris Bledsoe. I'm the Senior Enterprise Alliance Manager and I manage all of our backup vendors here for Apple Computer. So let's get going.

Have you ever had this happen to you? Back in 1996, I worked for Oracle and we had this product that was called Oracle Card. Does anyone remember Oracle Card? Alright, well anyway, I was building this presentation on this Mac so I could go do a show similar to this. And as I went to the show, late night, you know, you're doing your coding work, you're getting your demo set up, Boom, my hard drive crashed.

Like 3 in the morning, you know, on a Thursday night, you're like, great. So, literally for the next 8 hours, I had to recreate all the material that I had. And sure enough, I didn't have a backup. So, for me, as an individual for doing a presentation, 8 hours was difficult enough. But in enterprise, it's absolutely critical. That kind of time for an enterprise can easily represent millions of dollars of cost to you and your enterprise and your business. That's why it's absolutely critical that you have backup.

So, some of the things we're going to talk about today, some of the backup trends that we're seeing occurring in the market today. Everything from regulation compliance to the types of backup windows that we run into. Also, what I'd like to talk about is our backup market segments.

What we did is we kind of looked at the whole market and said, okay, what type of backup needs do our customers for Apple really need? And I'll talk in more detail about whether it's an individual system, a laptop, a Power Mac, a Power Book, all the way scaling up to large SAN type deployments like with our XN product line.

So, the goal of this session is so that when you get done, you'll have an idea of, okay, what kind of backup solution can I use? Because there's a number of vendors out there available for you, as well as find out what solutions work on the platform today.

So before I dig into all of the backup material, I'd like to cover a few terms first. The first one is Fibre Channel. Fibre Channel is a technology for transmitting data from your computer service across your network. So it's a communication capability. It's really great for Fibre Channel when you have like storage devices that are hooked up to the network.

Which kind of leads me to the next idea which is called RAID. Redundant Array of Inexpensive Disks. Or sometimes they're called independent disks as it says on the screen. The idea with the RAID is that instead of having a single disk, which has all of your data and it could fail, you set up an array or a number of those disks. And typically you want to do that for a couple reasons. First of all, you want to do it so you can get performance.

So instead of reading from a single disk, you can read across a set of disks and be able to access that information very quickly. Also you want to do it for fault tolerance. So in case a disk goes down, you either have replications of that data on the other disk so you can get access to it. We're not going to really drill down into the RAID today, like the different RAID levels. We have a great session on XSERV deployment and for RAID, XSERV RAID deployment that you should definitely be checking out and we talk a great deal about that.

Also, there's this concept of network attached storage. Right, so what you do here is instead of taking your hard drive storage like a RAID server and attaching it to your departmental server, what you do is you break it away and give it its own independent network address. The advantage then is that your applications that are running on the server don't have to compete on the processor with your disk access. So by separating and putting your data on the network, it makes it much more efficient for your server to get access to the information and still have access to this data in a very fast and efficient way.

Which leads on to- so you've got this network attached to storage area networks. This is a network that oftentimes is based on fiber channel, but it can be based on other technologies, where you have multiple disks that are on your network talking to multiple servers that are also on this high-speed interconnect technology.

Which- so that's what a SAN is. Now, that leads to what's called HSM, Hierarchical Storage Management. What that does is it says, "Okay, now I've got these disks on my network, how do I manage the migration of that data from one disk set to the other?" And that's what HSM tries to address is, "Okay, how do I manage it?"

Which leads to the last term, ILM, Information Lifecycle Management. And that's managing the whole stack from birth of the data when it's created to its obsolescence, when you no longer need it and you can actually safely delete it and move on. So those- just want to make sure you understand some of the terminology that we'll be covering today in our presentation.

Storage requirements. Did anyone here have stock in a WorldCom?

It takes a long time to backup a terabyte. So even if you're doing like disk to disk, and I pulled some of my good backup vendors here, you're typically looking anywhere from two to four hours, depending on what kind of throughput you can actually push through your fiber channel network.

So that's just to backup a terabyte. So you can imagine as you're working in high video demand type environments, the need to be able to shrink that backup window and be able to address it effectively so you can still get access to the data you need and safely archive it.

And the other thing that you've seen to happen, especially in large enterprises, is that each administrator for that server becomes their backup person. So you end up having a lot of administrators backing up their own servers. So if those administrators are heterogeneous in nature, you know, Apple, Linux, etc. Then what they end up doing is they have to be specialized on their own specific server.

Which kind of led up to this idea of backup clients. And this is probably the most popular and most well-known. So the idea here is that you take your backup client and you have a backup server. The server talks to the client and says, "Okay, today is Wednesday at noon. It's time to take all your data and put it on the tape library." So it's a nice, very easy, disk-to-tape type of backup scenario.

This is great if you have a ton of different operating systems in your network. All of my vendors here have client for not only on our platform but also across all the different permutations. I've talked to some that have up to 60 different operating systems where they have client backups so that they can actually get access to their clients and back it up to the server. So, generally you have good performance, right? Depends. It depends on how fast your actual network is that your backup server is connected to your backup client. That really defines it.

And it's very easy to add new platforms, right? Because all you've got to do is you call up your vendor, you go, "Hey, I added XYZ box. I need to get a client for that." They put it on there and it works within your existing infrastructure. That's why it's so popular. But there's some problems, right? For example, if you have a large backup and restore or a large backup window like we saw on that earlier slide for backing up just a terabyte, it's a little hard to get it timed up right.

Typically what you want to do is this thing called multiplexing where you're writing to multiple tape libraries at the same time because you're trying to backup many people in a similar timeframe like overnight. and it really doesn't solve the problem of these large backup windows. If you're backing up with say five terabytes a night, it's kind of hard to do that with just tape backup.

Which led to the evolution of what's called disk-to-disk-to-tape, which probably a lot of you have heard about. Very straightforward concept. So what you do is you take your backup client and you back it directly to disk. Very quick, very efficient, using the maximum bandwidth there. And usually you do that on a more periodic basis.

And then as your data gets old, you know like an ILM type technology, you're going, "Okay, I no longer need to keep this on my disk because I've had it backed up for a month. I'm probably not going to look at that data. Why don't I just go ahead and archive it?" And archiving is definitely very important.

Because when you archive it, that's when you usually take it off-site, right? So that way if there's a fire or there's some other kind of physical danger thing that happens to your data, you've got off-site storage and you can get access to it. So that's typically what you do. This disk-to-disk-to-tape.

What's really, really good about this is you get this centralized administration. Right? You don't have the problem where you have a bunch of different administrators managing a bunch of different servers. You generally can reduce the number of administrators you have focus exclusively on backup. It also gives you easy access to this critical data.

So for example, if you're doing a backup every day or every hour or every half a day, right, you can get access to the data that, you know, you actually need to go on a file, I need to go get that information, I gotta put it back on. You know, you're able to do that pretty easily. It also takes advantage of the great throughput you can get to your disk. Right? So now you're getting disk to disk, you're taking advantage of it. You're not being slowed down by doing your archival backup.

and then you migrate the data, right, as it gets less expensive media. So instead of sending it on your drive, you can actually put it up onto your tape. There's some challenges obviously with that, right? So the more moving parts you have, the more complex it becomes, which makes it a little bit more of an expensive solution. And because of all those things, it tends to create a little bit more overhead, although you have fewer administrators, you have a little bit more overhead in managing that.

So that kind of led to the next thing that we see a lot of is what's called land free. And this is important. The problem you'll see with disk to disk to tape is that you're doing this transfer of data over your network. Well, you can create these conflicts, right? So if it's the same network, you're doing normal network activity, then you're also throwing all your data across it for backup, you kind of create these problems. That's why you see things like land free.

So in this example, using something like an XSAN solution, you see that we map the drive on your XSERV RAID to an XSERV. All right, so it's now mapped as a regular drive. Your clients hit the XSAN. You let that server access it just like they normally would. Then when it does a backup, it goes through the network. So you never touch--that's why it's called land free. You never push the data through the LAN. You're always pushing it directly from the server within your fiber channel fabric.

Great. Very, very fast and the most efficient. Right? Because you're able to take advantage of this really nice, dedicated, high bandwidth communication to get your data to the appropriate area. You get the advantages of central administration and it's a great use of your backup resources, right? So now you're using your fastest network for your data and the most efficient. Very similar to the other one, it's a little bit more complex, a little bit more expensive and more overhead in your administration. But it's a trade-off, right? Because you get that better performance for your data.

So as you see here, we have a whole slew of backup vendors. And some of the obviously recognizable ones like Legato, Veritas, but even great people like BakBonne, CA, Quintex, Tollis Group, Danz, Atempo, Archerware, Avail, all the different vendors that we've worked with. So what I do here in this next slide is kind of give you an idea of the different types of solutions that are available.

So for example, everybody's got clients, right? And we have a lot of vendors who are now- they see the light. They get it. They go, "Okay, great. Apple has a lot of storage. We need to have more server solutions available on the market." So that's why you see a whole slew of guys over here doing betas.

But today, if you needed to buy, we basically have three vendors that have a production solution available today. Danz, Tollis, and SGO. So I wanted to kind of give you an overview of here's the different types of architectures. Here's why we got to be able to back up our data and why it's critical.

So now what I'd like to do is introduce a few of the guest speakers that I brought. When we looked at the market, we kind of broke it down into three basic groups. We got one end where your cost is the lowest and your complexity is the easiest. It's an individual workstation, right? This is your laptop, this is your desktop. You know, the need to backup your own individual one.

And then as it becomes a little bit more expensive and more complexity, you access the small work group. These are typically departmental level or small group levels. It's like what we do in my own organization. I have my own little server. It backs up about five or six of us. And, you know, it's that work group server solution. But then you need this capability at the really high end for corporate.

If you're backing up terabytes of data and you've got much information across different areas all over the network, that's when you need it. Which leads me to my first person I'd like to bring up from Dantz. Retrospect. And I'd like to introduce... Pat Lee. Hi Pat, welcome. Thanks. Thanks very much, Chris. Appreciate it. Thank you.

So Dantz was founded in 1984. We started out in the Macintosh and we shipped our first Macintosh backup product in 1985. It was actually for an iOmega product called the Bernoulli Box, if anybody can remember back that far. We've been in the backup and restore industry for 20 years.

We have two key US patented technologies, one of which I will talk about later and more in depth. And we've been working closely with Apple for many years. We've initiated a number of server backup programs with them and a number of Apple Firsts. Over 3 million computers worldwide have purchased licenses of Retrospect protecting their data today.

and we partner with many leading hardware vendors. For example, I mentioned iOmega earlier back in 1985. We're now partnering with them today as they announced their RebDrive, their new low-end tape replacement. One of our products is bundled with it. And we are also bundled, for example, with the new Exabyte VXA2 FireWire library, which if you haven't seen yet, you've wanted an easy connect solution, go take a look at it. FireWire Interconnect, perfect solution for your XServe today. And we have a product line that ranges from small home offices of a couple users to large departments of a couple hundred users.

The one thing we focused on is making sure this is an easy to use product. Most people aren't backup administrators that are dealing with this. They want something they can install and get up and running within a few minutes. Most customers can install Retrospect, start their first backup, and start protecting their data within five minutes of install. We think that's very important in this market.

But on top of being easy to use, it's also flexible. We support a wide variety of backup mediums. We support tape, which has been the most popular backup media to date for small and medium business. And we support it whether it's connected via Firewire, SCSI, Fiber Channel, you name it.

We also support hard disk backup, which is very key for either low-end or even high-end customers. And for customers who need off-site backup needs, we also offer FTP backup. We have backup clients that support Macintoshes, whether they start in System 7 Max, running PowerPCs still all the way up through the latest Panther clients, Linux clients, or Windows clients.

One of the things that we focus on is intelligence. We understand storage. You shouldn't have to understand all the complications. We should handle this for you. One of the things we have is called progressive incremental backup. And what that does is it allows you to say, "I just want you to backup this set of computers." And I'm going to say, "Do this progressive backup." The first time Retrospect backs up, it automatically backs up everything.

The next time it only backs up the new or changed files, sends the last backup to a particular set of media. And the reason a particular set of media is important is that you want to have more than one set of backup media. If you're relying on one set of backup media to protect your business and it's in the building and something happens, you don't have a backup.

If it goes away with your building going away, you don't have a choice. So you need to have off-site and on-site backup sets. By actually keeping track of your on-site and off-site backups differently, we can give you complete protection for both sets that's up-to-date and current, so you can restore from either set without having to worry about it.

The other thing that's intelligent about the approach of progressive incremental backup is that we have single-instance storage. Everybody in this room, I look around here, I see a lot of bright Apple logos facing me in the eye from your Powerbooks and iBooks. That means there's a lot of people out there whose data is not on a server. They need to protect it. And the important thing about that is there are a lot of common files in use.

What happens if we all have Microsoft Office installed? Do I want to backup ten copies of Microsoft Office across the network? No, I want to backup one copy and the other nine I should keep track of so I can restore them. Retrospect does that. We only need to backup one copy of every unique file in a particular backup set. It saves you space and time and it makes it more effective for your backup media.

Security. Again, multiple baseline backups are key. If you don't have multiple baseline backups, that means if you're doing incrementals against one full backup and you lose that full backup, your incrementals are useless against doing a complete restore. Multiple baselines are key in protecting your entire network. And complete verification by default. We do byte-for-byte verification of your data because if there's something wrong between writing the data to disk, tape, optical, and we go back and don't read it byte-for-byte, there's no guarantee it was written 100% correctly.

Personally, I was backing up to disk recently and I had a bad firewall cable on my personal backups. The verification pass caught the problem with the bad cable and showed me the files that were corrupt. Verification is key to your backup strategies.

While we're talking about backup today, it doesn't matter about backup. Chris's story told you a lot. You need to be able to restore the data. And Retrospect was designed to restore your data.

The most common restore we see from years of doing this is that people need to restore a few files. Because that's the common case. Oops, I made a mistake. I overwrote my budget Excel file. I've committed the save. How do I get this data back? It's not a problem.

Retrospect allows you to search for a wide variety of criteria. I can find all Excel files created by Chris in the last two weeks, and it will go and just find those in all my available backup media easily in one place. It's very key to help you narrow down your search for your important files. But it's when disaster strikes that you care the most about restore. Nobody ever wants to think about it, but it happens. Retrospect has what we create snapshots, which are basically an image of what the computer is like every time it's backed up.

So every day, assuming with Retrospect's progressive incremental backups, the first day you do a full backup, and then we do incremental backups every day since then, we still keep track of all the files that have been moved, renamed, deleted, and then we do a backup every day. We still keep track of all the files that have been moved, renamed, deleted, and then we do a backup every day since then. We still keep track of all the files that have been moved, renamed, deleted, and then we do a backup every day since then. it on the computer at every backup stage.

So if I need to restore my computer after multiple incremental backups to three days ago because I either deleted some system, I got a virus, or I had an issue like that, you tell Retrospect restore to that point in time three days ago, and it will restore that computer to exactly that point in time at the time of the backup. So if I moved, renamed, or deleted files, they're not going to come back in my restore.

If you've been doing restores from other traditional products, which do fulls and incrementals that don't track the state of your computer, when you do the restore to that point in time, you're going to get back files you moved, renamed, or deleted. You don't want that. You want your computer to be back to the exact point in time it was.

And to help you aid in that worst-case scenario, Retrospect includes a bootable disaster recovery CD that you can boot off the CD, do the restore, and make your life easier without having to first reinstall the system. So thank you very much for your time. Tomorrow we'll be in the Enterprise Lab, IT Lab. If you have any questions from 9 to 2, if I remember correctly. Is that correct, Chris? Yep, in the morning. And thank you very much.

Thanks Pat. So now what I'd like to do is introduce our next featured speaker who from our- the TOLUS group that they target their solutions called BRU. It stands for Backup Restore Utility. I thought that was a very makes sense kind of name for your product. And you can see that they're targeted pretty much in the middle. Although almost all of my vendors here can scale from the simple to the high end. I was trying to get them to look at okay what's their- what they're known for. And so without further ado, Tim Jones. Hi Tim, welcome. Thank you Chris.

Did I break it? Okay. Brew is- Yeah, we've got a good backup, so. Brew has been around for going on close to 19 years now. We have been a strong contender and a strong player in the Unix market space because that's where we came from. We grew out of Motorola technology in the middle, early 80s, and we've worked our way onto just about every Unix platform that you can imagine. And if any of you guys have got a Unix platform that I don't currently have a copy for, if you'll give me an SSH login in 30 minutes, we're there.

We picked up OSX and started supporting it in 2001 based on some requirements of our existing customer base. We have Solaris users and AIX users and HPUX users and Cray users that were bringing OSX boxes into their environments. And they said, "Hey, why can't we use Brew to back those up too?" So we got the calls and we started taking care of it.

Our team does one thing. We do backup and restore. We don't do database reporting. We don't do games. We don't do word processors. We partner with every major tape and library vendor running out there. Some of them you know. Some of them you don't know. There are just literally millions of existing licenses.

How many people have ever used an SGI box? Well, if you've done a system backup, you've used Brew. How many people have ever used Motorola's back in the old days when they were using the 8800? Well, you were using Brew. Some of the older Linux installs from folks like Red Hat and those guys included Brew in the actual operating system. And again, like I said, all we do is backup. One of the most important elements that Chris hit on is reducing that backup window. How many of you have four days to perform one backup?

We got one hand back there. I didn't think I was going to see many hands there simply because we don't. We need to get the data into its backup environment as rapidly as possible and be that staged on disk as Chris mentioned or onto tape, whether it be a standalone or a library environment. We need to reduce the amount of time that that operation requires.

The thing that Brew brings to the table here is we provide very high throughput rates and very low CPU overhead. Primarily, a good example, we have users that are constantly using Brew in multi-drive scenarios where they're backing up to and streaming data to multiple drives simultaneously. And on a 1.33 GHz XSERV, our numbers look like load factors of about 0.4 with CPU utilization of about 22%. What this means is that while that backup is going on, you're actually able to continue doing useful work.

We do our verification quite differently from most others. Every 2K of data that we pull off of your file system, we apply a 32-bit checksum to. The result is, when it comes time to do a verification of the data that's on the tape, we only need brew and the tape. We no longer need your file system. So for those of you that are doing live backup with live verification, we just sliced your backup window in half.

We incorporated disk-to-disk capabilities directly into our current Bruce Server product. Some of you have come by, I see some faces out there that I recognize when I cover the light. And one of the things that we've done is we've added this technology right into the product native. You don't have to buy it as an add-on. Because we realize, again, we've got to reduce that backup window to help you be successful in your administration tasks.

By writing to disk, two things happen. First of all, as Chris said, you're getting disk-to-disk speed. Your only limiting factor is your network infrastructure. But, in addition, if you've got lots of clients out there, if you're backing those clients up to tape, those clients are having to take turns.

You're backing up one client, it's finishing. You're backing up the next client, it finishes, and so on. With a disk stage environment, all of your clients can backup asynchronously, limited only by your network bandwidth. If you're dealing with systems where you've got 100 or 200 megs of data that changes on a daily basis, an average incremental backup can take as little as 10 or 15 seconds. So when you- when dealing with staging. So when you look at it from that perspective, all of a sudden, now this work group stage backup window has just reduced itself dramatically.

Finally, as Chris mentioned, the next thing to do with staged data is to put it onto media that can then be stored either safely on-site or off-site as Pat was mentioning. The key there is, again, how do I do this without interfering with my daily work schedule? Well, because bruise upstaging occurs between simply the server on which the server application is running and your tape library, again, the rest of your network backup environment is not involved at all.

So you're not- you can do this at your will. It doesn't matter. And again, because of bruise low fingerprint and- or footprint and low overhead, even the server that we're running on does not recognize a serious impact with that operation. Finally, on the upstage, when we upstage that data from your stage disk to the tape drive, we actually replicate the data into a tape backup as if you wrote it originally to the tape. So, in other words, when it's time to restore a client's data, it's a one-step restore. You're taking the data from the tape and returning it to the client. There's no need to restore the upstage environment to the stage disk and then restore to the client.

We are about 92% POSIX. Our core engine is just a whopping 290K on OSX. The 8% that's there that's not POSIX applies to supporting OSX Tape I/O, OSX Disk Record Utility, which will be coming in an upcoming release. The utilization of special features for some of the special OS's such as PTX and IRIX and these things where you have to take into account the way you allocate memory for certain things.

These are the little pieces that are specific to the various OS's, but that makes up a little 8% of what we do. This means, this is why I was not joking when I said if you can give me a login in 30 minutes, if I'm not on your platform, we will be.

We provide unique mechanisms to proof the backup. As I said, every 2K of data that comes off of that file system is checksummed when it leaves the file system because between the time that it leaves the file system and the time that it hits the input buffers on your tape drive, there are a number of places where corruption can occur. Because we check summit that early, we can tell you very rapidly whether or not you've got a good backup. And we can tell you down to 2K within an existing file on tape whether that data is any good.

The key here is, in the event that we run into a problem, tape media flakes. How many of you have never had a tape problem? and many others. Thanks for joining us. We'll see you next time. Bye-bye. If you run into a situation, if any of you have ever used TAR to do a backup and tried to do a store and been greeted with something that said TAR, Tape I/O Read Error, well, you're not going to see that with Brew. Well, unless the tape really is absolutely bad and it can't be accessed.

Finally, cross-platform, I mentioned all the platforms that we're on. The one other thing that's important about that is because we utilize the same tape I/O layer for all of the platforms, you can take tapes that you backed up on SGI, you can restore them on OSX, or you can send them to somebody with a SCO box, or you can send them over to a Linux platform or a Solaris platform or any other platform, and we will allow you to restore that data intact. We take account things like Big Indian versus Little Indian byte swapping.

If you've ever used CPIO because you needed to move data from a Big Indian system to a Little Indian system, you know you have to add special flags. Brew recognizes those changes and takes care of all that for you, so when you get into that area, we've taken care of it. We are highly extensible- hey, that should have been highly, Chris.

We are highly extensible via scripts and compiled- or compiled wrappers. Brew, as I said, is a very, very good tool. It's 290K. You're able to take that and combine it with whatever language you want to use: Cocoa, Carbon, Java, TCL, TK, Python with TK inner, real basic. It's your choice.

You can put your own wrapper around Brew and make it do things that you want it to do, but you don't have to worry about how we get the data to the tape or back from the tape or to the stage environment. As developers, if you're interested, we can talk about that. We actually provide that 290K kernel as an OEM product, and we can help you build back up into your application.

Brew understands and supports all Unix and Mac OS X elements. Now, how many of you saw the Tiger keynote? How many of you know what an ACL is? Well, guess what? Brew 17.0, which is the core of our current application platform, does not support Tiger's ACLs. However, in about two weeks, it will.

We are- Thank you. We are compatible with OS X- OS X 1.5 through the latest stuff. Now, I did a naughty and I installed Tiger on my laptop and we'll see, but I have very good feeling that we are not going to be facing any problems there. We leverage the Unix layer of OSX to provide that small footprint and high performance with low overhead.

We utilize the SCSI standards, the standards for tape, SSC, and for changers, SMC, to ensure that whether you're using the smallest firewire device or the largest fiber channel or SCSI library, we've got you covered. We don't also charge extra for those types of pieces, so if you've got four libraries, you're going to pay us one price for a product. And like I said, we support all SCSI, all fiber channel, all firewire and USB devices natively, no additional drivers.

So, and I also forgot, of course, one question that comes up. Yes, we cover your resource forks and all of your finder info. So if it was positioned here on your desktop when you backed it up, when you restore it, it's positioned here on your desktop. So that's it. Thanks very much.

and unfortunately I'm not going to be available tomorrow at the lab, but you guys can visit us and Chris has got information on the web for how to get in touch with us here at the end of the show. Alright, great. Thanks Chris. Thank you Tim. Sure. All right, so now you've seen some great solutions from Danz and Tolos Group.

So now what we're going to do is look a little bit more at what we call the high-end corporate and market. And to do that, we have BakBone, even though I spelled the name wrong. Sorry about that. It's B-A-K. But anyway, I'd like to introduce today Andrew Bowles, the Senior Director for Strategic Alliances at BakBone. Thank you, Chris. Welcome. There you go. Cheers. Thank you.

You know, again, when we built NetVault, we built it back in the early 90s like a lot of products. However, we took a hit and in the mid-90s, 96, 97, we rewrote it from the ground up to take advantage of network storage environments. A, it's got a very easy-to-install GUI-driven product, but also it has a modular architecture, an architecture that allows us to design and develop very quickly.

So, in the case of Oracle 10G for OS X, we're talking about weeks of development, not months like some of our standard competitors, Veritas and Legato and the incumbents that have a much longer rolling development cycle. Disk-to-Disk, you've heard about it a lot. I'd be surprised if most of you aren't experimenting. The next step is taking a look at a virtual tape library, a virtual disk library, and it allows your disk device to look like a tape target.

When Chris talked a little bit about the growing compliance needs, this is a way to begin setting yourself up for that, a way to migrate off to tape and do it effectively and also, naturally, as you heard, recover quickly. So, again, I think, you know, if I was asking you to take a few things away from this, robust disk-to-disk capability and also broad choice in the application side. You know, again, we don't see that there should be a trade-off moving to OS X. We want to give you the ability to run Oracle, run MySQL. SQL and do it on your time.

I want to put a sample graphic up here, just what a standard, we call it Acme Engineering, might look for. Again, hot backup, that would be your Oracle, MySQL. We've been doing this for a long time and I also want to point out we've supported FreeBSD in the past. So for us it was a pretty clean port.

I'd point to a customer that I spent a lot of time with down in the peninsula and that's Yahoo. They chose, they're a large FreeBSD shop. They run a lot of MySQL, so for those of you that aren't sure whether MySQL is ready for the, an enterprise environment, I'd urge you to think again. I think many of you would be surprised, it's coming a long way, coming fast.

That's 18 data centers across multiple continents and again, they're running on FreeBSD. So I think that Apple in moving forward with OS X has picked a winning, winning platform and, you know, is staying with their mantra which is all about reducing complexity. From a backbone in Apple, it's a lot of data. From a general standpoint, we share that as a common vision, taking more and more complex environments and making them, you know, easier and easier to implement.

One thing I want to come- you know, for you to come away with is A, we're a company that's easy to do business with. We have a sales model that's entirely indirect. So, you know, whether you want to pick up a partner in the form of Apple and purchase NetVault through the iStore, or if you have a common VAR that you're already used to doing business with, someone that takes care of your needs, we're there to enable them.

Backbon as a company is entirely indirect. We work with our channel partners, we work with OEMs such as Apple, and key ISVs such as Oracle, MySQL, Sybase, and others. So, again, I'm looking forward to the Q&A portion of this session. I encourage you to throw some questions our way. And again, I want to thank Apple and Chris for having us here. Thanks a lot.

Good job, thank you. Alrighty, batting up our designated hitter, I guess you could call him. Actually, we've also invited another one of our vendors, Atempo, who also has a solution targeted up here with their product called Time Navigator. So I'd like to welcome Randy Batterson, Director of Strategic Alliances.

Come on up. Chris? All right, thank you. Well, I'd like to kind of kick everything off and just give everybody an idea about who a tempo is and what we do. Basically, the company- Let's see if we can get this right here. I knew I was going to do that.

First time for everything. But basically, Tempo's been around for 12 years. The company was founded in 1992. We're actually dually located. We've got a facility in Paris, France. We also have a facility in Palo Alto, California, right here in the Bay Area. We actually consider our product a best-of-breed for high-performance enterprise environments. The product has been engineered from the ground up. It's very, very high-performing.

If you look at our customer base, it's actually a global 1,000 customer base. We have clients like France Telecom, huge telecom company. Been with them for almost seven years, and they've got about 13 different sites around the country itself. And what's really interesting is that we actually support almost 3,000 clients from a central location on that particular facility. So, again, it kind of goes back to that enterprise functionality. It's a very, very robust.

It's a very robust product. We've got almost 2,000 customers worldwide. And out of those customers, we've got roughly 3,000 sites. And I would say a good chunk of those are all very high-end performance or high-enterprise-type companies. And if you really look at it, some of these customers have a very high computing requirement. And that's, again, a reason that they go to this product, because we have a strong suite of business continuity and compliance solutions to offer them.

The company itself has about 170 employees right now. We're growing very rapidly. We've got about 44 technology people focused just on R&D. So this really kind of shows us the commitment that we have towards developing new products, just like supporting Mac OS X. And we've put a lot of emphasis on development, and I think this kind of shows that most companies don't have that type of a ratio of engineers focused just on development.

Some of the industries that we support include telecom, finance, manufacturing, education, government, a lot of the key industries that are also touched upon with the Mac environment. So again, this is a nice marriage between what we're doing, supporting Mac OS X, and the industries that we currently support. So we think that we're going to have a really good addition to the Mac family.

Okay, I'm just going to dive in a little bit here about what the product is. Time Navigator. One of the things that we like to say is that really it's got the fastest restore period. And that's- if I can leave you with one thing today, just remember that restore is what we do best. And we do it really well. There's some really key features that help support this. Kind of going back to the name Time Navigator, we do something which is called time navigation.

And the way we do this, it's actually the ability to go back in a point in time, any given point in time, we could actually go and retrieve a file or directory at any instant in the past. So it's a lot like going back into the past. You can actually pick on a particular date, time, and bring that file back. And we do this in a unique way. We use an object-oriented database. And why this is unique is if you look at the way many other solutions actually perform this function, they actually do it with a flat file database.

And what that causes is when you go and actually do a metadata search, you're actually going in a sequential form. So you actually have to go and, you know, go down the line and actually find the information you're looking for, just like if you were searching on a tape. By using an object-oriented database or a relational type database, it's instantaneous.

So that search takes a matter of seconds, nanoseconds. I mean, you find it, boom, you're there. What's really nice about time navigation, too, is the way we actually display that information. And what we do is we put it in a kind of a directory tree structure. So it's very user-friendly. It looks just like what you're looking at in any type of a directory tree.

So if you're looking for a particular file, you put the date down that you're looking for this file. And what happens is when you click on it, it does that search instantaneously. It'll bring back that tree, and it'll show you exactly the way your data looked at that point in time. And what's really nice is it'll actually show you with little crosshairs on a particular file if that file was deleted or there was a change to that at a point in time.

Now, where we get a little more deep in this whole search in time, if you will, is we give you the ability to do a depth of search. So you can actually click on that hatched file, click on it, and it'll show you every change that has ever happened to that file.

And then what you can do at that point is actually click on any one of those changes and bring back that image or the data the way it looked on that particular time. So it's very quick. It's very unique in that sense. You're getting a, you know, a point-in-time visual, if you will, of the way your data looked, and then you can restore it.

So it's very quick. Synthetic full backups. This is another thing that we do. It's kind of like what -- I guess what we like to say is that it's an incremental forever. What -- if you can imagine when you go in to do your first backup, you're going to have to do a full backup, okay? After a point in time, what you're going to start doing every -- say, every day if you set up your policies, what you're going to do is an incremental after that, and then another incremental, another.

If you were to do, say, a one-week setup, and at the end of the week, say you started your backup on Sunday, you finished on Saturday, what's going to happen is offline, Time Navigator will take those incrementals and it will build a new full. It's a full out of all those incrementals. This can go on forever, and that's why we kind of call it a forever incremental paradigm.

It keeps doing this forever. You never have to do a full again. And you can add points, you know, delete what happened before so you don't keep accumulating all that baggage. Where this is really unique for the restore, why it makes it fast, is going back to that database, what you're able to do is if you -- let's go back to the scenario where you did your full, and let's say after that first week you want to go back -- excuse me -- and you want to actually find a file on Wednesday. What happens is Time Navigator, because of the database and being a relational type database, will go exactly back to that full.

So you can go back to that full and you can actually find it back to that particular file on Wednesday. So what you don't have to do, which happens with many other applications, is you actually have to go and load the full, then go back through, you know, the Sunday full, then the incremental Monday, then the incremental Tuesday, just to get back to that Wednesday file. So it makes it very fast. You're not having to go through that whole cycle of going through tapes.

Another thing that we do is macro multiplexing. Macro multiplexing is really nice in the sense that if you're familiar with multiplexing the way it happens today. Basically, you're going to get multiple tape streams coming back to a backup server. And what happens on the backup cycle is the data is actually laid down onto the tape in little bits and pieces.

When you go to do a restore, you're actually having to go back and pick out little points of that file information and feed it through. And what happens is the tape drive actually starts doing a shoe-shining effect. And this actually slows down your restore. What Time Navigator does is we actually create a buffer.

and when the backup job kicks off, the data is put into 256 megabyte buckets. Okay, and these buckets then, once the backup starts, you know, feeding into this buffer, it'll go up to like a watermark and when that watermark is hit, the backup job will kick off and the data will actually start getting laid down onto the tape and what happens, it gets laid down on these 256 megabyte chunks.

Well, when you get to the restore, instead of having to go back and look for each, you know, each little piece of data like you would with regular multiplexing or interleaving, you actually backup using these big chunks and they come right back to the server very fast, basically hitting the theoretical throughput of the tape drive.

I'm not getting a lot of support there. Another thing that we do is actually, this is quite unique. I think we got a pointer here. Can you guys see that? Kind of. I think I'll just point. One of the cool things that we do, actually, on a security standpoint is we're able to back up through a firewall using just one port. Many applications today actually require opening up multiple ports, as you can see over here on the left-hand side. What happens, thanks.

Actually, what happens is in these other applications, you have to open up multiple ports, many for to initiate the backup and then many for, you know, bringing the data through on the other side. So you have anywhere from, you know, 10 to 25 ports opened up. What happens is a lot of these ports remain idle, and that opens you up to the threat of any kind of security attack.

With Time Navigator, we actually only open up one port. That's an outbound port opened up by the administrator. So everything from the metadata to the actual data flow to the TCP actually goes through that particular port. And again, that's an outbound port, so it's not open from the outside. It's open from the inside, inside the firewall, so nobody can actually penetrate from the outside.

This is really cool, too, because there's a couple very large deals that we got. Just to give you an idea, Capgemini, Ernst & Young, you know, auditors, I mean, these guys really worry about protecting their data, right? One of the things that they picked us over or picked us over the competition, if you will, was because we had the security feature, and it was very key for them to pick us because of that.

Okay, Time Navigator, just a few more innovations that we have. End-user simplicity. You know, a really cool thing that we do is a data center services model. The data center services model actually is something that we have that allows a user to kind of rent to own, if you will. It's kind of like leasing a car. Instead of actually having to go out and purchase the product in its entirety, all up front, put up a big capital expenditure, we're allowing customers to actually kind of pay as you go.

We'll go in, we do an assessment of the customer's site, understand what their data requirements are, set up kind of a billing cycle, if you will, for them based on what we think their usage will be, and then they're actually able to, you know, match against that, say, every quarter and see kind of where they're at and just pay on a monthly basis.

At the end of a period of time, like a year or two years, if they want, they can actually purchase the entire thing or, you know, just keep using it on a monthly basis. So it's a real nice way to actually get into backup and restore, especially in enterprise environments. environment, instead of laying out a lot of cash, they can do it very cheaply.

Multiple backup streams, up to four. This is really a very unique feature that we have also. So if you can imagine, if you're backing up to, say, an X-ray, and you want to kind of invoke some DR features, and it's something a lot of people are doing. I know we've been talking about DDD to tape. This actually gives you the ability to back up to four different devices at the same time.

So the same data stream can be backed up asynchronously to four different devices, and it can be any mix of devices. It could be tape, disk, MO, and it could be any number. So you could have two disks, one tape, one MO. And where this comes into play is, for example, if you're going to have some kind of a DR scenario. So you're backing up to the X-ray, and you want to back up to a disk locally just to have something near line.

At the same time, you want to have something offline, and that would be, say, an off-site DR site. You can do those asynchronously. So if one breaks, the other one's going to go regardless. And we can do it up to four. So if you want to have four different sites, we can do it.

and Flexible API and CLI. Basically, API set, we touch on every feature in the product. This is really key too. I mean, if you've got different products within your environment and you're not sure if they're supported or maybe we don't support them through our APIs, it's very easy to write and support the product set. CLI, you know, command line interface, same thing. If there's some scripting that needs to be done to support a product, we can do it very easily.

So that's about it. But one thing if I can leave with you today is that Time Navigator basically is the fastest restore period. And that's something that will, you know, challenge anybody on. We've got some really good features and we think they're great. So thank you very much.

Thank you Randy. So you see some really excellent solutions from a number of vendors that support the Mac OS X platform. So just kind of tie it all up again to kind of repeat what we talked about. So we looked at initially some of the storage trends that's driving the market today. Everything from compliance to the need to reduce your backup window, and that's driving your strategy for how you need to backup your systems.

We looked at a number of different backup architectures. Obviously just regular backup, accessing your man- doing disk- to-disk-to-tape, to land free. And then as you see we have a wealth of backup choices available, meaning any need you would have in your particular environment. And last but not least, I'd like to invite you tomorrow morning in the Enterprise IT Lab.

I will have everybody here. We have some demos showing some of their equipment. Any question you have on backup, I'm sure we'd be able to answer it there tomorrow at the Enterprise IT Lab. So if you have an opportunity, please, please just stop by and see us and we'll be glad to have you. All right. Contact information. For myself, Pat, Tim, Andrew, and Randy. And I'd like to ask my four colleagues to come on up and join us here.