Necessary to Enable Backup Volume for Time Machine?

I recently learned of the Time Machine Backup Volume feature and have a few questions.

(1) Once the backup volume is created, is it fixed, or can it be increased as I increase HDD capacity?

(2) Besides lack of encryption and the safety of limiting Time Machine’s size, are there other drawbacks to just having the Time Machine folder in my regularly formatted Drobo root directly?

(3) Is there a HPS and NTFS distinction that factors into this decision? Not fully versed on the distinction…

I work with stupid amounts of data and my Time Machine volume is 55TBs and growing, so the ability to allow my Time Machine to grow with my Drobo’s capacity is way more important than having encryption and a safety net for the backups to not creep beyond. I already have a safety net via the light indicators on the Drobo. When it nears capacity I take note of the yellow light and pop in another drive well before it goes red. I also periodically check into the Dashboard App so I’m on top of monitoring capacity. Otherwise enabling Drobo’s TimeMachine feature limits me at the less than the current capacity, right?

Thanks very much for reading and answering. Hopefully this helps others in the future…

It’s fixed, changing the allocated size requires destroying it & creating a new bigger one.

Not many, however, managing the space used (e.g. removing old backups manually) is very slow/time consuming if you ever have to do so manually because you hit budget constraints buying new bigger drives, which are sometimes required in pairs (or even 3s if you have dual redundancy enabled) and the rebuild times become excruciatingly long while those rebuilds happen during the rebuild phase, especially with a full or near full device. Your entire backup set is at risk of total loss to a single drive failure during a rebuild, so you want to keep rebuilds to a minimum frequency & duration.

Also the fact that the native volume has the Drobo track used vs empty space & the complex way TM stores data may well have an impact on performance at other times as well as during rebuilds, especially if you have many small files in the dataset.

NTFS is a Windows file system, even if your Mac has drivers to read it, & even if TM would use it, you’d be crazy to do so without native Windows tools (e.g. chkdsk) available to check & repair any corruption which may occur.

You don’t say which Drobo you have, but with anything other than an 8D you’re going to be hitting Drobo’s 64TB volume size limit in 9 more TB, at which point growing capacity will just create a second volume anyway without increasing what’s available to TM.

Were it myself I’d probably use the backup volume, but more importantly than that, and you don’t mention one way or the other, there is absolutely NO WAY I’d trust that much data to single disk redundancy without a second up to date backup stored somewhere else in addition. The reasons enterprises have stopped using RAID 5 apply just about equally to how Drobos store data, once your drives exceed about 4TB (capacity for RAID, used capacity on them for a Drobo) it becomes literally a coin toss (or worse) if a rebuild will complete, & the more data is involved the worse the odds get.

1 Like

cyber_beardy – thanks, this is really helpful. Some follow up below…

(2) it sounds like the increasing time the TimeMachine drive takes to “cleanup” increases along with the backup size, i.e. complexity of the backup, so that makes sense to me. But does the increased rebuild time have anything to do with with either enabling or not using Drobo’s time machine feature?

(3) I meant to ask about HPS and APFS – not NTFS

(4) I have 3x Drobo 8Ds and 3x 5D3s. The two I’m copying my Time Machine between are both 8Ds. The reason I needed to do this in the first place is because I inserted the disk pack from my 5D3 to the 8D as instructed, later realized I was running up against the 5D3-formatted 64TB capacity wall. So this transfer is to correct that mistake. What I’m trying to understand is why my destination Drobo now has more data on it than the original it’s copying from, but that’s a separate issue completely.

Thanks again for your time here – any additional advice you can offer will be greatly appreciated, and can hopefully help others.

It certainly can have, though how that plays out might depend how much data is to be protected, & how complex that job is for the default volume, & if the backup volume is encrypted or not, in the case it is, the data protection job becomes both bigger as it includes free space, & simpler, since it’s just protect all blocks, regardless if used or otherwise.

APFS is newer & has more features, including some extras for data integrity, if it’s available as a choice in the dashboard interface, it’s probably the better choice, that said I’m almost exclusively a Windows &/or Linux user.

That’ll be to do with the complex strategy & all the filesystem links TM uses to store data space efficiently, virtually nothing gets copying that to a different place right. As a user of backup software that employs a very similar strategy to store backed up files, literally the only method I know to move that data elsewhere is either using the software itself (does TM offer an option to migrate to different storage?), or else to use a program to image the drive & restore said image to another, anything file based (even rsync) messes the job up. There may be Mac exclusive tools I don’t know about that handle the task, maybe someone else will chime in.

1 Like

Wow, this info is gold for me to know, thanks again.

I’ve read many online forums about transferring time machine backups to larger drives to 1. preserve the existing backups and 2. to be able to continue adding new backups and there doesn’t seem to be consensus. Many claim Carbon Copy Cloner but that no longer works with Big Sur. Apple claims finder but most report it to not be a good method. I found a few had success with SuperDuper so i’ve been trying that for the last two weeks.

How you describe large transfers rarely being able to copy all files accurately sounds like cancer in living cells. Definitely hope that’s not the case here as I’d imagine it could cause all sorts of other issues.

I don’t know of Time Machine to have it’s own copy/migration mechanism unfortunately.

It’s not the files, it’s the handling of hard links & symbolic links, depending on situation your desired outcome might be copy the target, copy the link bit for bit, or update where it points to, absolute & relative paths also play into the outcome and/or desired outcome. This makes copying TM archives (or similarly organized storage under Windows) extremely difficult to get right at a file level, & tools that might be able to do it difficult to use as they need to have many options all of which need setting perfectly for the job in hand.

What I’d look for is software that does disk imaging/cloning & can cope with a different sector/cluster size on the target, there’s quite a selection of options for Windows & Windows filesystems that can do that, sadly I know of none myself for MacOS or Unix-like operating systems, not saying there aren’t any, just that I know of none.

1 Like

So fortunately, and out of nowhere, the copy via SuperDuper finished yesterday. It appeared most of the data was copied leading up the completion point but seeing it finished was still s surprise still since it was at 35,000,000 of 65,000,000 files evaluated an hour before what’s been a 3 week transfer. Luckily it ripped through the second half.

Like I was saying the destination Drobo 8D included 1 TB of data more than the source — odd butvTimeMachine accepted the new drive without issues and have tested new backups successfully!

So I now have a working and updated time machine backup, and just in time I guess. As it was backing up my 5D3 with most of my photos went into recovery mode and have 100 hours to rebuild as it loops through recognizing and not recognizing that a drive I didn’t touch is going on and off. I’d replace but it says not to touch anything. Luckily the TimeMachine backup was still able to finish during this rebuild process. Drobo support confirmed this.

My last issue is that I plan to have at least 1 more backup but my third 8D and third 5D3 Drobo encasements will mount to my Macbook Pro but not iMac Pro in the Drobo Dashboard app or via finder. I’ve reverted and updated software and firmware without luck. For another day I guess. Thanks again for all your advice. Enjoy your Saturday

The latest version of CCC now FULLY works with big sur. The issue with the previous version was you couldn’t boot up from a CCC backup disk but the data was still fully there and available to be restored to your computer.