Continuous Time Machine Verification Error on 3rd Mac

I have been running Time Machine on shares for 2 Macs in my house without incident. I added a new macbook (and 3rd share) to my Drobo 5N about 6 weeks ago. Every 1-2 weeks I get the error:

Time Machine completed a verification of your backups on “Drobo5N”. To improve reliability, Time Machine must create a new backup for you.

Can anyone suggest why I may be encountering this issue? FWIW, the macbook, drobo, and WiFi router are all in my home office. I have no reports of networking issues on any of the Macs or smartphones.

Drobo Dashboard: 2.7.0 [77097]
Drobo 5N Firmware: 3.3.0 [8.75.76511]
SSD on macbook is 256 GB, share is 512 GB

I back up to a NAS at work (Buffalo I think) and this happens to me every now and again there as well, I don’t think it’s confined to Drobo products. I think I’ve also seen this at home where I back up over the network to another Mac running Server with the network Time Machine feature turned on, but I’m not 100% positive.

Thanks Spiney. What’s funny to me is it’s always this computer’s backup, it’s happening every week or two, and never the backup of the other two.

hi, i think i first learned about the site from johnm but it might have some more info about it too:

Thanks Paul - I’m trying the naming changes suggested (I just removed a space in machine name - but other Mac’s in my house seem to have them). Don’t see the potential log issues they mentioned. A Big part of the reason I got the Drobo 5N was to centralize backups so hoping I can make this work!

it may be a time machine issue, e.g:

  • if the spacebar exists on another mac, and works fine, especially to your drobo
  • since others have seen the error to non-drobo devices

do you have the other macs using a different cable?
maybe you could try using the cable from the working mac, and using that for the one that sometimes gives you the time machine error, just in case the cable is causing some problems?

Are you connecting your problematic Mac via WiFi? Cabled connections are not only faster but much more reliable. Time Machine does a consistency check whenever it believes that a backup has been corrupted. The most usual cause is if the network connection to the Time Machine destination was interrupted during the backup process. That’s more likely with a wireless connection.

Time Machine backups to networked devices are more fragile than those to directly attached hard disks because they have to use an abstraction layer. With a directly attached disk, Time Machine can format it to use the HFS+J format, which supports the hard links (of both files and folders) that it needs to work. Networked storage doesn’t allow this so when networked storage is used Time Machine creates a special folder containing a large number of small files, together known as a “sparse bundle”. It uses the sparse bundle to hold a disk image file, which can be formatted and mounted, like a real hard disk. Hence it can use the required HFS+J format on the image. The sparse bundle itself can be stored on pretty much any file system but, because it consists of a large number of small files it’s slightly more prone to corruption.

This is happening to me as well… I’m almost always connected via wifi. I don’t understand why this only happens with Time Machine… i can copy files to and from my Drobo all day without corrupting them… wifi should not inherently corrupt files. I understand that wifi is more likely to loose packet, etc, that TCP knows then this happens, and you would think that the protocols that run over TCP would have their own consistency checks to ensure that a broken connection doesn’t result in a corrupt file.

hi phrend,
maybe the method of copying via timemachine, is somehow different to the usual copy process you use normally?

for example, some local or network tools have extra verification methods, such as calculating hashes or checksums (or simply re-verifying each bit as i think syncback does), so maybe there is an option you can look for within timemachine configs, possibly labeled as a slower verification method or longer copy?

i’m buying this explanation. is there a way to repair the sparsebundle yourself? i found this:,08,27,169,fix-time-machine-sparsebundle-nas-based-backup-errors.html website, but couldn’t get it to work. will this work for drobo’s?

hi kreditcional,
can i check how large your backup is (and approximately how long it usually takes to create) - it might be worth considering simply re-creating the backup, rather than fixing it, (though having a way to safely fix it is good).

i couldnt find any references to a drobo on that page, but it might only be worth trying things further, if you have a non-time machine (reliable) backup of the data, just in case some commands cause another issue.

btw, you might have already seen them, but there are about 4 pages of comments on that thread with garth replies and other comments, that only seem to show up when ‘older comments’ is clicked… maybe there is some additional info there that might be useful?

(just also linking your related post)

ok, so a few months later this happens again! again i need to restart the back up from scratch
i don’t back up to delete the back up every few months!!! i’m really pissed this happens again and again. why? and more importantly: drobo fix this!!!

hi kreditcional, i saw your other post about it happening again recently the other day too…

if you find a bit of spare time, would you be able to post back with some more details about your current setup and mac backup process and versions etc, as am just thinking that if some more info is known, maybe somone could spot something that might be able to be tweaked to help make things work better for you… i can try from here too though its just that i do not have a mac myself but if you do get a chance it might be worth trying if you can.