The Weblog of Erik J. Barzeski

Update Dec. 24, 2008: I've long since repurposed my Drobo after running into the same problem a commenter below had: the data backs up but doesn't show itself as a backup in Time Machine. There's a work-around, but it isn't a case of "it just works" at all, so you may want to avoid using your Drobo for Time Machine backups at all. It's way, way too much of a headache.

A few days ago I reformatted my Drobo because it was acting up. I believe this was due to a system reinstall and not the fault of the Drobo. Prior to reinstalling I was made aware of the fact that the Drobo, like virtually all expandable mass-storage devices, "lies" to the computer about its disk size.

This "lie" is beneficial if you plan to expand the size of your disk drives. It leaves "room to grow."

The "lie" is a horrible one, however, for Time Machine, which prunes its backups automatically when a disk is full. In my case, Time Machine would be led to believe I have a 2.0 TB disk even though my current Drobo configuration is only 1.35 TB. Once Time Machine had dumped 1.35 TB of data on my disk, it would not know to start pruning old backups to make room for new ones because it would believe that it still has another 650 GB of free space!

Additionally, because Drobos give you quite a bit more than half the storage space, it plays some tricks with your data to keep it safe. The long and the short of it is that once you get to about 95%1 of your actual maximum capacity (again, 1.35 TB in my case), the Drobo slows file copies to a crawl in order to run its proprietary routines that are designed to protect your data.

Update: 2008-11-13 08:42:40I've drastically changed the content of this post. I do not want to be seen as giving bad information (nor, obviously, do I actually want to give bad information), and since search engines are likely to pick up on this article, I've amended this article to be as useful as possible for as many people as possible.

As a result, several of the comments below may seem out of place. I'll consider removing some with the author's permission, though I currently hope to leave them all in place.

If you're looking to use your Drobo with Time Machine, I've come to understand that there are essentially three methods for doing so.

Best Method: Use a Sparse Image
By consensus, the "best" method is to use Time Machine's capabilities to back up not to the disk itself, but to a sparseimage file. A sparseimage file is like a DMG (disk image), but with some added special properties. For example, it can expand dynamically and the image file can be held to a maximum size. Apple's Time Capsule uses a sparseimage file with Time Machine to store backups for multiple computers.

The easiest way to create a sparseimage that will work with Time Machine is to use an Automator script called Time Tamer. Time Tamer will create a sparseimage file on your Drobo sized that's twice as large as your boot disk. For many, that will work.

If you're comfortable using the Terminal, and you'd like to customize the size of your sparseimage file (as well as the name), you can do so (originally posted in my comment below) with this command:

In this script, "1024g" is the maximum file size (1024g = 1024 GB = 1.0 TB), "Time Machine Backup" is the name of the disk as it will appear when mounted during backups, "/Volumes/Mimzy/" is the path to my Drobo, "Bunny" is the name of my computer (hostname without the ".local"), and "0017f202b9ec" is my computer's MAC address, obtained with ifconfig en0 | grep ether or via the System Profiler application.

Using this method, you can safely set your Drobo to be a 2.0, 4.0, 8.0, or even a 16.0 TB drive. This size will be reported to the Finder and other applications as the available size of the disk, and theoretically if we see 8 TB disk drives at some point, you might even get there.

Because of the "protection" methods used by the Drobo, it's still recommended that you stay below the "95% actual disk space" threshold at which the Drobo will slow file copies to a crawl. The Drobo Dashboard application will tell you how much actual disk space you have. In the image below, it's the "Storage Capacity."

In my case, I've formatted my drive as a 16 TB drive and created a Time Machine backup sparseimage file capped at 1.2 TB. Until Time Machine backs up 1.2 TB of data, I'll have a little extra space to store files temporarily, but it's up to me to remember that. After all, so far as the Finder knows, the disk is 16 TB in size. However, if I ever swap out any of the 500 GB drives I have installed now2 with a larger one, I will either be able to increase the maximum size of my sparseimage file (hdiutil resize -size 1500g) or I'll have a little room to play with.

This method is quite nice for several reasons. One, your sparseimage file can be upsized as you add more storage. Two, the sparseimage file itself is a single file. You can back this file up, copy it to another Drobo, or do anything else with it that you can normally do to a single file.

There's just one word of caution, and that is that regardless of the situation for which you use the Drobo - Time Machine, general storage, or a combination of both - you should take care to remain below the 95% threshold.

Method Two: Format for Smaller Sizes
If you use the Drobo Dashboard application to format your drive, you'll notice that it offers several choices for volume size: 1.0, 2.0, 4.0, 8.0, and 16.0 TB. If you create a volume that's larger than your "actual" storage space3, you'll get one volume that reports this increased size to the Finder and everything else.

But if you choose a size smaller than your actual storage, you'll create multiple volumes. For examaple, if I chose the 1.0 TB option with ~1.35 TB of actual storage space, I'd get two volumes or "disks." Both would report that they were 1.0 TB in size. One would actually be 1.0 TB but the other would only be about 300 GB in size. If I then expanded by replacing the drives with larger ones, I'd increase the actual size of the second drive or, eventually, end up creating a third drive, a fourth drive, and so on - all 1.0 TB in size.

If you never plan to increase the size of your Time Machine backup, you can use this to your advantage. In my case, I could have chosen a 1.0 TB size and used the first disk - the one that's got an actual size of 1.0 TB - as my Time Machine backup. The second disk I could use for temporary file storage or something, again taking care to stay below the 95% threshold.

This isn't the most practical of methods, and it's fairly limiting. If you later change your mind and want 2.0 TB of Time Machine space, you'll have to reformat your Drobo, which will delete the data on every Drobo drive.

Method Three: My Original Method
This is based on my original method, which I've since abandoned in favor of the sparseimage method. It uses a combination of the Drobo Dashboard and Disk Utility in a way similar to the second method, but without the "extra disks" or the precise limits on volume size.

Before you read any further into this method, parts of this method may very well be unsafe. According to a Data Robotics representative, the first parts of this method are supported. I'll point out when that barrier is crossed.

For this method, you format your Drobo using the Drobo tools for a volume size larger than the actual size of your disk. You should leave room for growth, up to and including choosing the 16 TB option. The Drobo will reformat (i.e. erase) the drives and appear on your desktop after a few minutes as a 16 TB drive.

Before copying any data to the drive, launch Disk Utility. Click the "Partition" tab and drag the volume size (or type in a number) such that it is below the 95% threshold.

This screenshot illustrates the process on a Drobo formatted as a 2.0 TB drive. Because this screenshot is from the way I used to be doing things, there is one incorrect thing and one difference from the way it should be done:

Difference: your volume shouldn't have any "blue" in it, as blue = data. It should be entirely white.

Incorrect: 1.35 TB was my "actual" storage capacity. I should have sized it at 1.2 TB to stay below the 95% threshold.

Again, do this before you copy any data to the drive.

When you're done, your Drobo will appear on the desktop as a disk of the size you've chosen. In my case, had I created a 1.2 TB disk, it would show 1.2 TB. I could use the volume as a Time Machine backup volume, for general storage, or any combination of those two things. Time Machine would automatically prune old backups as necessary and you wouldn't have to think about sparseimages or the 95% threshold, as that's built in already.

The downside is that you're also limited in how easily you can upgrade the storage. If some day you find four 1.0 TB drives on your porch, and you pop them into the Drobo - one at a time, and when the Drobo lets you so you don't lose any data - you'll have 2.7 TB of actual storage space. Yet your disk will still show only 1.2 TB because that's how large the partition is. The rest is just unused - and inaccessible - space.

That "supported" versus "unsupported" barrier I talked about before? Here it is. Everything above here is supported by Data Robotics. What I'll talk about now, below this point, is not supported by Data Robotics. Again, I've done what I'm about to tell you below and others have as well, but you should consider us to have gotten supremely lucky.

Warnings aside, let's get back to the scenario I was talking about above. We lived happily with a 1.2 TB disk, but it's full and someone left four 1.0 TB drives on our porch, so we want to put them into the Drobo and increase the size.

So we do so, one at a time and when the Drobo tells us it's safe, and eventually we have 2.7 TB of actual storage space being reported to us as the 1.2 TB volume we created earlier. When the Drobo is not doing anything - the Drobo Dashboard's drawer will often say something like "DATA PROTECTION IN PROGRESS" when it is - you can launch Disk Utility and drag the partition size to create a larger partition. In this case, you might drag it out to 2.4 TB. You'd click "Apply" and you'd wait for the partition scheme to be applied.

After awhile, your disk might re-appear on the desktop, data intact, at its new size.

I've done it several times. Once when I was using this method, as seen in the screenshot above with the "blue data," and several times last night as a test re: increasing the size of the partition as a test. However, it remains unsupported and not recommended. You cannot trust Disk Utility when it says "this volume will not be erased" because it doesn't know that the Drobo is the special kind of disk that it is.

Note that the initial partitioning to a smaller size may take awhile, and it will likely depend on the sizes ("fake" and "actual") of your drives. Some of the operations I performed took a few minutes. One commenter noted that his took 12 hours.

I should note here that I was "okay" with catastrophe - losing every bit of data on the Drobo - because mine is a backup drive and I have several other backups available. Odds are, you don't. Consider that the last warning.

Some Thoughts on Why Method Three Works at Least Some of the Time
An HFS+ disk has several invisible items. It has an "Extents Overflow" file, a few catalog files, and volume bitmaps and information that store things like the size of the disk and its partition(s). I believe that the Drobo also stores this information - part of the reason why you can use Disk Utility to Verify and Repair Drobo drives, or format them - and this is exactly the reason why you can re-partition with live data.

With a normal disk, the location of this type of data is important. I believe this "hidden information" is typically written at the lowest addresses on the disk. If data is written immediately after it, the disk is limited in how much it can change that hidden information by the space it gave itself to grow. This hidden volume information is obviously stored on the Drobo, but it may not be in one place and it may not even be on one disk. The Drobo seems to act as a sort of address translator. The Mac says "give me this file," and the Drobo assembles the file from various parts sitting at various locations and hands it to the requesting application.

If that's true, then perhaps live resizing a Drobo will work fairly successfully a good percentage of the time as long as some guidelines, such as not pushing close to the 95% "slows to a crawl" threshold, are observed4. Nobody outside of Data Robotics knows how the Drobo works, but I personally believe this method to be at least a little bit safer than the stern "DO NOT" warning issued by Data Robotics. But then again, they're the experts and I'm just speculating wildly, so take this entire section for what it's worth (not much at all).

Are you using a PPC Mac? If not, unfortunately that's not going to work for you. I mentioned this in my comment on your last post about the Drobo, but you need to make sure you have the correct partition map on your Time Machine drive, or somewhere down the line bad things will happen.

I don't have a drobo but I did notice a drobo app targeted at Time machine users.http://www.drobo.com/droboapps/downloads/index.php?id=16
Apparently its a script to limit the size used by Time Machine on the drobo. Could be helpful as it sounds like Time Machine swallowing up space that isn't really there wouldn't be the best thing :p

What I did was split my Drobo into two partitions. One for Time Machine, and one for general storage.

So I created a 500GB partition for TM, and I left the rest to storage where I keep my iTunes library, work files, etc. That way everything on my mac is backed up via Time Machine but my huge music library and work files are protected by the Drobo itself.

You know, Data Robotics strongly warns against using 10.5's live partitioning on a Drobo.

The rep on the phone told me the same thing re: that note. He said they support resizing the partition sizes before you copy data to it, but they won't support resizing afterwards. When I told him I'd done so, he said (paraphrasing) "yeah, it usually works, but some lady tried it and made a big stink about losing her data, and we don't support it at all."

Unfortunately, the Drobo tools only let you choose 1.0, 2.0, 4.0 (etc.) sizes, so choosing 1.2 TB (or 2.4, or whatever) is impossible. The Drobo app itself will tell you to use Disk Utility if it, for some reason, can't format a disk (in my case because it couldn't unmount it).

I wouldn't recommend this solution. Setting the partition on the drobo to 16 TB allows for future expansion with the fewest headaches. The Drobo is designed for easy expansion, and as you add drives (as most Drobo users will as drives become cheaper and cheaper), the solution you outline will force you to add partitions. Each partition is mounted as its own volume in OS X, so you can easily foresee having to split your storage across 4, 5 or more volumes.

The most simple solution, at least to me, is to allow the Drobo to "lie" to your computer about its size (therefore only dealing with a single external volume), and then just use Time Tamer or the terminal to limit Time Machine from taking up all your space.

That sounds like a good solution for you. It should remain that way so long as you remember the "lie." And FWIW, I hate calling it "the lie" but I can't think of a better term for now. "Lie" implies "evil," and that's not really a factor here. But it's all I've got for now.

I think my solution bypasses "the lie". Time Machine only sees that it is on a 500 GB partition and will not try to take up any more space than that...it's the equivalent to having a 500 GB hard drive plugged in.

Now "the lie" comes into play with my storage partition but then who cares when it's something like 1.2 TB in my case? I will never use that much.

So I don't need to think about this at all when it comes to Time Machine

The rep on the phone told me the same thing re: that note. He said they support resizing the partition sizes before you copy data to it, but they won't support resizing afterwards. When I told him I'd done so, he said (paraphrasing) "yeah, it usually works, but some lady tried it and made a big stink about losing her data, and we don't support it at all."

That's interesting, and a little unsettling that they'd put out such a strong warning as a butt-covering move without properly understanding the risks. But if a risk does exist, you couldn't expect Disk Utility to warn you, because it has no way of knowing it's connected to anything more complicated than a single drive mechanism.

Either way, I encourage people to size their disks properly before doing a single backup. There's no data to be lost at that point.

I didn't mean to suggest that you shouldn't use Disk Utility with a Drobo - destructively partitioning before you put any data on it makes sense, and is fully supported. But I doubt that most people with large Drobos have the capacity, or see the need, to keep them backed up (though they should), and as you recommended, many will use it to store a mix of primary data and backup data.

Given how much the Drobo benefits over time from being able to seamlessly add storage to a single pool, using the above "MaxSize" tip to put a soft lid on Time Machine's backup consumption seems like a preferable long-term approach to partitioning for its own sake.

The Drobo is designed for easy expansion, and as you add drives (as most Drobo users will as drives become cheaper and cheaper), the solution you outline will force you to add partitions.

Only if someone plans to add drives. Prior to my recent re-format, I had data going back to the first day I had my Drobo about three months ago. For awhile, I had absolutely no plans to add storage to the Drobo. I was simply using it as a sort of overpriced RAID for my Time Machine backups. So while the Drobo may be designed for easy expansion, not everyone will necessarily plan to expand. Nine months of Time Machine backups is plenty.

That's interesting, and a little unsettling that they'd put out such a strong warning as a butt-covering move without properly understanding the risks.

Better safe than sorry. I don't personally blame them for covering their butts. When it comes to data, everyone should cover their butts.

But I will say the guy wasn't surprised that it had worked for me. I got the feeling that he thought it would work at least some of the time, perhaps even the majority, but that it's still important to cover themselves in case data is lost.

Perhaps true, but isn't part of the beauty of the Drobo that it appears to be just a regular disk to the Mac OS?

For the purposes of reading and writing data, it appears to be a regular disk. That, of course, is the Drobo's biggest lie of all, and the illusion was not designed with stretching the partition map in mind. Live repartitioning can fail even when Disk Utility knows exactly what it's dealing with, so it's hardly a stretch to think that the Drobo's behind-the-scenes knife-juggling might interact poorly with Disk Utility's behind-the-scenes knife-juggling.

When your drives do fail, you're going to replace them with larger drives which cost less, per GB, than the ones you own today. Unless you expect the useful life of the Drobo to be less than that of your current computer, you'd have to work pretty hard to do otherwise.

In the meantime, the Drobo's knife-juggling remains proprietary, and nobody outside Data Robotics is in a position to definitively determine whether using it with live partitioning is safe. They claim it's not.

Live partitioning debuted in a limited fashion for Boot Camp, to allow a windows partition to be carved out from an existing disk. Once set the new partition couldn't be resized, or deleted. The generalized version came out in 10.5, and it still only works with GUID-formatted HFS+ volumes. Thus the comment above about the lack of PPC support, as GUID volumes can't boot PPC machines.

Did you know that what you call Drobo's "lieing" about its actual space is a "feature" in Enterprise Storage systems called "thin provisioning" that sell for 100x the cost of Drobo?

Previously I had seen lots of articles describing how to use OS X's hdiutil plus a lot of other command line mumbo-jumbo to create a sparsebundle to limit how much space Time Machine used. The "Time Tamer" app at drobo.com/droboapps automates all of that crap ... its easy to use and makes sensible defaults. We've been using it for about 3 weeks... no problems, just goodness.

The comments above about Drobo being "proprietary" are -- how do I say this politely? -- rubbish. While technically true, they are phrased in a way to create concern and alarm.

Every other RAID array is "proprietary" in the sense that you can't move a disk set from vendor A to vendor B and expect them to work. Ditto for all the Enterprise thin provisioning solutions.

if you only have 1.35 TB of usable space (i.e. 4 - 500 GB drives), and you're using your Drobo as a time machine backup, i actually would strongly recommend AGAINST formatting it at 1.35 TB and not using another utility (time tamer or the terminal script) to limit Time Machine.

why? because Time Machine thinks it can use all 1.35 TB of the available data and while this is true, when the drobo gets 90% filled with data, the speed at which it writes data goes down to an absolute crawl and it can start to cause issues. not to mention the drobo itself starts to scream at you to replace your drives with bigger ones. but Time Machine WILL start to delete data at that point, but it will always keep the drive filled and it will run at a snails pace. its not fun. i speak from having this happen to me.

see what i'm getting at? if you only have 1.35 TB of space and you're not going to use Time Tamer or the terminal script, then format your drobo to 1 TB just like Drobo suggested that you should do. that way your backups will always be speedy and (relatively) trouble free.

Actually, this is much the better solution in some respects, its not actually an application, but an Automator script to make easy a method of creating a DiskImage (.dmg) as the ultimate destination of your Time Machine backup, as such it doesn't hack any prefs *nor* is it Drobo specific.

It is basically going to size your system drive, then allocate a DiskImage of twice that capacity, where normally this would pre-allocate the required space, in this instance it creates the dmg as a sparseimage (ie. thin provisions it). Time Machine sees the image as a valid target of 2x your system disk and backups into it ... this is the exact same approach Apple use for disks in the Time Capsule, as you can support many machines to one TM, each gets its own .dmg.

The automator script just makes this easy and appropriately names the .dmg to enable simple operation.

BTW, this means you can even backup, duplicate for offsite, etc the .dmg easily and transfer it around without any issues. A much better solution than re-partitioning and more flexible.

For the purposes of reading and writing data, it appears to be a regular disk. That, of course, is the Drobo's biggest lie of all, and the illusion was not designed with stretching the partition map in mind. Live repartitioning can fail even when Disk Utility knows exactly what it's dealing with, so it's hardly a stretch to think that the Drobo's behind-the-scenes knife-juggling might interact poorly with Disk Utility's behind-the-scenes knife-juggling.

It certainly interacts badly with iPartition's â€œbehind-the-scenes knife-jugglingâ€, which is why we wrote this and then added red warning test to the bottom of the iPartition product page on our website.

The fact is that Drobo's controller is making all kinds of assumptions about the validity of the information about where free space is within the partition maps and filesystems it supports. During repartitioning, sometimes those assumptions will not be valid (for instance because an area of the disk is being used for temporary storage, or because a filesystem is not entirely valid for whatever reason), and in that case, it's possible that blocks that appear (from the partitioning tool's perspective) to have been successfully written to the Drobo haven't actually been stored at all.

This isn't a criticism of Drobo per se. It just means that it isn't likely to be compatible with live repartitioning tools in general.

The situation is actually particularly bad for iPartition, partly because we try to be smart about the way we move data about the disk and partly because we deliberately make the partition map look invalid while we're working on it (we do this so that users will use the recovery feature in iPartition if something goes wrong rather than blundering in with some other disk utility and trashing their data as a result).

Incidentally, we've asked Data Robotics more than once now to add some text to their product FAQ, which currently claims incorrectly that Drobo is compatible with all disk utilities. It is not, and indeed it cannot be.

Actually, this is much the better solution in some respects, its not actually an application, but an Automator script to make easy a method of creating a DiskImage (.dmg) as the ultimate destination of your Time Machine backup, as such it doesn't hack any prefs *nor* is it Drobo specific.

The only part of that which is a mystery is "0017f202b9ec", and that's just your MAC address. You can get that on the command line (ifconfig en0 | grep ether) or via the System Profiler application.

Knowing the command Time Tamer uses, I'm not sure why anyone comfortable with Terminal would use the script over typing customized commands into Terminal. Time Tamer may save you from having to copy and paste a command, but it does little more than that (again, for those comfortable with Terminal). Perhaps it can be upgraded to be useful to more people. For example, it would be more useful if:

It told you what the largest size you could set your backup to be to avoid the "slows to a crawl" pace.

It suggested that size - but let you change it - rather than assuming.

It offered to let you change the name of the backup volume.

It might have to ask you what the usable size of your current disk is, but most people can do that. It's right in their Drobo Dashboard.

Using this information, is it suggested that I format the Drobo to 16 TB, create a sparseimage with a size of ~1.2 TB (1228 GB), and leave it at that? If so, you may have all convinced me. A sparsebundle can change its size quite easily: hdiutil resize -size 1500g. Does everyone here just format their Drobo for 16 TB and use hdiutil to limit their backup sizes?

Erik, I'm sure that you're happy with hdiutil, but didn't know how many others were

My Drobo(v2) is declared as 16TB up-front, currently with 4x 1TB drives, so I'm a way from filling it this month, most of the content is media ... my laptop's drive is 200GB, so I've got a 500GB sparseimage sitting on the Drobo, as a 'fit and forget' type size for TM. Its not too big to handle nor too easy to fill up ...

Overall, I find the Drobo flexible but irritating also, I find the lack of info regarding its proprietary storage a little worrying and also it seems to lead to quite a few unknowns (50% thresholds and thrashing, re-organisations, etc). Its been in place now for about 3-4months and whilst its been reliable so far I think it will eventually give way to a simpler SATA drive enclosure with ZFS (Raid-Z/Z2) managing the disks and iSCSI/CIFS/NFS access, then I get compression, snapshotting, etc as well as the flexibility.

Overall, I find the Drobo flexible but irritating also, I find the lack of info regarding its proprietary storage a little worrying and also it seems to lead to quite a few unknowns (50% thresholds and thrashing, re-organisations, etc). Its been in place now for about 3-4months and whilst its been reliable so far I think it will eventually give way to a simpler SATA drive enclosure with ZFS (Raid-Z/Z2) managing the disks and iSCSI/CIFS/NFS access, then I get compression, snapshotting, etc as well as the flexibility.

Indeed. I can't say I'm thrilled at this point with the Drobo, but it works as advertised, so I'm not disappointed either. I'm neutral. It just "is."

… when the drobo gets 90% filled with data, the speed at which it writes data goes down to an absolute crawl and it can start to cause issues. not to mention the drobo itself starts to scream at you to replace your drives with bigger ones.

Incorrect. Drobo starts to get slow at 95% full.

At 85% full, Drobo turns an indicator LED yellow over the smallest drive (or top drive if they are all the same size) as a warning. It will also send an email if you have enabled email alerts. If you continue writing data to it, at 95% Drobo turns the LED red instead of yellow, an optional email alert if you used them. If you continue to ignore Drobo and not add space, it starts to slow down. Sort of its last way to get your attention.

Re: TimeTamer
Actually, this is much the better solution in some respects, its not actually an application, but an Automator script to make easy a method of creating a DiskImage (.dmg) as the ultimate destination of your Time Machine backup, as such it doesn't hack any prefs *nor* is it Drobo specific.

I'm glad you agree. Time Tamer was created for those uncomfortable with the command line. For more advanced users, Time Tamer writes a "README" file with the specific command - command-line savvy users can cut and paste this as a starting point… really, how many of us remember all of hdiutil's options?

Incidentally, we've asked Data Robotics more than once now to add some text to their product FAQ, which currently claims incorrectly that Drobo is compatible with all disk utilities. It is not, and indeed it cannot be.

Your requests must not be reaching the right place. Email me at mfuccio [at the Drobo domain] and we can get it rolling.

Can anyone get the Drobo (attached as an airdisk) to show up as a backup volume in the Time Machine settings without using the "tmunsupportednetworkvolumes" terminal hack? Or is the terminal hack necessary?

It seemed like the simplest method, so I tried the command the other day (assuming the command in the first comment as correct--what do I know?). I didn't notice until this morning that TM hadn't backed up for two days.

It's working again now with a custom MaxSize (using the -integer option), and I'll be a bit more cautious before trying something like that next time. In the mean time, does anybody know how to set MaxSize back to its default value? Or what the default value is?

It's working again now with a custom MaxSize (using the -integer option), and I'll be a bit more cautious before trying something like that next time. In the mean time, does anybody know how to set MaxSize back to its default value? Or what the default value is?

The default MaxSize value on my machine, where I haven't fiddled with it, is 0.

@latchkey has made a great contribution for Drobo and DroboShare users -- he ported afp and bonjour (actually, avahi) to run on DroboShare in his "backupmyfruit" package. He has also enhanced the Time Tamer script in various unspecified ways and is promoting them in many places.

I am using his backupmyfruit package, but not his Time Tamer replacement. Two reasons: 1) you only create a sparsbundle once, and 2) unsubstantiated claims about why his unnamed script is different.

@Erik:
1) My script comes with source code on the download page so you can see for yourself what it does.
2) I've explained myself in other forums (including the page where you download Time Tamer), but I'll repeat myself here (apologies for upsetting you):

Here are the two major problems with TimeTamer and what my script does differently:

a) Time Tamer doesn't include the nospotlight option so you also get spotlight indexing your bundle which is a waste of disk space and computationally expensive.
b) The default sparse band size is 8megs which is too small for backups. You really should make it 64megs because otherwise you get 1024 files per gig instead of 16. This makes a huge difference in speed when doing things over a network.

My script also sets the 'defaults write...' option for you so you don't have to manually do it.

@MarkFuccio: Just re-create your sparsebundle using my script and start backups again. Rename your old one until your backups have been fully completed and then you can just delete it.

Yes, as much as I love the Drobo, I think it is messed up that Data Robotics keeps visibly promoting TimeTamer when it is really not a 100% rock solid solution.

a) Time Tamer doesn't include the nospotlight option so you also get spotlight indexing your bundle which is a waste of disk space and computationally expensive.

Some people may want the option to search their backup volume with Spotlight. Just pointing that out here in case anyone does. Can the "-nospotlight" feature be added to the bundle later on? Is it as simple as rm -r /Volumes/Backup/.Spotlight-V100; /usr/bin/mdutil -i off /Volumes/Backup?

b) The default sparse band size is 8megs which is too small for backups. You really should make it 64megs because otherwise you get 1024 files per gig instead of 16. This makes a huge difference in speed when doing things over a network.

I certainly have more than 16 files per GB backed up on my current (Time Tamer script-created) Sparse Bundle, so perhaps you can explain what that means. (And I'm not backing up over a network, obviously.)

In the script I just pulled from your action, it's 131072. Divided by 64, that's 2048 - or double the awfully standard 1024. In other words, 131072/128 = 1024. So have you chosen 64M or have you chosen 128M in your script and, again, what's that really matter? What's the impact?

I also note that you're using case-sensitive journaled HFS+. Any comment on that? Why? Can it cause any problems?

All of the research I've done is that is the right filesystem to create in this case and my testing (full system restore) has proven that it is an acceptable parameter. Can it cause problems? I really don't know how it would. Just like the other parameters, you can change it to be whatever you want.

Some people may want the option to search their backup volume with Spotlight. Just pointing that out here in case anyone does. Can the "-nospotlight" feature be added to the bundle later on? Is it as simple as rm -r /Volumes/Backup/.Spotlight-V100; /usr/bin/mdutil -i off /Volumes/Backup?

Why anyone would want to be able to search for something they can already search for locally seems a bit odd to me other than if they happen to delete a file and want to search for it by the contents of the file.

Can it be added later on? I don't know. Check the hdituil man page.

If you are creating sparsebundles over the network, then all that indexing goes over the network. The speed hit is obviously pretty heavy.

In the script I just pulled from your action, it's 131072. Divided by 64, that's 2048 - or double the awfully standard 1024. In other words, 131072/128 = 1024. So have you chosen 64M or have you chosen 128M in your script and, again, what's that really matter? What's the impact?

The math is this: (131072 * 512 byte sectors = 64m). Each band file is ~64m instead of 8m.

My testing showed that mounting a disk image over the network with 64m bands was significantly faster than with 8m.

1. How do you get Time Machine to see the sparsebundlee file? I have created the sparsebundlee file with latchkey's automater action package which it puts on my desktop. I move it into one of my Drobo files but Time Machine will only identify the two Drobo files and not the sparsebundle that is within one of them.

2. Isn't anyone concerned about the 16 minute boot time that is shown by Drobo Dashboard when the Drobo file size is set at 16 TB?

@Lloyd: When I met one of the Drobo guys at Photokina this year I asked him about the long boot time. He said that this only relates to the occassional scandisk on Windows. There no performance hit on a Mac resulting from the size of the Drobo partition.

I've set this up using a sparse bundle on an external (locally attached) hard drive according to your exact instructions, and Time Machine appears to be backing up regularly.

However...

When I enter the Time Machine interface to go back in time to view changes/files from past snapshots, it does NOT show any backups! The interface only shows the current file system, and I can't use the GUI to view older files that were deleted/changed.

I can mount the sparse bundle and look inside to verify that the snapshots are being done correctly, and I do see older deleted files in past snapshots, but apparently the GUI doesn't like using the sparse bundle solution you've outlined here.

Joe: There is. When you want to restore a file from a sparse bundle, mount the sparse bundle manually. Then option-click the TM icon in the menu bar. You'll notice that the "Enter Time Machine" entry has changed to "Browse Other Time Machine Disks". Use this option, navigate to your sparse bundle and -- lo and behold -- all your backups are there.

When you want to restore a file from a sparse bundle, mount the sparse bundle manually. Then option-click the TM icon in the menu bar. You'll notice that the "Enter Time Machine" entry has changed to "Browse Other Time Machine Disks". Use this option, navigate to your sparse bundle and -- lo and behold -- all your backups are there.

That's weak. I moved away from using my Drobo for Time Machine backups because I didn't know that trick and thought the Time Machine backup was broken somehow.

Don't feel bad, Erik. I also thought Time Machine was broken in some way, since I didn't know "the trick" (and by the way, I haven't even tried "the trick" yet, but I'm going to in a minute). However, I found that you can navigate through a Finder window to the sparse bundle and pluck old files out one by one like that. But that's nowhere near as nice as the groovy TM spaced out interface.

I have a Drobo connected to a Mac Mini and shared over the network. I want to use it to back up both the Mini and my MacBook Pro.
I created two sparsebundles with your script, one for each machine. I cloned the Mini's old TM backup volume to the new sparsebundle using SuperDuper, and everything works great on the Mini. I started fresh with the MacBook Pro as follows:

1) Used TM to backup to the new sparsebundle from the laptop to an attached USB drive.

2) Plugged the external drive into the Mini, and copied the sparsebundle over to the Drobo.

3) Mounted the sparsebundle on the laptop, over the network, and verified (using mdutil -s) that Spotlight was disabled.

4) Pointed TM on the laptop to the Drobo.

Et voila, Spotlight tries to index the backup volume.

I can re-disable Spotlight on the backup volume, but every time TM starts up again, Spotlight does as well. Any tips for making it STAY off?

Thank you guys for figuring this stuff out! Santa brought me a Drobo and an Airport Express and setting up the sparse bundles (one each for my computers) on a 16TB Drobo partition solved all my problems.

The only thing remaining is that, if I plug in the Dorbo directly to my computer, Time Machine can't find the backup volume (even if I manually mount the sparse bundles). This is only a slight nuisance, but would speed up the initial backup. I guess I could make an initial TM backup somewhere else and manually move it into the sparsebundle.

Finally one more puzzle for you: Is it possible to put the Drobo into standby mode while it is attached to the AE?

I'm going to go with the sparseimage approach, despite the need to manually mount it when you want to use Time Machine to browse.

Here's my question, though. On the Time Capsule, it creates multiple sparseimage files if you have multiple computers backing up to it. I don't think they have maximum file sizes on their sparseimage files, do they? How do we verify that in hdiutil? I tried on my existing sparseimage file from my Time Capsule and I got a very long number that isn't divisible by 1000 or 1024.

And so this brings up the question - if I want to back up two computers to my drobo using sparseimage files, then let's say I have 1.2 TB of usable space. Do I need to make each sparseimage be a max size of 600GB? Or should they both be 1.2TB, and is Time Machine smart enough to know when to start deleting files if they both get large?

I made my images slightly larger than the size of the disks that I'm backing up.

a) I don't require a long history of changes.
b) I don't expect the drive I'm backing up to fill up, thus the number of changesets will continue to cover a long enough period in time.

I based this off my TM usage at work where I have two hard drives in my desktop machine. The main drive size is 232GB (62gb used) and the backup drive is 279GB . This leaves me with 81 folders going from today back until 06/2008 (~6months) and 3.19gb currently available on my backup drive.

Dan and Derek, see the comment by Alexander from December 24. You have to open Time Machine by doing Option-Click on the TM icon instead of a regular click. That's the "trick" to allow you to open a sparse image and see past backups in the fancy Time Machine GUI.

I have Drobo II with 4 one Terabite drives installed. I created a separate 650 Gb partition on Drobo for TimeMachine. I have TM backup everything except my Pictures, Movies and Sound files (these are my largest files) which I copied unto the primary Drobo partition manually. I use ChronoSync to synchronize these files from my Intel Imac 24 Express to the Drobo primary partition.

Everything is working fine. TM is always available with no need to install it or manually access it. Backups are working well and are always available.

As I noted earlier, I attempted to create a sparcebundle but was not successful. Presently, I cannot understand what its advantage could be.

Yes, I can see that trying to increase a TM partition would be undesirable. But if you load Drobo with four 1 terabyte drives (they are available for about $85.00 apiece) and assign about 500 GB to a TM partition it would seem unlikely that a resizing of that partition would be necessary, especially if TM is used to backup only the most basic data, and special data such as Pictures, Movies, Sound etc. are backed up to Drobo outside of the TM protocol.

Another advantage of this approach is that TM will only remove the oldest of the backed up material when it gets full and that can be examined before TM discards it. Since most day to day data from Documents, Downloads, all Libraries and System files only amounts to about 21 GB and since TM only synchronizes these files and does not replicate them with each back up, the 500 GB partition should last quite a while and can be copied to a different drive as an archived backup should that become necessary.

@Erik: You start with a fresh sparsebundle. You don't try to resize an existing one. Rename the old one and then create a new one in its place. Once the backup has finished and/or your archival history needs are satisfied, then you just delete the old one. Still, this is far better than reformatting your entire drobo.

I've found another problem with the sparseimage approach. I tried to do a clean install of Snow Leopard and then a restore from my TM backup on a sparse image. No go. The installer doesn't see the TM backup when its on a sparse image. The only way I could see how to do this is to do a once-off TM backup onto a local disk and then do a snow leopard install.

Andy, I'm not sure I follow you. I'm not using droboshare - which part of the instructions on your setupguide should I be looking at for a clean Snow Leopard install? Here's what I do:
- Boot with Snow Leopard install DVD
- Select Utilities, erase disk with disk utility
- Install SL
- When SL boots on install disk, select copy info from TM backup
And this is where the installer can't see the TM backup that's on a sparse image.

Hello this is great work people! I am frustrated by the lack of information from Apple & Drobo on this....

I have a Drobo I want to hook up to my Airport Extreme and use Time Machine to back up 3 Macs to it. I also need to store some shared files on it too that we all use in our home.
I intend to format the Drobo to 8GB Partition and use Sparse Bundle.

Does anyone know if 3 macs will be ok backing up to the same drive on the Drobo (I'll do the initial large back up wired with ethernet from each mac)

Does Time Tamer work for 3 macs?

any help would be appreciated...maybe I am missing the point just want to make life as simple as possible

Does backmyfruitup work on a Drobo that is directly connected via Firewire/USB, or only through Droboshare?

Another downside to partitioning, that I just discovered. I had my Drobo set as a 16gb volume (with four 1.5tb drives, i.e. 4tb usable space); I set the first partition at 1tb for TimeMachine use, the rest for usable data/media space. However, only the TimeMachine partition showed up in Drobo Dashboard. I contacted Drobo and they said the latest version of Dashboard doesn't support seeing multiple partitions, only the *first* one. So, it would never give me a true reading of the actual usable space left on the Drobo, since it was "ignoring" the other (larger) partition.

The DroboShare is a small embedded linux computer with USB and Ethernet ports.

BackMyFruitUp is a port of netatalk (and about 10 other pieces of dependent software) to the (limited) version of linux that runs on the DroboShare. This is software that runs on the DroboShare and provides AFP (Apple File Protocol) and Bonjour services.

When compared to, say, a USB drive connected to AirPort Extreme, or simply a USB/Firewire drive connected to my Mac and then shared over the network, is the main advantage of DroboShare the speed (i.e. gigabit ethernet)?

The speed is limited to the fact that the DroboShare connects to the Drobo over a USB2.0 connection. Also, the DroboShare is essentially a vastly underpowered computer (ie: slow).

That said, I get about 2mb/sec TM backups over wireless from my Macbook Pro laptop to my Drobo/DroboShare. I rarely even notice it is running. I usually do the first backup with the computer plugged into a hub and then the rest over wireless. It is more than acceptable speed for a very reliable home backup solution.

I've also heard that BackMyFruitUp is significantly faster than using SMB to talk to the DroboShare. SMB is the default protocol that DataRobotics uses. DO NOT USE SMB to do TM backups. You *have* to use BackMyFruitUp or you risk data loss.

Oh, if you use BackMyFruitUp, please be sure to donate a tiny bit to me. I spent a lot of time creating this solution and I spend a lot of time in various forums (like here) answering questions and helping people. Thanks so much.

I was very happy to find this posting. I have been a Time Capsule (500gig) for the past year or so, and have been contemplating upgrading to the 2 Tb model ($$$).

I have 5 computers that have been backing up to the Time Capsule, via Ethernet, and have found my main desktop is a space hog, and ends up bumping out the other computers as the TC gets filled.

The TC has also acted up several times, requiring a reset and re-installation, so my confidence in it is weakened - thus a Drobo solution, which I know has been reliable from experience, would be preferred.

I read about using Drobo as a Time Machine backup destination so bought one (my third). The unit and 2 x 1 Tb drives was still cheaper than a new 2 Tb TC.

For the past 8 hours, I have been unable to get the Drobo to be seen by Time Machine and accepted for backups. I keep getting "The backup disk is not available" errors, unless the Drobo is directly attached to the computer. I have run Time Machine while the Drobo was attached to a Mac mini. The mini backed-up okay, but none of the networked Macs would.

I connected the Drobo to my Airport Extreme, and now no Mac's will back-up

I tried running the terminal script used by Time Tamer, no go, and found Time Tamer and ran it on 3 of my macs. It did create the sparsebundle files on my Drobo - BUT, Time Machine STILL doesn't run a back up - "The backup disk is not available" errors continue.

It seems something happened since the writing of this article and now? Snow Leopard? 10.6.1 update? or changes to the Drobo firmware?

I am still having Drobo/Time Machine/Airport Extreme problems (I do not have Droboshare, just the Extreme) none of my 3 macs will work with Time Machine. I have spend ages on this in the last 2 months after buying a second Drobo to hang off the extreme for the same reasons as you.
Firstly when backing up Time Machine wirelessly I got 'Error 109" which no one seems to know what that it is but may to be related to Snow Leopard, then after taking 3 days to back up my 500GB MacBook I get the spinning message ' cannot mount backup' when its supposed to be backing up. I also used the 'Create Backup Volume' from BackMyFruit http://code.google.com/p/backmyfruitup/ up to create a sparsebundle specific to each mac to load onto the Airport Drobo.
I posted on the Apple forums and someone suggested changing my computer names to have no punctuation and less that 13 characters and lower case. I then deleted the original sparsebundels and created new ones, loaded them onto the Drobo and waited another 3 days to back up my macs, but same error again 'cannot mount backup'
I've almost had it with this - Drobo support told me in September it should work and a shared/airport Drobo was my great? idea as I was able to take the older 4x1TB drives and put them in the shared Drobo then upgrade my main Drobo with 4 x 2TB's so finding a great way to upgrade as I am not happy with the Time Capsules fixed capacity.
For now I am using SuperDuper which works fine to clone my drives to the Drobo.
So if anyone else can help that would be really useful, I am getting to the stage where I think it would be easier to sort out the political situation in Zimbabwe than get my 3 macs to back up to Time Machine on my airport extreme Drobo. HELP!

I gave up on the sparse image approach, and just repartitioned my Drobo into two drives. One is just for backups, and Time Machine can use all that partition. The other partition is for everything else. It's been working great this way for the past 10 months.

latchkey, is there anything about the sparsebundle approach that is technically inferior to just creating a separate drobo partition?

My sparsebundle (created by your automator action) got corrupted after about six months of use. disk utility just spun and gave no output; fsck_hfs went quiet at rebuilding the index (I had to "attach" rather than mount); disk warrior gave up by saying there wasn't enough RAM (I have two gigs, should be enough), and I'm out of ideas on how to repair it. Should I be doing a different approach?

This is a snow leopard macbook pro backing up wirelessly to a drobo that is connected through a firewire cable to my mac pro. The mac pro is also backing up to a sparsebundle but that's been going fine.

The only way I got this to work is to hook up the Drobo directly to my iMac and use it via sharing preferences so my 2 MacBooks can work with Time machine, I gave up using it with my Airport extreme as it kept failing.

@Curt, I've never seen or heard of an issue like that. I've been backing up to the same sparsebundles since last June (using BackMyFruitUp running on a DroboShare). Maybe my time is almost up. =)

I recently got a PogoPlug from the guys who make it (I went by their offices and met them, very nice smart guys). I'll be porting BMFU to that as soon as I get a chance to work on it. It will make a great alternative solution to a DroboShare/Mac Share.

I'm going to try a few more times, maybe re-creating the sparsebundle manually, then I'm going to have to revert to using fixed partitions created via Dashboard.

Nope, no luck at all. backupd is freezing every time.
I posted on the Apple forum about this and no help there either. Someone also said, btw, that in OSX 10.6.3 TimeMachine automatically resizes its sparsebundles to the size of the disk its on, so not sure this method is now going to work ...

I'm the author of BackMyFruitUp. I'm working on porting netatalk 2.1 to the DroboShare (which is pretty much done), but like you said... 10.6.3 kind of screws us with this auto resizing thing. I may end up having to find another way to do things. I'm working on it though.

I don't get it. I have a macbook pro and a mac pro both backing up to sparsebundles on my Drobo, and my software is fully updated, and it's continuing to work fine. Is it because I created the sparsebundles on a version before 10.6.3 even though I'm using 10.6.3 now?

[...] Machine. Using a Drobo with Time Machine can be a bit painful, but my friend Erik has posted an excellent blog post about how to make it work. I’m quite happy with this setup, as I can have multiple drives [...]

Create a share using the Drobo Dashboard and select the Time Machine option. Again, in the the Drobo Dashboard, choose Settings > Shares and choose the mount check box for your new Time Machine Share (this may take a while to mount). Now go to your Time Machine System Preferences and the volume should be available now for backup.