BRU LE for Mac OS X

GraWil wonders: "The Tolis Group has just released BRU LE for Mac OS X. It is far more reasonably priced than the professional version but it is still priced well above the personal edition for Linux and BSD users. Does anyone have experience they can share about strategies for backing up Powerbook and Desktop Mac I am using a total of 140GB of the 180GB available)?"

Comments

Re:The solution seems simple...

[altp]

--
Money shouldn't be much of an issue since you're already spending a bunch on the OS, plus you've got two macs sitting around.
--

Just because someone uses macs doesn't mean that they have a bunch of money sitting around.

Yes, Macs are expensive. But there are several good finance programs around that make them much more affordable. Apple Loan is available on their website, and compusa often has a "18 months same as cash"

Backup on Mac OS X

[atomic-penguin]

Not trying to be a troll, just pointing out that OS X comes with perfectly good backup software.

Tar and bzip2 come with Mac OS X, it wouldn't be that hard to script automated full and incremental backups. I do not believe that all OS X come with bash, however they at least come with tcsh. Here are a couple of simple examples.

#!/bin/sh
#example of full backup
date > timestamp
tar jcf home-full.tar.bz2 /home/

#!/bin/sh
#example of incremental backup
lastbackup=`cat timestamp`
date > timestamp
tar jc --newer $lastbackup -f home-weekly.tar.bz2 /home/

Re:Backup on Mac OS X

[Permission Denied]

1. MacOS X has come with bash since 10.0 in /bin/bash. It wasn't the default shell until 10.3.

2. tar will not pick up HFS forks. Resource forks are somewhat more rare in Mac OS X, but they're still there and some programs won't work without them. Finder forks are everywhere in Mac OS X, and while they're not critical, Mac users refused to use a backup system I provided when it did not preserve finder forks.

You can convert HFS resource forks into regular directories/files that will be picked up with tar/rsync/cpio/whatever. Resource forks can be accessed with the syntax "file/rsrc" or "file/..namedFork/rsrc". You can then copy the resource fork into a file called "._file" parallel to "file" and it will be preserved. This is how resource forks are handled on UFS, but it works on UFS and HFS.

So you can do "mv file/..namedFork/rsrc ._file" to prepare file for backup by tar. Put it in a script with a "find" command and you can convert an entire filesystem. (Obviously, do your experimentation somewhere where you don't care if you break your file system.)

Aliases are files with zero-length data forks and the alias information in the resource fork. If you preserve resource forks in one of the above manners, you preserve aliases. Otherwise, you just get regular empty files. I don't know how relevant this is for a backup/archival system as aliases usually break when you move them between systems due to differing volume IDs.

Unfortunately, it's not possible to access the finder fork (creator, type) from the command line using standard utilities. If you want something that also preserves finder forks, it's possible to create, mount and manipulate HFS disk images (.dmg) from the command line using utilities supplied with Mac OS X. The commands you use are hdid, hdiutil and ditto. This is a PITA, but I just found someone who automated it: http://www.kernelthread.com/mac/apme/archive/

Unfortunately, you can't access dmgs using standard utilities on other platforms, so this method is of limited usefulness. One of the main points of using tar (for me at least) is cross-platform compatibility: I need to access these files on non-Mac OS X systems (like a Solaris box or my NetBSD/SPARC machine, platforms that commercial vendors are unlikely to port to) but I would also prefer to have the metadata preserved when moving between Mac OS X systems. Other reasons to use tar are that (1) tar archives will remain accessible virtually forever due to their ubiquity (whereas an esoteric backup program probably won't have a version for OSes ten years in the future) and (2) tar comes standard with MacOS X, so your backup system will always work (whereas you may have to wait for your backup vendor to release a new version of their program for 10.4, 10.5, etc., assuming the company exists at that time, but if 10.4 introduces some incompatibility in a script I wrote, I can fix that myself in minutes), and the final reason for using standard command-line utilities is (3) flexibility: you can do anything from any kind of incremental schedule to simulating filesystem snapshots, selectively choosing which files to back up, how often and where and automating the entire process so it's completely transparent to your users.

Back in the days of 10.0, I had a long list of problems with Mac OS X that kept me from using it as a serious Unix system. Some of these were relatively minor and esoteric problems that I doubt many others encountered. Amazingly, each one of these except one has been fixed by 10.3. The only remaining issue I have with Mac OS X is that I can't access finder forks using POSIX APIs. If someone could rectify this, that would be really nice :)

Re:The solution seems simple...

[burns210]

And then there is always the fact(yes, it is a fact) the mac users tend to keep their computers longer(longer replacement cycle) than do most PC users, so the cost is evened out much more....

Re:The solution seems simple...

[Anonymous Coward]

Yes, Macs are expensive. But there are several good finance programs around that make them much more affordable. Apple Loan is available on their website, and compusa often has a "18 months same as cash"

Holy crap, why does someone suggesting to people who can't really afford it to take a loan at 10% interest to buy a friggin computer get +5 Insightful?

Re:looking for good mac backup software

[ObiWanKenblowme]

I hate to risk getting modded down by pointing out the flaws of open source advocacy, but I find it funny that your first complaint after the fact that it's closed source is that the interface is awkward. Maybe I'm way off, but for the most part it seems to me awkward interfaces are a staple of open source software. Don't get me wrong, I like the idea of "free" in all its incarnations, but opening source unfortunately doesn't (usually) mean the interface gets better.