Crystallography on OS X
meaningless logo





Return to Crystallography on OS X


Making OS X a viable Unix Platform

Installing X Windows

Installing Developer Tools

Installing Fink

OS X Unix Links

OS X Unix Advice Board


Crystallography Programs

Use Fink to Install Crystal Software

Installing CCP4

Installing CNS-1.2

Installing Solve

Installing Data Processing Software

Installing Eden

Installing Molecular Display Packages


Other Links of Interest

Various Useful OS X Programs

Backups

Screenshots

Biophysics on OS X

NMR on OS X

W. G. Scott Research Group


Return to Crystallography on OS X

Click here for web site index






Backing up HFS+ filesystems with resource forks:

Standard unix utilities, prior to 10.4, like cp, tar (and gnutar), pax, dump, etc., will not work correctly with the HFS+ filesystem disk format that is the default for an OS X installation. This is because these tools do not honor resource forks, which as far as I know are unique to Apple computers. Thankfully, with the advent of 10.4, many of these tools now work with resource forks.


A.  What are the options?

As of 10.4, pretty much any option that you might want to use should work without heroics.  In case of doubt, or older installations, I will leave the descriptions below (since they still work).

There are several utilities, and a few commercial programs, that have been developed or modified from their standard unix cousins.  These include, but are not limited to, the following:


1.  /Developer/Tools/CpMac   You already have this if you installed the developer tools.  CpMac is essentially a version of cp that appears to behave properly with resource forks.  Watch out, the -p argument doesn't appear to work.  

2.  hfstar   This is a hacked version of gnutar that you can install in /usr/local/bin or can now install with fink.  It can peacefully coexist with the normal tar installed by fink or Apple. It takes all of the arguments that gnutar takes, and otherwise behaves identically except for the fact that it deals properly with resource forks.  Because of this a tarball made with hfstar will be incompatable with the normal gnutar, so if you back something up with hfstar, you have to use hfstar to unpack it.  Keep your life simple and just download the precompiled binary and stick it into /usr/local/bin, or use the fink installation script.

3.  hfspax is a modified version of the standard Mac OS X and UNIX tool, pax.  The Readme.rtf explains all about resource forks, etc.  This is also available via fink.

4.  psync   deals with resource forks and allows incremental backups.  This is a perl utility that overcomes the limitations of cp.  It too is now available via fink, and remains my backup utility of choice. Here are directions on  how to install it manually, if you don't want to use fink.  (Note that for 10.3.x you need a patch and you need to use gcc 2.95, at least currently.)


5.  ditto will copy whole directories with resource forks intact:  
# ditto -rsrcFork directory backupdirectory

6.  A commercial alternative for proper backups of stuff with resource forks and that allows easy GUI-interface automation, is Retrospect Express.   The first OS X version was problematic, but those problems have apparently been fixed with the update release, but please double-check with people who are using it, because there are some reports that it causes kernel panics.

7.  A shareware utility (which he insists should be free to educational users) that is very useful for making clones of bootable drives is called Carbon Copy Cloner.  "Have you ever wanted a simple, complete, bootable backup of your hard drive?  Have you ever wanted to upgrade to a larger hard drive with minimal hassle and without reinstalling your OS and all of your applications?  Have you ever wanted to move your entire Mac OS X installation to a new computer?  Then CCC is the tool for you!



B.  How do you use these for backups?


I'm just going to tell you how I do backups.  There are many ways, some of which may be much better.


1.  First, find a remote device to back up to (another computer, a RAID, etc.).  This should preferably be in another building in case your building burns down.  (As Kissinger once said, "It's when you stop being paranoid, that's when they get you.) Paranoia in systems administration is a Good Thing.



2.  Second, NFS mount your backup device.  This will allow you to do nightly incremental backups at say 2:00 am. You will need a static IP address for your computer, and a cooperative systems administrator for the computer hosting your backup device.  Assuming this backup device is on a standard unix computer, you (or the administrator) will have to add a line to your /etc/exports file that looks like this:

/disk1/filesystem/mybackups bakunin.domain.edu
Then, as administrator, activate the export on the remote machine, probably with a command of the type  
# exportfs -a
burning down the lab

This example assumes you have a static IP address on your Mac that corresponds to bakunin.domain.edu, and the name of the disk filesystem you want to use as your remote backup device is simply /disk1/filesystem/mybackups. You'll need to change this for your own situation. 

(Automount now works properly in 10.3.x.)

An alternative to using NFSmanager is to use the normal unix fstab file, and tell your operating system to look for that file.  You can control this in 10.2.x using /Applications/Utilities/Directory Access.  This is described in detail in OS X for Unix Geeks.  I haven't tried it.


Note that in order to have write permission to the remote device, you must have the same user id (eg: 501) on both machines.  If you need to change this one one of the machines, be sure to go to the directory ABOVE your home directory and, as root, issue

# chown -R yourusername yourusername/  

assuming yourusername corresponds to the name of your home directory.



3.  Create a backup script to be run by cron.
 For backing up all of my work on a daily basis, incrementally, I use psync (which is the program behind the CarbonCopyCloner GUI).  I used to use hfstar and a shellscript, described below in small print.


A.  Incremental backups onto an HFS+ formatted volume called /Volumes/Backupdisk

This is very easy to do.  After installing psync, just issue the following commands, or put this into a shell script to be run by cron:


% mkdir -p /Volumes/Backupdisk/yourdirectory_backup
% psync   /Users/yourdirectory  /Volumes/Backupdisk/yourdirectory_backup


This copies all your files in /Users/yourdirectory  into /Volumes/Backupdisk/yourdirectory_backup.   If current versions of any of those files already exist in the backup directory, it will only copy the new ones.  This saves a lot of overhead.


B.  Incremental backups onto a UFS formatted volume like a unix RAID or UFS hard drive.

I have a normal unix formatted RAID that is NFS-mouned to my Mac.  This means that I have to worry about breaking resource forks if I simply copy or psync my files onto the UFS device.  I used to do this with hfstar (see below), but this way is much more elegant and straightforward. Now I make a disk image that can be stored on a UFS without breakage, but when opened up, creates an HFS+ formatted virtual disk onto which I can do incremental backups.   The virtual disk thus becomes a mirror of my home directory that gets synched every night.  Here is what I do:

1.  Create a sparse disk image on your UFS device.  This is a disk image that only takes up as much space as you need, and can grow to a pre-set upper limit.  I chose 60GB as an upper limit.  You can do this either with Disk Utility or using the following unix command:


% cd  /automount/static/nfs/archive/yourdirectory/daily/
% hdiutil create -volname nightly_backups -encryption -type SPARSE -size 60.0g -fs HFS+ nightly_incremental_backups


It is a good idea to encrypt the disk image, so someone can't break in.  Choose a password or passphrase unique to this disk image (you will be prompted by a GUI window) and tell the keychain to remember it (a checkbox that is unchecked by default).


2.  Create a shell script for running the backups, and put it somewhere like ~/bin or ~/Scripts or ~/Library/Scripts.  I call mine daily.zsh.  Make sure only you (the owner) can read it, because it will have your disk image password in clear text (this is needed only if you want to do backups when you are NOT logged in.)  Here is the content of my backup shell script.  You will have to alter this to fit your own needs.


3.  Protect it, since it has a clear text password inside:    

% chmod 700 nightly_psync.zsh


You only have to put a passphrase in this if you want to do backups while not logged in.  A cleartext passphrase in a shell script is a security hole.  But so is an unencrypted disk image.  Choose your evil (or avoid both pitfalls by leaving yourself logged in and require a passphrase to get beyond your screensaver).  If you have anything truly private, encrypt it BEFORE backing it up.


4.  Tell cron to run the backup script at a convienient time (like 1 am):


% crontab -e

then enter a line like this:

01 01 * * * sh /Users/myusername /bin/daily.zsh   2>&1 | tee /Users/myusername/Current/logs/daily_backups.log
 
          or simply put a line in your /etc/daily.local file to run it under your username:

          su myusername  /Users/myusername/bin/
daily.zsh







Also of potential interest: I just found a free program that lets you use your digital video camera and DV tapes to back up a tarball.

 Click here for web site index

Valid HTML 4.01!