|  [man] dumpfs

  That does exactly what I need, thanks ... :)

Note that dumpfs != dump (but they are culturally compatible).

  My main reason for avoiding dump was that I was under the impression
  that if you had an environment with more than one architecture/OS/fs
  type then each required it's own version of dump - the output of which
  weren't interoperable, whereas tar was pretty much universal.

I've found dump to be pretty interoperable, but you are wise to be
wary - and should check the combination of interest.  For example, I
ran dump on an SGI/mips box under IRIX, and was able to read it on
FreeBSD under i386 - different OS, CPU, and endianness.  But,
basically BSD ffs on both - there is a loose de facto standard for BSD
dump behavior.

  Are there any benefits which outweigh this problem?

The biggest benefit for me is that dump doesn't update atimes.

I also really like the 'nodump' flag (see cflags(1)), and use -h 0 to
have this respected even on full dumps.  My disks are bigger than my
tape drives, and this lets me avoid dumping e.g. gnome/TeX goop in
/usr/pkg, which I'm going to rebuild rather than restore if my disk
dies anyway.

Dump is also traditional in the BSD world.  It's how we did backups in
the 70s, if memory serves me, or at least on 2.8BSD.

In the Linux camp, dump is widely frowned upon, and dump under Linux
on ext2fs may or may not indeed be unreliable.  All my filesystems are
ffs, so I haven't worried about this.

On the con side, since dump doesn't use the filesystem to read (hence
the not updating atime advantage), it can dump active files
incorrectly on active filesystems.  In practice people don't worry
about this too much, and I rarely hear of trouble.

-- 
        Greg Troxel <gdt@ir.bbn.com>