Drobo

TimeTamer is not a good solution

It really bothers me that you (DataRobotics) continue to promote TimeTamer as a solution for TimeMachine when it is a terrible solution that doesn’t create sparsebundles that are good for use with Time Machine. What can I do to convince you that you should stop recommending and distributing it?

Either that, or FIX it. Please take a look at the source code to the Create Backup Volume automator action: http://code.google.com/p/backmyfruitup/downloads/list

I’m passing the correct arguments to hdiutil. All you have to do is fix TimeTamer to use those same arguments.

thanks,

jon

Hi Jon, I’ve got several Macs backing up to sparseimages created by Time Tamer - what’s the problem with the code in Time Tamer exactly?

Like I said in my posting above, TT doesn’t pass good arguments to hdiutil. Since you seem unable to compare the differences, I’ll do it for you.

This is the command TT uses:
$cmd = “hdiutil create -size $size\g -fs HFS+J -volname “TM-backup-of-$host” $SBfilename”;

This is the command CBV uses:
CMD="hdiutil create -nospotlight -imagekey sparse-band-size=131072 -size $VOL -fs “Case-sensitive Journaled HFS+” -volname “Backup of $HST” ~/Desktop/$

Specifically, the following arguments are important:

-nospotlight -imagekey sparse-band-size=131072

(sadly, apple seems to ignore the -nospotlight, but might as well put it in there)

the sparse-band-size is VERY important because otherwise the default tiny size is used and since TM writes a lot of data to sparsebundles (generally over the network), then opening a ton of tiny files is a major speed slowdown.

This is a very simple fix for TT, but nobody is making the effort to do it. Until it is done, it should be removed from the DR website.

The other problem with TT is that it kind of implies that backing up over SMB is ok. That is the furthest thing from the truth. Read the BMFU mailing list for more discussion on the matter.

Thanks - I’m actually finding that using Time Machine on a Drobo (gen 1) with the Time Tamer sparse images is causing a overheating problem. Could the type of sparseimage be a contributor to this?

The Drobo doesn’t overheat doing single file writes and reads, but doing a TM restore kills the Drobo after about 20 min.

Not sure about the SMB reference - my Drobo is mounted via AFP

If you use the DroboDashboard app to access your Drobo, then that use SMB as the file sharing protocol. That is bad. If you have your Drobo plugged into a Mac and access it via that mac’s sharing (afp), then that is good. If you have a DroboShare and put BackMyFruitUp on it, then that is good.

Yes, it will definitely cause more read/write activity to use a smaller band size. 8mb vs. 64mb (131072 is the number of 512byte sectors in each band).

Open up your sparsebundle and look at it (using show package contents). You will see a bazillion little files inside of it. The fewer little files in it, the better, right?

Is there a way to convert the bad sparsbundle image into a good one with the larger file sizes? Or do I have to delete it and start again?

hdiutil has a “convert” option but I don’t know if it can be used to change the band size. If you don’t want to start from scratch, my best guess would be to create a new sparsebundle with the BMFU script and then try to copy the content from the old sparsebundle to the new one with something like SuperDuper.

I think the problem with that approach is that there are lots of hard links made by TM that probably won’t survive the copy - but I might be wrong.

I wonder where DataRobotics is on this topic… bueller? bueller? anyone?

Have you opened a support ticket? That’s the best way to get official eyes on it.

What is the point of these forums then?

According to the verbiage at the bottom, it’s a space for “us users” (or in this case, developers) to communicate with each other.

Unfortunately DroboApps aren’t supported by tech support. I’ve never used them and can’t comment on this forum. Sorry.

Yet your company is responsible for advertising and displaying them on your website. If you are willing to put up an app that doesn’t do a good job (and mark it as a #2 TOP DOWNLOAD), then don’t you think that is a disservice to your customers?

Data Robotics provides any and all DroboApps as a courtesy. DroboApps are not supported by Data Robotics. Data Robotics makes no representations regarding the applications or any information related thereto. Any questions, complaints, claims or comments regarding the applications must be directed to the relevant developer or software vendor. Use DroboApps at your own risk.

So what this “bugfix” would do is to speed up the TimeMachine backup process a bit or what?!