We were recently tasked with an experiment: Find a way to perform Time Machine backups for individual Mac workstations (laptops or desktops) and have those individual backups reside on a Windows Network Share., and have this be as hands-free and hassle-free as possible. During my preliminary research, we were able to determine that such a process was possible, albeit clunky, as the process was not designed for out-of-the-box. Unfortunately, in practice, it ended up being too volatile to use in a live environment.
The Time Machine program is primarily designed to create and store system backups to an external device, either a plug-in USB hard disk drive or the Apple-branded “Time Capsule” which must have a Mac-formatted partition. At regular intervals, Time Machine will take a snapshot of any and all data that has changed since the last known backup and save it to a date-and-time folder within the destination device.
The OSX platform has the capability to mount virtual disk drives with little to no effort involved. For example, Mac installer files downloaded from the Internet are often in the .dmg format. Instead of merely being a compressed executable like most Windows installer files, the .dmg format is more akin to an actual disk image (e.g. the ISO or IMG format for burnable media). If you double-click a .dmg, it will mount almost instantly as though it were its own disk drive.
Because of this native capability, users discovered the ability to back up their Time Machine data to a sparse bundle disk image created within the Disk Utility program. This ability involves using a simple one-time Terminal command that points Time Machine to the aforementioned disk image’s destination. While this doesn’t require any special software, it does require a bit of know-how, or some clever querying on the Internet. That special terminal command is:
sudo tmutil setdestination /Volumes/[Name of the mounted disk image]
The proverbial “wrench in the gears” comes in the form of Windows Samba shares (referred to in shorthand as SMB). Connecting to an SMB share is a simple task for Finder: click “Go”, select and click “Connect to server…” then enter the proper credentials, pick your folder and voila – connection made. Once that connection has been established, mounting a drive from that location is as simple as a double-click.
Welcome to the first cog that our wrench connects with: For a “hands-free and hassle-free” scenario, that’s a fair bit of seeking and clicking! If that wasn’t enough, there’s also the clutter of having several windows appear on the screen whenever a share or a drive is mounted. In an attempt to resolve this, we searched for a method to mount both an SMB share and the drive within it without all of these confirmations and windows appearing on the screen. The result was an Automator script that can be run once a user signs into their machine, with the key components of “-quiet” and “-nobrowse” flags that explain themselves in their simplicity. Since the mounting of the drive is all that Time Machine needs to begin its process of queuing the next scheduled backup, the seamlessness of mounting the Time Machine disk image appears to have been accomplished.
However, this is where our second cog comes into focus. Logouts, re-logins, recoveries from sleep and physically leaving the network (hello, wireless!) all have the potential for the undesired effect of unmounting the Time Machine drive. This renders the user unable to have the background backup process running, not to mention not having access to the previous snapshots and backups that might be needed. This is definitely not hassle-free.
You may be reading this and thinking, “Why not just run the script again?” or “If you log out and log back in, shouldn’t the script automatically take care of this?” Our answer to you is “We wish that worked.” While each of those above scenarios will unmount the Time Machine disk image, it will not automatically unmount the SMB network mount. This means that, upon running the script in any of the above scenarios, you’ll likely receive errors at the “Connect to Servers” step, because the network link already exists. Sadly, the Automator script does not have a way to process “if-then” conditions, so it declares the script dead on arrival.
There are two workarounds for this above error: disconnect the Windows SMB share in the Finder and then re-run the Automator script or manually mount the network virtual disk drive (not hands-free), or restart the Mac machine while connected to the proper network environment. Neither of these solutions are ideal, but they do work in practice to be able to reestablish a connection with the drive so that access to backups (and the ability to back up) can be restored.
The third and final cog that the SMB wrench hits is the propensity for random disconnections like those listed above to corrupt the Time Machine image. Whether this is due to the fragility of NTFS partitions, the nature of Time Machine backups, the time-honored tradition of disconnects during use causing damage or a combination thereof, not having a physical connection to the disk drive throws a likely doom variable into the mix. This happened on my test machine exactly once, which was enough for me to determine that this was not an acceptable archive method. It’s entirely too likely that my scenario is repeatable in several different flavors, all with the same result.
There is only one potential case where the Windows Network backup method would actually work in practice, but it’s so rare that it’s likely not going to be considered. The rarity: a Mac desktop connected via Ethernet to an internal network server, and that desktop is only ever powered off when the user assures that a Time Machine backup is not currently running. Considering that Mac desktops are not the norm anymore, ethernet ports aren’t even featured in the Air models of MacBooks, and that powering off and powering on an electronic device is an unfortunate IT meme wherein people don’t actually know that they should do this, we cannot recommend this method to ANYONE.
