Slashdot Mirror


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)?"

12 of 56 comments (clear)

  1. Why would I use this over Dantz Retrospect? by Anonymous Coward · · Score: 5, Interesting
    $99 PER CLIENT?? I thought Retrospect's pricing was awful, but these guys really take the cake. For $99 I could buy every machine on the network a second hard drive and just clone to it.

    This product doesn't even support the APPLE superdrive, for pete's sake.

    1. Re:Why would I use this over Dantz Retrospect? by yummyporkproducts · · Score: 5, Informative

      Because retrospect is a worthless piece of shit. We struggled with it for years, because it was the only backup option that supported tape on OS X. It had a problem with just not running on schedule, quitting mid-backup, and others. Retrospect doesn't even support the APPLE Xserve RAID, for pete's sake (or didn't until the latest version, 6, which is a paid upgrade for a product that never worked well in the first place). BRU works well - we've found that it backups and restores reliably, and we can script it from the command line.

  2. Context!!! by samael · · Score: 5, Funny

    Aah, yes, BRU LE, that fantastic program which......

  3. Just one question... by Intellectual+Elitist · · Score: 5, Funny

    So where's the companion program "CRE ME"?

  4. Backup on Mac OS X by atomic-penguin · · Score: 5, Insightful

    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/

    --
    /^([Ss]ame [Bb]at (time, |channel.)){2}$/
    1. Re:Backup on Mac OS X by Graff · · Score: 5, Informative

      As I mentioned in an earlier post be very careful with some of the copying/archiving utilities that come with Mac OS X. Many of them are not intended to copy Mac files, these utilities often strip metadata and resource forks and end up ruining files.

      Instead you need to use alternate tools included with Mac OS X such as ditto, CpMac, and hdiutil. There are also 3rd party utilities such as the tar replacement hfstar (located at the bottom of the page), and the rsync replacement RsyncX.

    2. Re:Backup on Mac OS X by Permission+Denied · · Score: 5, Insightful
      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 :)

  5. looking for good mac backup software by Anonymous Coward · · Score: 5, Interesting

    I've been trying to find good software for backing up the mac too..

    Retrospect Express works, and that's what I currently use, but it suffers from typical closed-source problems. They ported it to Mac OS X but didn't improve the interface which is still a little awkward. The whole architecture of the program is still geared around OS9 single-user. And it doesn't correctly archive Unicode filenames (I had a bunch on my hard drive and finally gave up and renamed them all english). It also only supports FTP for remote backups, not SFTP/SSH or rsync. Basically it seems "stuck" in its current feature set.

    BRU?? I tried installing that on my Linux machine a long time ago, it didn't come in any package and it littered the hard drive with "hidden license files" which had backspaces in the names to hide themselves. I don't know what it does on the Mac, but no thanks.

    I have a big RAID server where I back up all my Unix machines with rsync. What I really want is to back up my Mac the same way. But I'm not aware of any rsync that will correctly copy resource forks to a filesystem that doesn't use them natively.

    There is a Mac OS X rsync, but it only copies resource forks to other Macs, as far as I know. Not to a non-HFS filesystem.

    What I really really would love is an rsync that copies the resource forks to hidden files the same way the Mac copies them to non-HFS partitions already. So I could mount the backup directory via NFS and all the resource forks would be recognized.

    I have considered the option of mounting the backup dir via NFS, and using resource-fork-aware rsync locally to the NFS directory, but would rather do it over the network.

    Are there any rsync ports that do this??

  6. RSyncX for resource forks by JJSpreij · · Score: 5, Informative

    the default rsync included with OS X isn't aware of resource forks at all...

    RSyncX will copy resource forks, but only to another OS X system running RSyncX with a HFS(+) filesystem.

    --
    "These are my principles. If you don't like them, I have others." --Groucho Marx
  7. Carbon Copy Cloner by SimonDorfman.com · · Score: 5, Informative

    Carbon Copy Cloner works very well. I just did a backup of my powerbook to an external firewire drive using CCC before sending the powerbook in for repair. Now I'm booting from the firewire drive on my old iMac until I get my powerbook back. Seemless. http://www.versiontracker.com/dyn/moreinfo/macosx/ 13260M

    --

    --
    A little nonsense now and then is cherished by the wisest men. -Willy Wonka
  8. use psync by noisia · · Score: 5, Informative

    psync is a great, easy to use tool for backing up OS x. It copies resource forks, and makes a fully bootable copy of the hard disk. Easy to script it into your /etc/daily file as well. I believe that ccc is a front end to psync as well.

    not a shill, just a happy camper.

    http://www.dan.co.jp/cases/macosx/psync.html

  9. Some other useful standard tools by rohanl · · Score: 5, Informative

    You might want to look at: /usr/bin/ditto copy files and directories to a destination directory /usr/sbin/asr Apple Software Restore
    Read the man pages for more info. Both these are standard in Mac OS X (Panther at least, not sure about older releases) and handle resource forks properly.

    asr is actually the command line backend that the Software Restore Disk that shipped with your computer uses.