Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

10.5: Back up Time Machine's sparse image bundles System 10.5
If you're using Time Machine to back up Macs to a Time Capsule or networked hard drive, each backup is contained in a single sparse disk image bundle (.sparsebundle) disk file. When your backup contains weeks' or months' of data, if that single file is lost or damaged, you'll obviously lose all of your backups. It is therefore quite important to back up the sparse bundle and test the backup! Here's one way to do that that, though there are many other methods available:
  1. Copy the sparse bundle back to your Mac (and then remember to exclude it from Time Machine's backups, using the Options button in the Time Machine System Preferences panel).
  2. Use Disk Utility's Repair Disk feature on the mounted .sparesebundle to insure that it's in good shape. This should be quite fast when run on the local copy of the sparse image bundle.
If Disk Utility doesn't find any issues, you've now got a good backup of your critical Time Machine data. If you do this even once a month, that will greatly limit your losses should the sparse image bundle go bad or accidentally get deleted. While this may seem like overkill, the first time you have a sparse image bundle go bad, you won't think so.

[robg adds: I've had my MacBook Pro's Time Machine backup go bad a couple of times now, so I've taken to copying the sparse image file onto the Mac Pro as a redundant backup. I keep it in a folder that has been added to Time Machine's 'do not backup' list, so that it's not taking a ton of space in my Mac Pro's own Time Machine backups. If you have only one Mac, I suggest attaching a FireWire hard drive and using that to store the copy of your sparse image bundle, as drive space on a laptop is a precious commodity.]
    •    
  • Currently 2.25 / 5
  You rated: 4 / 5 (8 votes cast)
 
[41,058 views]  

10.5: Back up Time Machine's sparse image bundles | 16 comments | Create New Account
Click here to return to the '10.5: Back up Time Machine's sparse image bundles' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
10.5: Back up Time Machine's sparse image bundles
Authored by: Anonymous on Aug 07, '08 08:53:24AM
You say:
each backup is contained in a single sparse disk image bundle
If this is the case then why:
if that single file is lost or damaged, you'll obviously lose all of your backups
If each backup is contained within a single file, then surely if that file is lost, then only the backup related to that file will be lost?

Or did you mean "all backups are contained in a single sparse disk image bundle"? That would make the second assertion true.

Please, grammar is important. You have to use the standard so people can understand what you mean.

[ Reply to This | # ]

10.5: Back up Time Machine's sparse image bundles
Authored by: gshenaut on Aug 08, '08 06:57:10AM

Each state is part of the United States, all states are part of the United States;
Each state has a capital city, all states have a capital city.

The problem isn't grammar, it's quantifier-scope ambiguity. In context, only one of the two meanings makes sense, which in fact is usually true, so syntactic disambiguation is less important here than in contexts where both meanings could make sense. If you really needed to use syntax to disambiguate that sentence, you could go for something like "{Each backup|All backups} of a given computer {is|are} stored in the sparse image associated with that computer's internal ethernet adapter's address" (I don't actually know if that's true, it's just an example for syntactic purposes).

I think that "each" was used here (by the way) because the writer was focusing on the fact that there is a sequence of individual backups, each of which goes into the same image file. If you were focusing primarily on the aggregate all at once ("all of the backups in the image file were corrupted") then perhaps he would have used "all".

Greg Shenaut



[ Reply to This | # ]
10.5: Back up Time Machine's sparse image bundles
Authored by: kencohen on Aug 07, '08 11:02:55AM

"Use Disk Utility's Repair Disk feature on the mounted .sparsebundle"

How do you do this? Specifically, I guess, how do you mount the .sparsebundle file?



[ Reply to This | # ]
Don't copy an active TM backup
Authored by: lincd0 on Aug 07, '08 11:27:33AM

If you copy a TM sparsebundle while TM is running, the copy may be in an inconsistent state. You should stop TM while the copy is made.

Also, TM is designed to be a backup solution, not an archival solution. If you need to keep archives of old files, you should treat them as original data, not backups, and back them up in the same way as the rest of your data. Copying a backup onto the same storage device that's being backed up doesn't make a lot of sense. You should make a redundant copy onto a third device.



[ Reply to This | # ]
Don't copy an active TM backup
Authored by: koyeung on Aug 09, '08 07:40:28PM

one sentence is missing from original post: "As minimal steps and without additional hardware, ..."

The sparse bundle contains more (including old changes) than the main harddisk, there is still benefit to keep the copy even on the same harddisk.
If no attached firewire HD is available, backup to the main HD is better than nothing :) The drawback of here is it takes a lot of time to do the copying.

You are right that we need to stop TM before copying the bundle. That's critical.



[ Reply to This | # ]
10.5: Back up Time Machine's sparse image bundles
Authored by: AlienX on Aug 07, '08 01:44:28PM
That's a good thing to do because you can then use these Backups wireless!
Read here how to do it: http://rolf.haynberg.de/?p=83

Regards


[ Reply to This | # ]
A sparsebundle IS NOT a single file
Authored by: lowbatteries on Aug 07, '08 05:26:02PM

The "bundle" in sparsebundle lets you know that it's not a single file. Actually, its a whole bunch of 5MB files containing data, a few metadata/index files, all wrapped up in a bundle that Finder sees as one file.

This makes it much harder for it to be corrupted than say, a sparseimage file. It also makes it MUCH MUCH faster to sync two sparsebundles with rsync, unison, or other differential-backup utilites.



[ Reply to This | # ]
Another advantage of many files
Authored by: lowbatteries on Aug 07, '08 05:32:18PM

Another advantage of a sparsebundle being many files, is it can be copied onto multiple hard drives in a pinch, or even file systems that don't support large files (like Windows FAT32 with its 4GB limit).

I also assume it improves the performance of image files on RAID and ZFS.



[ Reply to This | # ]
A sparsebundle IS NOT a single file
Authored by: maikel on Aug 10, '08 11:08:10AM

Correct, yet in reality, alas my sparsebundles end up being corrupted nonetheless.

Your post did hint me to an approach I might still adopt; create the sparse bundle on the local HD and use time machine to keep that loaded with the latest backups, confining the space the sparsebundle eventually grows to by limiting the max size at the creation of it.

THEN using a scheduled rsync to copy the sparsebundle to the NAS, instead of writing to the NAS directly. THAT would indeed be much faster. (I was using a home grown rsync script prior to time machine that mounted/unmounted the NAS volume)

Needless to say, it's a waste of HD space on the local machine, may need to upgrade the good ol' iMac with a bigger one finally.



[ Reply to This | # ]
10.5: Back up Time Machine's sparse image bundles
Authored by: Dr. T on Aug 07, '08 07:20:51PM

I don't see the purpose in backing up the backup file for most users. If the backup file goes bad, you just start over with a new Time Machine backup. For persons who need more security, instead of making a backup of the Time Machine sparsebundle, they should make a full clone of their main drive. That gives you two full backups of different types (which should reside on two different drives so a single drive failure doesn't kill both backups).



[ Reply to This | # ]
10.5: Back up Time Machine's sparse image bundles
Authored by: regulus on Aug 07, '08 11:31:32PM

Sparse bundle? My time machine backups are not in a sparse bundle. They're in a folder called "Backups.backupsdb" and I can navigate that folder just like any other folder. The drive used for my time machine backups is a second internal drive on my desktop computer.

Maybe sparse images are used somewhere else but not on my machine. I'm not sure what you guys are talking about.



[ Reply to This | # ]
10.5: Back up Time Machine's sparse image bundles
Authored by: regulus on Aug 07, '08 11:35:39PM

Sorry, my mistake. I now see that this is for time capsule and network backups.



[ Reply to This | # ]
10.5: Back up Time Machine's sparse image bundles
Authored by: maikel on Aug 10, '08 11:11:49AM

sparse bundles are only required when you're backing up to a non-mac formatted drive. This could be a networked drive with a linux device, exposing the linux formatted drive through SMB share. Obviously not up to Apple's standards and for sure not good enough for Time Machine to accept. The sparse bundle then is a good bunch of files that represent a virtual drive on top of a different file system. Quite neat. Yet network access does make the approach not entirely feasible in my experience.



[ Reply to This | # ]
10.5: Back up Time Machine's sparse image bundles
Authored by: dan55304 on Aug 08, '08 06:43:13AM

The value in this hint is saving the time of an initial TM backup which is quite long. This hint assumes that all the daily change backups have some value and must be retained. Granted, TM goes into that territory by it's frequent backups: I edited a file, screwed it up, and want to revert to the one I had two hours ago.

TM's main declared purpose is backup. Backup from what? I'm concerned about 1. Drive or computer failure, 2. disasters like fire, theft, or flood. The only way to accomplish that is to TM to a device in another building. What good does it do to have 10 copies of TM backups if they all go in the same fire?

I backup TM in another building over my local network. I also backup using .Me for settings, the i apps data, and my documents. That gives me redundancy for all critical files.

I'm still missing a strategy I like for archiving, where I remove the files from my hard drive because they aren't relevant currently. I want to make two copies on separate hard drives and store them in different places. I hate manual tasks. I just can't make myself do it.

TM for archiving is a non-starter for me. I don't want to, or expect to, have TM backups for all time. Their size will become unmanageable and Apple will eventually break these with new updates or a change in technology. I don't want an archive of every revision of a file anyway.



[ Reply to This | # ]
About archiving
Authored by: hamarkus on Aug 11, '08 09:36:18AM

The smaller the number of logical disks (ie, a RAID would be one logical disk), the easier it is to backup and archive and keep track of things. If you cannot fit all your data on the your current harddisk, get the biggest available drive and try again. If if still does not fit, consider pooled drives (RAID, Drobo).



[ Reply to This | # ]
You're backing up the back up ... on the drive that you were backing up?
Authored by: maikel on Aug 10, '08 11:02:38AM

I found out that the option of using sparse bundles can go wrong too easily. Essentially, the sparsebundle consists of thousands of small files that together are mounted as a file system. After trying rigorously to make my nslu2 work as NAS that, through mounting the sparsebundle files were trusted, I found that solution not reliable; every two weeks I had to restart as the sparsebundle to back up my iMac would go south, requiring me to start ... again and again.

This hint could help the restart process, picking up from a particular incremental backup. It is obviously not a good idea to copy a backup back to the backed-up drive as when that drive is lost, so are the files. In case your sparsebundle happens to be crippled at the same time, you're in shit.

As for the one big file comment; the backup itsself is written to the Volume that you mount from the sparsebundle. The backup of all the files is written to this volume, which in turn is persisted as thousands of files that represent that Volume. In theory, this would reduce the chances of loosing data due to unreliable network access.

In theory, yes. I had to move away from the NAS approach; sadly it's not reliable enough. I found that checking the volume with even ONE missing file-segment would cripple the entire bundle.


Each back up <i>looks</i> like it is a complete copy of all the files. Instead this is so called hard-links at work. Very smart way of double using unchanged files; the entire directory structure is indeed replicated in each backup, instead of being incremental. Yet, all of the unchanged files are only on the bundle once, with a use-counter. Once the last reference to that file is removed, so will the file be. Very smart IF your files are small, rather than big binaries.

Good thing iPhoto library looks like a single file, but actually is a package comprised of the underlying photos and metadata. Also Mail uses many many small files. So where M$ Outlook would touch the OST or PST file of 500mb and change it, Apple actually made its persistance very lean to back up incrementally.

I ended up using a plain hard disk in the neighborhood. I have no idea how the time capsule circumvents the above issue.



[ Reply to This | # ]