10.6.3 Resizing Sparsebundle Disk Images

Mike Turner wrote:
. . .
hdiutil resize -size 100g /Volumes/Drobo/DroboCapsule/MacBookPro_nnnnnnnnnn.sparsebundle

That works on Time Capsules and USB drives connected to Time Capsules and Airport Extremes; it ought to work on a Drobo as well.

The problem is, effective with 10.6.3, every TM backup re-sets it back to the size of the volume.

Sorry I didn't make it clear. The resize using hdiutil does work. But then the next TM backup changes the size back to the maximum size of the drive.
Apparently for one person at least if you follow the hdiutil resize with a Verify operation on the back up drive AND sparsebundle, using Disk Utility, that has made the resize to the smaller size stick in the subsequent TM backups.

I tried it both ways: verifying the sparse bundle via WIFI; and connecting directly and verifying both the partition and sparse bundle.

No go; 10.6.3 immediately reset back to the volume size in both cases (as it did for some of the other posters there), at least some of whom were using Drobos.

OK thanks for that. Well I have posted the problem with Apple so I guess we just have to wait and see.

Hi, I'm the BackMyFruitUp contributor Mike was talking about 😉. Running TM backups to a droboshare+drobo v2.

The first TM backup following the 10.6.3 upgrade changed the sparse bundle max size to 8TB (my Drobo was formatted for an 8TB volume). Resized the sparse bundle max size to 550GB using hdiutil while being connected directly to the Mac. Next TM backup, back to 8TB like most people experience.

A few days later, I connected the Drobo again directly to the Mac. Resized the sparse bundle again to 550GB using hdiutil, verified Drobo and the sparse bundle with Disk Utility. Since then (about a week), the max size of my sparse bundle stays at 550GB.

Yesterday I even changed the max size over the LAN (Mac->droboshare->drobo) from 550GB to 560GB, and DID NOT run any verify. A bunch of backups later, max size is still at 560GB.

So it works on my side after the initial hiccup but I can't really explain why.

CedricJab wrote:
. . .
So it works on my side after the initial hiccup but I can't really explain why.

I suspect that it working for you is an anomaly -- whether it's something unique in your setup, or something to do with the Drobo, or perhaps the phase of the moon 🙂 , who knows.

It doesn't work for me, either via WIFI or directly-connected, but with different hardware; it didn't work for some folks with Drobos in the other forum; and it doesn't seem to work on Time Capsules, either. And the main problem is, while most situations have the alternative of partitioning, users of Time Capsules can't do that, so they're really out of luck!

So maybe amongst the Drobo users, you can figure out the difference.

I posted a heads up over at the MacOSXHints forums and a member there (biovizier) found a solution. Just remove write privileges ( *chmod -w* ) from the Info.plist file inside the sparsebundle (I'm not sure if it's necessary, but I did the same for the Info.bckup file).

After downsizing my sparsebundle and setting the permissions, my next backup included the following:
...
*Resizing backup disk image from 100.4 GB to 4095.6 GB*
*Could not resize backup disk image (DIHLResizeImage returned 13)*
*QUICKCHECK ONLY; FILESYSTEM CLEAN*
...
*No pre-backup thinning needed: 100.0 MB requested (including padding), 12.49 GB available*

I can certainly live with a "Permission Denied" error. Hopefully there aren't any other side effects. biovizier's post indicates that only resize operations should be effected; adding files and compacting should be fine.

Message was edited by: fracai

Hmm. Very interesting. Not exactly a user-friendly workaround (I hate recommending Terminal to folks not familiar with it!).

Given the contents of that file, I doubt there'd be other problems, but you never know.

Please do some experimenting, and I'll do the same.

Things to check: attempting a backup that would fill past the new maximum; deleting backups; compacting; re-selecting via TM Preferences, including deleting the preferences file; repairing via Disk Utility, Disk Warrior, and the like.

And of course, anything else we can think of!

I can test with a USB drive on an Airport Extreme, and if I get ambitious, a shared drive on another Mac.

I don't have a Time Capsule, do you? If not, I can probably get a couple of the frequent posters in the TC forum to try it. (That's the place that needs this the most, since you can't partition one.)

I'm backing up 2 machines to a Drobo; one locally, the other via AFP share. Both are using sparsebundles.
I'll give a few of those a try and report back.

I'm running a verify and repair task right now.

skerb1 wrote:

Pondini wrote:
Or have you done that, and subsequent backups are resizing it again?

It looks like my backups are still resizing. This does not seem to be a one-time thing. I just used TM again this morning:

Yes, we've confirmed that's 10.6.3's behavior. There may be a workaround; see fracai's recent post (starting "I posted a heads-up . . ").

If you're comfortable with Terminal, give that solution a try, and let us know if it works for you.

If not, we'll let you know what we find out; if it seems to be a workable solution, we'll provide detailed instructions.

fracai wrote:
. . .
Just remove write privileges ( *chmod -w* ) from the Info.plist file inside the sparsebundle

Exactly how are you doing that?

I'm not a UNIX guy; but I can't get it to work -- I get no error message from Terminal, but TM still resizes the sparse bundle.

I'm not at my machine right now, but I think it should be as simple as:
+chmod -w /path/to/sparsebundle/bundle.sparsebundle/Info.*+

To verify, what is the output of:
+ls -la /path/to/sparsebundle/bundle.sparsebundle/+
and:
+ls -lad /path/to/sparsebundle/bundle.sparsebundle/+

fracai wrote:
I'm not at my machine right now, but I think it should be as simple as:
+chmod -w /path/to/sparsebundle/bundle.sparsebundle/Info.*+

That gets +*No such file or directory.+*

but +chmod -w /path/to/sparsebundle/bundle.sparsebundle/Info.plist+ shows no error message, and takes a few moments to complete, but TM resizes it again.

To verify, what is the output of:
+ls -la /path/to/sparsebundle/bundle.sparsebundle/+

+*Ls: /Volumes/S.Misc1/JPsBigiMac.sparsebundle/bundle.sparsebundle: No such file or directory+*

and:
+ls -lad /path/to/sparsebundle/bundle.sparsebundle/+

ditto.

I tried the chmod with the sparse bundle mounted, again with it not mounted. Made no difference, TM resized it back to the volume size.

As a friend of mine used to say, "It's too deep for me!"

I think you have a few too many "sparsebundles" in there. Sorry if I wasn't clear.

For example, the following:
/path/to/sparsebundle/bundle.sparsebundle/
would translate, for you, into:
/Volumes/S.Misc1/JPsBigiMac.sparsebundle/

So the Info.plist and Info.bckup files should be located at:
/Volumes/S.Misc1/JPsBigiMac.sparsebundle/Info.plist
/Volumes/S.Misc1/JPsBigiMac.sparsebundle/Info.bckup

Try:
+chmod -w /Volumes/S.Misc1/JPsBigiMac.sparsebundle/Info.*+

and then:
+ls -la /Volumes/S.Misc1/JPsBigiMac.sparsebundle/+
+ls -lad /Volumes/S.Misc1/JPsBigiMac.sparsebundle/+

The resize (with whatever target size you want) would be:
+hdiutil resize -size 100g /Volumes/S.Misc1/JPsBigiMac.sparsebundle/+