Time Machine backup to network shared drive limit to 16TB?

Question

Level 1

4 points

Time Machine backup to network shared drive limit to 16TB?

This is continued from this thread since the original issue seems to have been resolved in Sonoma 14.1, I'm creating a new one for another issue. Hopefully this is another hidden MacOS limit that could be easily removed.

Long story short, I'm trying to set up network sharing as Time Machine destination, using an old Mac as the server. The data I'm trying to backup is ~22TB, the JBOD hard drive I have on the old Mac as network share is 68TB.

I've got it almost working, except the backup would always stop while it's reaching 16TB, complaining there is not enough disk space such as this:

Time Machine couldn’t complete the backup to “Time Machine HD”

Time Machine was only able to complete 86% of the backup because there is insufficient free space on the backup disk.

My client MacOS is Sonoma. I've tried Sonoma, Catalina, and High Sierra as server OS. Yes I've tried this many times, each taking days to reach 16TB before failing:-( If this is a similar limit in MacOS, I'd suspect it's on the client side. I also know this only happens with network sharing destination because I've had for a couple of years using a locally attached TM drive.

Please help, Apple!

Posted on Nov 21, 2023 7:49 AM

Reply

Answer 1

Top-ranking reply

engathome Author

Level 1

4 points

Dec 7, 2023 5:33 PM in response to engathome

My Workaround

My intuition was the same as what @estresoft suggested, to create my own sparse bundle and just point Time Machine to it. The complexity of hdiutil was intimidating to me, and fortunately I found this link with detailed instructions about using Disk Utility to do that. These are steps copied from it with my comments:

(You can do this on either server or client. Ultimately you'll copy the sparse bundle to the network folder anyway.)
Select File → New Image → Blank Image...
Name the disk image in the "Save As:" and "Name" fields (this is not important as you'll be able to rename it later), then change the Image Format to "sparse bundle disk image." (this is important).
Set the Size. (this is important of course).
Keep the default Format and Partitions (this is important, especially the default partition is GUID, which I suspect was the root cause of the original issue), then click the "Save" button at the bottom right of the window.
The new sparse bundle will automount. You can unmount it from within Disk Utility.

Before you move on, there is an important step to add. The generated sparse bundle has default band size 8MB. According to this link, it'll result in the number of files (bands) exceeding the max allowed in a folder, effectively limiting the size still. I couldn't get the command "hdiutil resize" to work but "hdiutil convert" works:

MBP-2010:Time Machine HD$ hdiutil convert -format UDSB -tgtimagekey sparse-band-size=16777216 -o New.sparsebundle My\ iMac.sparsebundle/
Reading Protective Master Boot Record (MBR : 0)…
Reading GPT Header (Primary GPT Header : 1)…
Reading GPT Partition Data (Primary GPT Table : 2)…
Reading  (Apple_Free : 3)…
Reading EFI System Partition (C12A7328-F81F-11D2-BA4B-00A0C93EC93B : 4)…
....
Reading disk image (Apple_APFS : 5)…
....................................................................................................................
Reading  (Apple_Free : 6)…
Reading GPT Partition Data (Backup GPT Table : 7)…
....................................................................................................................
Reading GPT Header (Backup GPT Header : 8)…
....................................................................................................................
Elapsed Time:  3m 12.766s
Speed: 32.7Mbytes/sec
Savings: 100.0%
created: /Volumes/Time Machine HD/New.sparsebundle

It takes only a few minutes since the sparse bundle is empty. Otherwise it'd be a lot longer.
Remove the old sparse bundle and rename the new one to the name you like.
Copy it to the network shared folder if it's not already there.

Now you have two choices. You can choose to permanently mount it as a virtual disk on your client by double-clicking it, and use the command "sudo tmutil setdestination" as suggested by this link. However I found that if you rename or move the sparse bundle and want to link it again, it'd fail with an error that it's not empty. That doesn't work for me because I move or rename the backup files often and don't want to make a fresh backup everytime.

Instead I found the command "sudo tmutil inheritbackup" works the same way as adding it as Time Machine destination in System Settings:

My-iMac:Volumes$ sudo tmutil inheritbackup /Volumes/Time\ Machine\ HD/My\ iMac.sparsebundle/
Password:
Mounting disk image...
Unmounting disk image...
Inheriting disk image for machine...
Successfully inherited disk image '/Volumes/Time Machine HD/My iMac.sparsebundle'

This command seems to add the client Mac's identifier in the sparse bundle because it'd complain if there is another one for the same Mac in the same folder (you need to remove it). Now you can also rename or move the sparse bundle to a different location. Time Machine will find it (you'll need to point to new location in System Settings) and continue from what was last backed up. You could also have other Macs back up to the same folder. This is how I had planned to use network sharing.

Hope this helps.

Reply

Answer 2

etresoft

Level 9

56,590 points

Dec 5, 2023 8:00 AM in response to engathome

frustrated_daddy wrote:

Please help, Apple!

Apple's not here. This is a user-to-user technical support forum.

It looks like the 16 TB limit is a consequence of the default 4KB block size of the volume. You may be able to expand that if you create the sparse bundle with a larger size. Since your backup is hosted on a Mac, you may be in luck. See if you can use the hdiutil command (on the server) to resize the bundle to larger than 16 TB. If that doesn't work, see if you can create a new sparse bundle, with the exact same parameters, but a larger block size. Not many people have that much free storage. I'm afraid you're on your own here.

Good luck!

Reply

Answer 3

engathome Author

Level 1

4 points

Dec 7, 2023 5:30 PM in response to engathome

In case anyone is having the same problem, I think I found the issue and have a workaround (well it'll be at least a week before the first backup is complete so I'm keeping my fingers crossed).

The Issue

This seems a MacOS bug and I've submitted a report. When I add the network folder as Time Machine destination in System Settings for the first time, it asks about encryption and custom size before automatically creating the sparse bundle. But my choice of size (no limit or 68TB) is ignored. In the created sparse bundle, it's always 16TB. Here is what "hdiutil imageinfo" says:

MBP-2010:Time Machine HD$ hdiutil imageinfo My\ iMac.sparsebundle/
Class Name: CSparseBundleDiskImage
Size Information:
	Total Bytes: 16000000000000
	Compressed Ratio: 1
	Sector Count: 31250000000
	Total Non-Empty Bytes: 16000000000000
	Compressed Bytes: 16000000000000
	Total Empty Bytes: 0

Interestingly it also says partition scheme is none and has only one partition:

partitions:
	partition-scheme: none
	block-size: 512
	appendable: false
	partitions:
		0:
			partition-name: whole disk
			partition-start: 0
			partition-synthesized: true
			partition-length: 31250000000
			partition-hint: Apple_APFS
			partition-filesystems:
				APFS: Untitled
	burnable: false

That might be the root of the problem because in the sparse bundle I create manually the partition scheme is GUID and there are many partitions.

Trying to use "hdiutil resize" to change the size results in an error code 22. I didn't dig into that because my server is so slow I figured it'd take more time to convert than a fresh new backup anyway.

Reply

Answer 4

engathome Author

Level 1

4 points

Dec 5, 2023 9:51 AM in response to etresoft

Thanks @etresoft! You're absolutely right - except the issue seems more mundane - I think Mac just hardcodes the size limit to 16TB. My workaround though is what you suggested - creating my own sparse bundle. I'm waiting for the backup to complete - only about 10 days to go now:-) - before I post details.

Reply

Answer 5

leroydouglas

Level 10

199,308 points

Dec 5, 2023 7:42 AM in response to engathome

frustrated_daddy wrote:

This is continued from this thread since the original issue seems to have been resolved in Sonoma 14.1, I'm creating a new one for another issue. Hopefully this is another hidden MacOS limit that could be easily removed.

Long story short, I'm trying to set up network sharing as Time Machine destination, using an old Mac as the server. The data I'm trying to backup is ~22TB, the JBOD hard drive I have on the old Mac as network share is 68TB.

I've got it almost working, except the backup would always stop while it's reaching 16TB, complaining there is not enough disk space such as this:

Time Machine couldn’t complete the backup to “Time Machine HD”

Time Machine was only able to complete 86% of the backup because there is insufficient free space on the backup disk.

My client MacOS is Sonoma. I've tried Sonoma, Catalina, and High Sierra as server OS. Yes I've tried this many times, each taking days to reach 16TB before failing:-( If this is a similar limit in MacOS, I'd suspect it's on the client side. I also know this only happens with network sharing destination because I've had for a couple of years using a locally attached TM drive.

Please help, Apple!

The current stable release of Sonoma including bug fixes, security updates is macOS 14.1.2

Keep your Mac up to date - Apple Support

To be proactive you can file a bug report /submit your Apple Feedback here: Product Feedback - Apple

Reply

Answer 6

etresoft

Level 9

56,590 points

Dec 7, 2023 5:55 PM in response to engathome

I think you might be losing sight of the most important part of a backup - the recovery. Time Machine simply isn't designed to backup that much data. And your backup medium isn't the most reliable in the world. It seems like you're just asking for corruption.

Time Machine is designed to backup a boot volume and restore it exactly the way it was before. Even normal users with 1-2 TB drives simply can't churn through that much data. Most of the data they have doesn't change, so why does it need to be on the startup volume anyway? And why does it need to be backed up as often as Time Machine does? It should be pretty easy to identify the files that haven't changed in 5 years and probably won't change in the next 5. Move those to an archive storage. Instead of a big RAID where one failure costs you all your data, archive the same data to multiple disks for redundancy.

Reply

Answer 7

Dec 8, 2023 12:26 AM in response to engathome

I'm with etresoft. If having a backups is your main concern, my thoughts would turn to a second raid backup device using dedicated backup software. I wouldn't be using Time Machine for this much data. It would give you far greater control over backup events and storage too.

Reply

Answer 8

Dec 9, 2023 3:44 AM in response to engathome

I've two Synology NAS, each with 2-disk redundancy, i.e. Synology's Raid-6 hybrid. One NAS mirrors the other.

I run Time Machine for the core MacOS stuff, with my day-to-day data stored on an external drive (in addition to the 2 NAS). My MacOS internal drive has almost no personal data on it, beyond things like Mac Mail, which I also backup daily to the NAS.

I've lost data in the past, so I take a belts and braces approach these days. At least as far as my finances allow.

My backup software of choice is Chronosync, which I've been using for more years than I care to count.

Reply

Answer 9

engathome Author

Level 1

4 points

Dec 22, 2023 5:29 AM in response to engathome

Last update: The initial backup was successful. However after a few more backups TM started failing with various errors again, including "not enough space". I finally gave up and took advice from you guys. I'm now excluding the large data RAID in TM, and using a sync app for that instead. So far it's been flawless.

Too bad because I actually like TM.

Reply

Answer 10

steve626

Level 6

13,881 points

Dec 22, 2023 8:44 PM in response to engathome

One architectural problem with your approach is that the size of your data grows continuously. This "problem" keeps on growing over time.As you acquire newer cameras with more and more megabytes per photo, the issue multiplies in scope. My daughter is a professional photographer and I help her with her disks and archiving of the raw and final images that she delivers to clients. I quickly rejected use of one large disk or disk array, too many eggs in one basket, dependence on software that isn't rock solid, and as Etresoft and others point out, Time Machine isn't designed for that sort of environment.

Here's how she does it now:

Main computer (Macbook Pro) is used for all image processing with Lightroom. All raw and processed images restored on inexpensive external mechanical external drives (4 TB or 5 TB).
Data are "cloned" from the original external drive to two additional (redundant) drives. Hence three copies of each such drive.
Final (not raw) images for customer delivery are stored in the cloud. For more redundancy.
She probably goes through 1 to 3 of these drives each year, plus 2 clones of each original. So, say, 4 to 6 drives per year, with triple redundancy.
When full, each drive and its clone are stored in a secure cabinet. One additional clone is stored in a different geographical location.
About 60 such drives have been used so far (250 TB), over a ten year period. Two have failed -- one was one of the clones, quickly replaced, the other was a Time Machine drive (used only for the computer where the photography work on Lightroom is carried out), also replaced easily. Other than those, all drives have worked, even when in storage for years.
Maybe this is a RAID like philosophy, but the distributed nature of the storage approach and the minimal impact of failure any one of these inexpensive drives, and the geographic diversity plus redundant cloud storage of the "final" (reduced size) delivered products has made it work well for over a decade. The idea of storing everything in one RAID device scares me. Because the photographer is working with just one 5 TB drive at any given time, keeping it backed up with incremental "clone" software is very quick.
These are inexpensive drives but they have been reliable. Also, the cost of the drives is low in any given year and all these purchases are taken as a business expense on taxes.

Reply

Answer 11

engathome Author

Level 1

4 points

Dec 5, 2023 9:45 AM in response to leroydouglas

Thanks @leroydouglas. I had tried 14.1.2 and it still has the issue. I think it's a bug in MacOS. I'll submit a report.

Reply

Answer 12

engathome Author

Level 1

4 points

Dec 7, 2023 6:22 PM in response to etresoft

You have a good point. My use case is probably not typical. I'm an amateur photo-video-grapher and what I want to protect are the photos and videos, and they grow rapidly. Actually I don't care about the boot volume at all because my main data is on a 36TB external RAID that I can plug into any Mac. It has its own layer of protection by being RAID 1 so this is just to add to that.

Agree most of those files probably don't change that often. My rationale for that is, TM would just maintain one copy of them so it won't waste any space anyway. At least that's my understanding how it works.

Also good point for multiple disks. I've been actually thinking the same. The reason I moved the TM RAID to a server far away was that it has enough space for another RAID in future for redundancy. I didn't split the 68TB this time was because I figured backing up 36TB needed that much.

Reply

Answer 13

engathome Author

Level 1

4 points

Dec 9, 2023 7:02 AM in response to Robbbbbbbbiiiiiiieeeeee

Ah I see. I did research NAS and Synology before I started this but unfortunately they were over my budget:-( I have been using TM for years (co-located with my data RAID) and have been quite happy with it.

I'll check them out again if this doesn't work out.

Reply

Answer 14

engathome Author

Level 1

4 points

Dec 8, 2023 8:43 AM in response to Robbbbbbbbiiiiiiieeeeee

Thanks for the suggestion. Do you mean second raid just for data? What software do you have in mind?

Reply

Answer 15

engathome Author

Level 1

4 points

Dec 23, 2023 7:36 AM in response to steve626

Steve, wow that's quite a setup! What I had managed to do was to place the backup disks at another end of the house and call that geographically diverse. LOL.

Reply