Move Time Machine backup to new Drobo 5D

Third Party Applications Time Machine
1

I am new to Drobo, and to this forum, so please forgive me if I didn’t post this correctly…

I just installed a new a 5D on my iMac running Yosemite and upgraded the 5D to the latest firmware. There is an option for creating a Time Machine partition, and it worked as advertised. The problem I had was in moving my old Time Machine backup to it.

I first tried a copy the “Backups.backupdb” folder from my old Time Machine disk. Finder spent many hours displaying “Preparing to copy”, then once the copy started it failed after only a few GB with an error saying I didn’t have permission to copy some files.

I next tried Disk Utility. This worked as advertised, but after the copy finished the Time Machine partition was unmountable, and Disk Utility said the partition was trashed. I had to delete it.

My experience with Drobo is, as I write this, almost exactly one day old, and I’m out of ideas. If anyone has any suggestions I’d be grateful.

2

It isn’t a straightforward process to transfer existing Time Machine backups from one disk to another. Simply copying the files won’t work because there are file permissions to consider and the fact that there are hard-linked files and folders. Much the best option is to put your old Time Machine backup disk to one side and start afresh on your new one, in this case the new one being your Drobo. It’s fully explained on this page of the excellent guide to Time Machine.

3

I’ve been using Time Machine since 2008, and during that time I’ve moved my backups twice as I upgraded to bigger and bigger Time Machine disks. I used Disk Utility to copy the entire volume each time, and I never had a problem. I also didn’t see the speed problem mentioned in the article; I think that Disk Utility just essentially does a block by block copy, so the complicated Time Machine directory tree shouldn’t affect the time required for the copy. I’ll admit to having been wrong before…

Moving my Time Machine backup to the Drobo was a different matter. Disk Utility seemed to have a problem with the Drobo “disk” (in January when I tried it, anyhow). The copy seemed to work, but after the copy, the Drobo Time Machine volume was unusable. I’ve avoided using Disk Utility with my Drobo ever since.

Keeping my old Time Machine disk wasn’t an option. It went away along with my old Mac. I did just start over with a fresh backup. I wiped the old drive.

4

Well, I said it wasn’t a straightforward process! Since you say that you had become accustomed to having to use Disk Utility to move your old Time Machine backups to progressively larger disks I’m surprised that you expected a simple drag and drop Finder copy to work when moving them to your Drobo. I therefore stand by what I said: it isn’t a straightforward process. I have a 5N, which handles Time Machine differently from the 5D. If I wanted to save all my old Time Machine backups I’d look to storing them within a disk image container, such as a sparse bundle.

5

I should have re-read my original post before replying to yours. My problem occurred in January. That’s a long time ago, especially when you reach my age, so I’d forgotten some of the details.

I originally tried the copy rather than using Disk Utility because, since Disk Utility operates at a very low level, I was concerned about just how good a job the Drobo did at looking like a real disk. My concern seems to’ve been justified since the copy made by Disk Utility was unusable.

In any event, it doesn’t matter anymore. There have been one or two Drobo firmware upgrades (and MacOS updates) since then, so for all I know Disk Utility would work today. Also, since I started Time Machine from scratch on my Drobo and deleted the old backups, I don’t need to do a copy.

6

I think you’re right to have reservations about how well a (directly attached) Drobo volume does the job of looking like a real disk to low level utilities like Disk Utility. Mine is a (network attached) 5N and therefore doesn’t look the least bit like a real disk so, as you’d expect, Disk Utility doesn’t even see it. I do however store images of disks on it in the form of .iso files (optical media), .dmg files (Mac read only) and .sparsebundle packages (Mac read/write), which can be manipulated by hdiutil and mounted and the contents manipulated by Disk Utility. If I wanted to store the contents of a Time Machine backup disk (or any other self-contained HFS+ volume) I would store it inside such a container using either Disk Utility or one of the commercial cloning applications (such as Carbon Copy Cloner or SuperDuper!). The container emulates a real HFS+ volume exactly while being abstracted from the real underlying filesystem.

For what it’s worth I use a dedicated USB-connected hard disk for my active Time Machine backups because I want simplicity and ease of access in the event of having to perform a full recovery. I’ve never felt the need to keep more than a year or so’s worth of backups and a Time Machine volume equal in capacity to my system volume has always proved adequate. Furthermore, the only occasions I’ve I ever had to restore from a Time Machine backup were when I replace a system drive, either due to failure or to increase its capacity. At times like those you really appreciate the simplicity of a USB drive! I’d like to think that a 5D would be equally simple in such circumstances, but a 5N is likely not to be. Is it possible to mount a volume on a 5D without access to the Dashboard, for example?

7

You made some excellent points which I’ll certainly keep in mind.

Like you, I never had reason to keep more than a year’s worth of backups, even when managing backups was part of my day job, but Time Machine really spoiled me. The penalty for several years’ worth of backups is very small, and there have been a couple of times when they came in handy. I still don’t see the need for multi-year backups, but I do like having them.

My system consists of an iMac with a 500GB SSD, the Drobo 5D for most of my data, and a USB drive for Time Machine. The Drobo has two partitions; a Time Machine partition, and a regular partition. I back up the regular Drobo partition with Time Machine also, and the Time Machine backups stored on the Drobo are the ones I’ll keep for a long time, but I want the second Time Machine backup in case the Drobo hardware fails. I just keep those USB drive backups for a few months, so I don’t need a large drive.

Yes, the Drobo 5D volumes seem to look like regular volumes to Disk Utility. They verify without a problem, but I haven’t risked doing a repair…

They dismount and mount automatically after a reboot without the need for the Drobo Dashboard. In fact, a mount/dismount using the Drobo Dashboard can no end of grief for Time Machine, so I only do it when updating the Drobo software/firmware.

When the Drobo drive mounts after being dismounted via the Dashboard, it seems to mount with a different UUID than it had when it was dismounted, and Time Machine seems to roll the UUID into whatever it uses to identify backups. As a result, Time Machine does a deep scan of the Drobo volume, backs up everything, and it totally ignores my exclusion list (I assume that TM assumes that the exclusion list applies to a different volume).

I have a LOT of stuff on my Drobo that doesn’t need any more protection than the Drobo provides; iTunes media, for example, which I could re-download if needed. This stuff could fill up a TM backup drive in no time, so the exclusion list is rather important. If I manually dismount the Drobo volume, I have to delete then recreate the exclusion list, and manually purge the junk from my backups if I forgot to disable Time Machine before the dismount.

Things can be a bit exciting even if I let the OS dismount the Drobo volume, although I don’t think this causes long-term problems. The very first time TM runs after a reboot, I can get one or more, “Property list invalid for format: 200 (property lists cannot contain NULL)” errors. As best I can tell, after a lot of Googling, this error usually occurs when there is an item in the TM exclusion list that points to something that doesn’t exist. I don’t get it during the second, or subsequent, backups.

I’ve been in touch with both Drobo and Apple support, and the problem was escalated to second level support by both companies, and both support groups have tried to be helpful. The consensus seems to be that TM is trying to scan the Drobo volume immediately after the boot, and before The OS, Spotlight, and friends have finished with it. I’ve seen similar strange and wonderful behavior on a regular disk when I tried to access it while Spotlight was re-indexing it.

My solution is to disable Time Machine before shutting down the system, then wait a few minutes after a reboot before enabling Time Machine. I never have a problem if I do this.

8

Thank you for the interesting read. I now know much more about the 5D than I ever did before.

Time Machine does indeed make heavy use of UUIDs internally, as described here. This or this might help your particular situation - apologies if you’ve already read them.

Are you aware of the tmutil command line utility for advanced manipulation of Time Machine? You may be able to use it to make sure that Time Machine is automatically disabled whenever you shut down your Mac. It’s also useful for the advanced management of exclusion lists. It has a man page and you can get some ideas here.

9

Thank you for the interesting read. I now know much more about the 5D than I ever did before.

Time Machine does indeed make heavy use of UUIDs internally, as described here. Pages B5 and B6 of the same document might help your particular situation - apologies if you’ve already read them.

Are you aware of the tmutil command line utility for advanced manipulation of Time Machine? You may be able to use it to make sure that Time Machine is automatically disabled whenever you shut down your Mac. It’s also useful for the advanced management of exclusion lists. It has a man page and you can get some ideas here.

10

Thank you for the interesting read. I now know much more about the 5D than I ever did before.

Time Machine does indeed make heavy use of UUIDs internally, as described here. Pages B5 and B6 of the same document might help your particular situation - apologies if you’ve already read them.

Are you aware of the tmutil command line utility for advanced manipulation of Time Machine? You may be able to use it to make sure that Time Machine is automatically disabled whenever you shut down your Mac. It’s also useful for the advanced management of exclusion lists. It has a man page and you can get some ideas here.