Formatting the Drobo for Time Machine Backups
Posted November 11th, 2008 @ 02:54pm by 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% ((Please see this comment for more on this number.)) 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:40
I'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:
hdiutil create -size 1024g -fs HFS+J -volname "Time Machine Backup" /Volumes/Mimzy/Bunny_0017f202b9ec.sparsebundle
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."
You can also approximate your "actual size" with the Drobolator.
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 now ((My Mac Pro got the four 1 TB drives that came with the Drobo.)) 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 space ((Again, ~1.35 TB in my case with four 500 GB drives - use the Drobolator to figure out your actual size.)), 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 observed ((Everyone who tested, regardless of the kind of data they had, reported that Disk Utility always showed the files as unfragmented and always occuping the "beginning" portions of the disk.)). 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).
Posted 12 Nov 2008 at 3:15pm #
Instead of formatting or limiting your Drobo, you can change the maximum size allowed for the TimeMachine backup.
Type this command in the terminal where the size is specified in MB (100MB in this case).
defaults write /Library/Preferences/com.apple.TimeMachine MaxSize 102400
I found this hint in a comment by "dfbills" on this blog post: http://emperor.tidbits.com/TidBITS/Talk/1908
Posted 12 Nov 2008 at 3:21pm #
...or you could use the "TimeTamer" DroboApp to limit the size of your Time Machine backups:
http://www.drobo.com/droboapps/downloads/index.php?id=16
Posted 13 Apr 2009 at 12:25am #
does running the time tamer automator script erase any existing data you may of had on the drobo?
Posted 12 Nov 2008 at 3:22pm #
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.
http://support.apple.com/kb/TS1550?viewlocale=en_US
Posted 12 Nov 2008 at 3:48pm #
[quote comment="50700"]Instead of formatting or limiting your Drobo, you can change the maximum size allowed for the TimeMachine backup.[/quote]
This is another option, albeit one that could fail if the preferences file is ever deleted or becomes corrupt.
[quote comment="50702"]Are you using a PPC Mac? If not, unfortunately that's not going to work for you.[/quote]
Word of caution to those who still have PPC Macs. Format in Disk Utility or at least check the partition format before doing certain things with the Drobo.
Posted 12 Nov 2008 at 3:55pm #
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
Posted 12 Nov 2008 at 3:57pm #
In retrospect, this seems painfully obvious. Nicely done.
Thanks too for posting this; I'm about to buy a Drobo off a co-worker, and being aware of just how dissonant Drobo and OS X are with respect to the drive size is good to know.
Posted 12 Nov 2008 at 4:05pm #
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.
This works great for me.
Posted 02 Sep 2009 at 10:55pm #
I have done the same thing however no files are on the drive that I partitioned for my Time Machine...any advice?
Posted 12 Nov 2008 at 4:15pm #
A question: when I decide to add actual capacity to my Drobo by adding new drives will I be able to just open up DU and expand the partition?
I assume the answer is yes.
Posted 12 Nov 2008 at 4:16pm #
You know, Data Robotics strongly warns against using 10.5's live partitioning on a Drobo.
http://bit.ly/drobo-partition
"Warning" isn't even quite the right word, as they state without caveat that "Should you repartition the Drobo drive you will lose the data on the drive." I'm a little surprised it worked.
Posted 12 Nov 2008 at 4:27pm #
Nice. I didn't realize Disk Utility could resize partitions...
Posted 12 Nov 2008 at 4:29pm #
[quote comment="50712"]A question: when I decide to add actual capacity to my Drobo by adding new drives will I be able to just open up DU and expand the partition?[/quote]
You may or may not be able to do so. I was, and so were some friends, but I wouldn't bet on it. It's your data, so be careful.
[quote comment="50713"]You know, Data Robotics strongly warns against using 10.5's live partitioning on a Drobo.[/quote]
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).
Posted 12 Nov 2008 at 4:32pm #
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.
Posted 12 Nov 2008 at 4:36pm #
I love the icon of your Drobo disk. Is this anywhere available?
Posted 12 Nov 2008 at 4:37pm #
[quote comment="50715"]
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.
[/quote]
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
Posted 12 Nov 2008 at 4:43pm #
[quote comment="50715"]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."[/quote]
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.
[quote comment="50715"]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.[/quote]
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.
Posted 12 Nov 2008 at 4:50pm #
[quote comment="50716"]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.[/quote]
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. ๐
[quote comment="50717"]I love the icon of your Drobo disk. Is this anywhere available?[/quote]
All of my disks have a "rabbit" theme, currently. I used these icons.
[quote comment="50719"]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.[/quote]
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.
[quote comment="50719"]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.[/quote]
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?
Posted 12 Nov 2008 at 5:59pm #
[...] interesting blog post describing how best to set up a Drobo for time machine backups. There are some more suggestions [...]
Posted 12 Nov 2008 at 6:02pm #
[quote comment="50720"]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?[/quote]
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.
[quote comment="50714"]Nice. I didn't realize Disk Utility could resize partitions…[/quote]
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.
Posted 12 Nov 2008 at 9:13pm #
My repartition from 2TB to 1.36 has been going for 4 hrs ๐ฏ
Posted 13 Nov 2008 at 1:16am #
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.
Posted 13 Nov 2008 at 2:03am #
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. ๐
Posted 13 Nov 2008 at 4:19am #
So, after 12 hours - it finished!
Posted 13 Nov 2008 at 7:51am #
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.
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.
Posted 13 Nov 2008 at 8:13am #
[quote comment="50725"]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.[/quote]
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.
Posted 13 Nov 2008 at 8:23am #
[quote comment="50746"]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.[/quote]
Time Tamer runs this script:
hdiutil create -size 1862g -fs HFS+J -volname "TM-backup-of-Bunny" /Volumes/Mimzy/Bunny_0017f202b9ec.sparsebundle
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 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?Posted 13 Nov 2008 at 8:45am #
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.
Posted 13 Nov 2008 at 11:09am #
[quote comment="50750"]Erik, I'm sure that you're happy with hdiutil, but didn't know how many others were ;-)[/quote]
Stupidly, my initial resistance to Time Tamer was due to the fact that I thought it was just an Automator script that wrote out the MaxSize preferences.
When I learned that it was just a sparseimage creator, it prompted the re-write of this article.
Like yours, my Drobo is now a 16 TB device. I set the sparseimage size of 1225 GB (a bit less than 1.2 TB, which is itself below the 90% threshold of 1.215 TB).
[quote comment="50750"]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.[/quote]
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." ๐
Posted 13 Nov 2008 at 7:50pm #
Mark F. here from drobo.com…
Drobo is a virtual storage array. It has some properties and behaviors that are different from traditional fixed-capacity drives or storage arrays.
[quote comment="50740"]… 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.[/quote]
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.
[quote comment="50746"]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.[/quote]
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?
[quote comment="50748"]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.[/quote]
Your requests must not be reaching the right place. Email me at mfuccio [at the Drobo domain] and we can get it rolling.
Posted 14 Nov 2008 at 3:59am #
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?
Posted 14 Nov 2008 at 10:28am #
The very first comment above has some erroneous information. The command line should look like this:
defaults write /Library/Preferences/com.apple.TimeMachine MaxSize -integer 100000
Without the "-integer" option, it stores the number as a string, causing Time Machine to stop working.
(I found the correct info at the end of this thread on Apple Support Discussions: http://discussions.apple.com/thread.jspa?messageID=8163455 )
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?
Posted 14 Nov 2008 at 12:09pm #
[quote comment="50768"]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?[/quote]
The default MaxSize value on my machine, where I haven't fiddled with it, is 0.
Posted 14 Nov 2008 at 12:21pm #
Ah, that make sense. Thanks!
Posted 14 Nov 2008 at 1:26pm #
[...] learned that the Drobo slows down only when it hits 95% capacity, not 90%, I decided to up the maximum size of my backup drive slightly1. I figured it would also be a good [...]
Posted 16 Nov 2008 at 8:53pm #
TimeTamer shouldn't be used. It doesn't pass enough options to hdiutil. I wrote an alternative Automator action that passes all the right parameters.
http://code.google.com/p/backmyfruitup/
I also have a solution for backups over AFP to a DroboShare.
Posted 16 Nov 2008 at 9:05pm #
[quote comment="50814"]TimeTamer shouldn't be used. It doesn't pass enough options to hdiutil. I wrote an alternative Automator action that passes all the right parameters.[/quote]
If you're going to come on here and say something like that, I think duty binds you to at least provide the proper script here or elaborate on exactly what options aren't passed that should be passed.
Posted 16 Nov 2008 at 10:49pm #
@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.
Posted 17 Nov 2008 at 1:50am #
@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.
Posted 17 Nov 2008 at 7:54am #
[quote comment="50821"]1) My script comes with…
2) I've explained myself in other forums…[/quote]
I still don't know why you couldn't just have posted it here. It probably would have saved us all some time.
hdiutil create -nospotlight -imagekey sparse-band-size=131072 -size 1225g -fs "Case-sensitive Journaled HFS+" -volname "Backup of Bunny" /Volumes/Mimzy/Bunny_0017f202b9ec.sparsebundle
Bold is where a user would make the appropriate changes as discussed above.
I also note that you're using case-sensitive journaled HFS+. Any comment on that? Why? Can it cause any problems?
[quote comment="50821"]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.[/quote]
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
?[quote comment="50821"]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.[/quote]
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?
Posted 17 Nov 2008 at 11:53am #
[quote comment="50823"]I also note that you're using case-sensitive journaled HFS+. Any comment on that? Why? Can it cause any problems?[/quote]
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.
[quote comment="50823"]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
?[/quote]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.
[quote comment="50823"]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?[/quote]
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.
Posted 26 Nov 2008 at 8:30am #
[...] Formatting the Drobo for Apple Time Machine [...]
Posted 08 Dec 2008 at 12:12pm #
[...] I followed Erik J. Barzeski’s instructions to configure Time Machine to backup to a sparse bundle disk image on my Drobo. I wasted a lot of [...]
Posted 11 Dec 2008 at 1:30am #
Two Questions:
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?
Posted 19 Dec 2008 at 4:33pm #
Pretty interesting discussion here, very informative, too:
@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.
Posted 14 Dec 2008 at 8:52am #
[quote comment="51382"]How do you get Time Machine to see the sparsebundlee file?[/quote]
It's automatic. Create it on your Drobo at the root level and select the Drobo itself as the backup source.
[quote comment="51382"]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?[/quote]
It doesn't take 16 minutes. In fact, it seems to take the same amount of time.
Posted 22 Dec 2008 at 7:10pm #
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.
Has anyone else experienced this problem? Is there a solution?
Thanks.
Posted 24 Dec 2008 at 5:28am #
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.
Posted 24 Dec 2008 at 4:06pm #
Alexander:
THANK YOU!!!
Now I can finally use my Drobo properly, and limit the size of my Time Machine backups using sparse bundles.
If you're ever in Chicago, the drinks are on me!
Best,
Joseph.
Posted 24 Dec 2008 at 9:03am #
[quote comment="51717"]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.[/quote]
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.
So much for "it just works."
Posted 30 Jan 2009 at 10:50pm #
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.
Posted 24 Dec 2008 at 11:47am #
If you use a Drobo+DroboShare and my BackMyFruitUp project, then "it just works". So, yes it is another $200 to solve your problem, but at least you don't have to waste money on a TimeCapsule. =)
Posted 20 Jan 2009 at 2:11pm #
@latchkey (or any Spotlight guru):
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?
Posted 28 Dec 2008 at 6:06am #
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?
Posted 26 Jan 2009 at 9:01pm #
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?
Posted 26 Jan 2009 at 9:31pm #
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.
Adjust your images appropriately.
Posted 29 Jan 2009 at 10:46am #
Hey Guys,
Thanks for all the advise above, I have created a sparse image and multiple time machine backups have succeeded. However when I open time machine I can only see the most recent backup?
Any Ideas why?
Thanks,
Dan
Posted 29 Jan 2009 at 11:00am #
[quote comment="52498"]However when I open time machine I can only see the most recent backup?[/quote]
Scroll all the way up. Read the first paragraph.
Posted 31 Jan 2009 at 12:18pm #
Dan,
I have the same problem. Mac Mini (OS X 10.5.6) using a Drobo (firmware 1.3.0 [1.248.15408] and dashboard 1.2.4 [1092]) and I am also only able to see Today's backup in Time Machine.
If you are able to solve the problem I'd sure appreciate hearing from you (and vice versa).
Sincerely,
Derek Iverson
Posted 31 Jan 2009 at 4:15pm #
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.
Posted 29 Jan 2009 at 4:12pm #
Hey Erik - actually, I don't think it's as big of a deal as it seems or as you make it sound. I'm doing the sparseimage to the Drobo, and the first time, I had to mount it and choose it.
But each time afterward, even after restarting, it works as you'd expect. I just enter Time Machine, and everything just works.
Posted 29 Jan 2009 at 4:30pm #
[quote comment="52505"]But each time afterward, even after restarting, it works as you'd expect. I just enter Time Machine, and everything just works.[/quote]
Roger that. I still don't think the Drobo makes a great Time Machine disk for the other reason(s) discussed here and elsewhere.
Posted 29 Jan 2009 at 5:45pm #
General Comment:
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.
Posted 29 Jan 2009 at 6:17pm #
The advantage is that you don't have to partition your Drobo.
Posted 29 Jan 2009 at 6:26pm #
I realize that but what is the drawback to such a partition?
Posted 10 Feb 2009 at 12:25am #
The drawback is that if you ever want to increase your TM partition (say to match an upgrade in the size your primary drive), you basically have to reformat your entire Drobo.
With the sparsebundle, you just run a command.
Tricks to getting it to work are:
- Follow the instructions, including the exact naming convention.
- It must sit in the root folder of your Drobo.
Posted 10 Feb 2009 at 9:04am #
[quote comment="52740"]With the sparsebundle, you just run a command.[/quote]
Don't be so sure: Resizing a Sparsebundle Fails.
Posted 10 Feb 2009 at 1:13pm #
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.
Posted 10 Feb 2009 at 10:21am #
[quote comment="52361"]
...
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?[/quote]
Update on my issue: after I gave in and let Spotlight index the mounted sparsebundle once, it hasn't bothered me again. Every now and then I see it indexing, but it only lasts a few seconds.
Posted 10 Feb 2009 at 11:54am #
@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.
Posted 10 Feb 2009 at 12:16pm #
[quote comment="52750"][quote comment="52740"]With the sparsebundle, you just run a command.[/quote]
Don't be so sure: Resizing a Sparsebundle Fails.[/quote]
Ok, wow, I did not know that! Wow that's a pretty major bug.
Perhaps you could add this as a warning in your original article.
Posted 26 Feb 2009 at 11:53am #
[...] mostly followed the “use sparse image” section from this post. here is what i did step by [...]
Posted 15 Jun 2009 at 5:01pm #
[...] do it all via the terminal, Iรขโฌโขm happy at the command line, so following the instructions over on nslog.com I went about it like [...]
Posted 30 Aug 2009 at 9:28am #
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.
Posted 30 Aug 2009 at 12:14pm #
Did you follow the directions for restoring?
http://code.google.com/p/backmyfruitup/wiki/SetupGuideVersion2
Posted 30 Aug 2009 at 4:44pm #
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.
Posted 02 Sep 2009 at 3:58am #
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
Many thanks Shaun ๐
Posted 02 Sep 2009 at 3:59am #
...sorry on last post I meant do the initial Time Machine back-up with firewire.
Posted 21 Sep 2009 at 11:06pm #
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.
Posted 22 Sep 2009 at 11:43am #
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.
Posted 22 Sep 2009 at 12:51pm #
Got it. Now you've got me wanting to buy a DroboShare. ๐
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)?
Posted 22 Sep 2009 at 2:13pm #
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.
Posted 24 Oct 2009 at 10:00pm #
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?
any ideas?
Posted 25 Oct 2009 at 2:56am #
Hello Graydon
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!
Posted 26 Oct 2009 at 12:14pm #
I have given up trying to get the Time Machine software to work on Drobo, and am running my backups with ChronoSync.
Hopefully a fix will arrive for this TimeMachine/Drobo problem, then I'll switch back
Posted 26 Oct 2009 at 12:33pm #
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.
Posted 27 Dec 2009 at 9:19pm #
I have written a small script that will create the sparsebundle for you.
http://garretthoneycutt.com/index.php/MacOSX
Posted 28 Dec 2009 at 1:18pm #
@garrett: For TM backups (especially over a network), you should create the SB with a sparse-band-size of at least 131072...
Check out the Create Backup Volume automator action:
http://code.google.com/p/backmyfruitup/downloads/list
You might also consider setting the TMShowUnsupportedNetworkVolumes property... ala:
defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1
jon
Posted 04 Feb 2010 at 2:54am #
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.
Posted 04 Feb 2010 at 3:19am #
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.
Posted 04 Feb 2010 at 1:14pm #
@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.
Posted 04 May 2010 at 3:29am #
Does the drobo work attached to the airport extreme (usb) since 10.6.3 ?
I changed my drobo schema to have partitions, but time machine won't start backing up ๐
Posted 12 May 2010 at 10:25am #
I just tried the sparsebundle approach last night freshly formatted Drobo set (500GB/500GB/1.5TB/1.5TB formatted using Drobo Dashboard to 16TB) using TimeTamer to create the sparsebundle.
TimeMachine backup fails every time and I'm forced to do a hard reboot.
The last Console entry is:
com.apple.backupd[440] No pre-backup thinning needed: 178.24 GB requested (including padding), 16.00 TB available
Anyone else experienced this and overcome it?
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.
Posted 14 May 2010 at 12:58pm #
[quote comment="61910"]I just tried the sparsebundle approach last night freshly formatted Drobo set (500GB/500GB/1.5TB/1.5TB formatted using Drobo Dashboard to 16TB) using TimeTamer to create the sparsebundle.
TimeMachine backup fails every time and I'm forced to do a hard reboot.
The last Console entry is:
com.apple.backupd[440] No pre-backup thinning needed: 178.24 GB requested (including padding), 16.00 TB available
Anyone else experienced this and overcome it?
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.[/quote]
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 ...
Posted 14 May 2010 at 1:42pm #
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.
Posted 19 May 2010 at 11:13pm #
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?
Posted 11 Jul 2010 at 6:49am #
My favourite way to get the MAC address for the en0 interface and format it for use in a TM sparsebundle image name is below.
ifconfig en0 | awk ' /ether/ { gsub(/:/, ""); print $2 } '
If you're a CLI ninja you could also get the machine name using `scutil --get LocalHostName` and concatenate that with the formatted MAC address to do everything in one go!
Thought you might find it useful. Thanks for the write up!
Posted 07 Nov 2010 at 11:17pm #
[...] 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 [...]
Posted 17 Jan 2011 at 11:06pm #
[...] for me. And there’s a good discussion of some of this stuff on a couple of blogs — this one was most helpful to [...]
Posted 26 Jan 2011 at 8:32pm #
[...] interesting to me that this Drobo post from late 2008 is still getting hits. But, then again, the information is pretty good and still relevant, so in [...]
Posted 17 Jul 2011 at 5:53pm #
I've created the sparseimage, but I can't get the mounted image to show up as an option for Time Machine.
I'm using an original drobo, directly attached to the mac. Any thoughts?
Posted 18 Aug 2011 at 12:25pm #
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.
Posted 22 Sep 2011 at 1:09pm #
@Troy: Did you find a way to do this, i'm sitting on the same issue right now....
Posted 29 Aug 2013 at 5:05am #
Do you know if the latest version of the DroboShare will be available for the Windows machines too? I think it can be a really good tool, if will be adapted to Windows OS.