This is a slightly shortened version of an article I already wrote in German which is my native language so please forgive me possible mistakes.
Mac OS X features in its newest release Leopard (Mac OS X 10.5.2 while I am writing this) an automatic backup solution called Time Machine. It automatically creates backups, takes care of everything and even incorporates a very stylish interface to find and recover old files.
Unfortunately Time Machine has some limitations. So far it only works with external hard disks that are connected directly to the Mac. Apple now provides a solution for network backups called Time Capsule. However, using already existing drives for backup would be desirable.
You can find guides to make Time Machine at least accept network shares as backup drives in the web. Using the command (all in one line)
defaults write com.apple.systempreferences
TMShowUnsupportedNetworkVolumes 1
in Terminal is sufficient. But this only results in accepting the share. At least in my case creating the first backup failed with the error:
Time Machine Error - The backup disk image could not be created.
Pretty dissatisfactory. We gonna need new solutions. In my investigation I often found the statement that Time Machine simply would accept self made disk images on the network share. It doesn’t.
It rather helps to investigate the failed backup attempt more precisely. You will notice that Time Machine tries to create a sparse bundle disk image on the share. It remains Time Machine’s mystery why that fails.
On Apple’s support forums you’ll find further advice. It is proposed to copy the bundle image while creation and to copy it back after this fails. Did not work for me. Anyway, the solution is much simpler. During the backup attempt Time Machine creates the bundle image on the share. This is called <computer’s name>_<string>.sparsebundle (Update: by the way, string is the MAC address of the local en0 device without colons). You should keep the exact name in mind (e.g. by copy & paste or by looking in Console or by constructing it yourself from computer’s name and MAC address).
Afterwards you start Disk Utility and create another “sparse bundle disk image” on your local drive. Volume Size should be the designated maximum size (see update 2) of the Time Machine backup (don’t be afraid, only by using the image it will increase in size). Further parameters: Volume Format - Mac OS Extended (Journaled); Partitions - No partition map.
After this use the exact name Time Machine assigned to its bundle image to rename your newly created image (if not already done while creating your own image). Finally you copy the image on the share and manually start a backup via menu bar.
Voilà. Afterwards Time Machine should start the tedious initial backup.
Update: Giving it a try I am positively surprised. After the successful initial backup Time Machine tries to create new backups every hour. And doing so it behaves very ideally. If the network share is not accessible (e.g. host is turned off) the backup simply will not be performed (and the user won’t be bugged with error messages). Nevertheless Time Machine continues to try to access it hourly. If the host comes online again new backups will be created. The needed share and disk image will be mounted automatically.
If you want to access Time Machine to recover files the automatic mounting will work as well. At first (in my case) the Spotlight index was broken. I don’t know why this happened, but I have created an article how to repair this index (currently only available in German).
On the network host which provides the share I have created a special backup user whose home directory contains the image. Fortunately, Time Machine has no problem if a user connects to shares on the host with his own user data.
Let’s face the drawbacks. Once a backup is created or Time Machine is launched the image will indeed be mounted but will not always be unmounted afterwards. Thus, users will have the image on their desktops. The connection to the share itself will also be kept established (but it is only visible by entering mount in Terminal).
Both isn’t necessarily bad if the share keeps being available. However, this does not have to be the case. If you want to disconnect image and share correctly from your Mac you’ll first have to unmount the image itself. Sometimes the system requires an admin password to do so. The share can only be unmounted by calling umount in Terminal. Supposably it will become problematic if the host is shut down while a connection is established or even a backup is in progress.
And of course bandwidth is a major drawback. If (as in my case) the Mac is a MacBook primarily using 802.11g WLAN and accessing the share on a Windows machine via SMB you surely should not expect too much from this solution.
Update 2: Things you should know about the maximum size of the image and the free space on the network share.
Aktuelle Kommentare