1) If I wanted to copy the entire hard drive image (OS X + bootcamp Win7) and have a fully bootable restore, would copying the entire rdisk0 be the way to do it? e.g. dd if=/dev/rdisk0 of=/Volumes/Backup/<filename>.img bs=1m
Yes. But realize that the disk to restore to must have the same, or more, number of sectors. Two "2TB" disks will invariably have different number of sectors, so to go smaller you have to shrink the last file system first. When you go to a bigger disk, everything will just work, even if you don't do anything else. But there are two small issues: a.) the backup GPT won't be at the end of the disk, per spec. The primary GPT will still correctly point to the backup GPT, but it ought to be placed in the correct location which can be done with gdisk. And b.) you'll want to adjust the size of one or both of the file systems, which can be pretty tricky without the use of 3rd party tools specifically designed to deal with hybrid MBRs and GPTs. It's important to understand that Apple's diskutil almost invariably does this wrong, and also sets the MBR partition type code incorrectly, rendering Windows unbootable.
1a) I assume [keyword here] I would need to boot from an external firewire or USB drive to do this (I have one with 10.8.4 installed with utilities) as well as the target .img file also external (could do on same drive?)
I might not be entirely following the question. The source disk, use for if=, needs all filesystems unmounted or at least read only (i.e. single user mode boot). If any source file system is read/write, it'll change as the sector copy is happening, which renders the sector copy corrupt. It usually can be fixed, but I don't advise depending on this. You can boot from the destination disk, set as of=, since in this context you're writing a file to a file system in that direction. When you do a restore, this flips around. You can be booted from the source, since it contains the image file, but the destination needs to be unmounted (which it would be because presumably it's blank).
There's no possible way to sector copy a disk to a file on the same disk because that implies one of the file systems on that disk is r/w and changing constantly, so you'll just create a useless image file. You can sector copy one partition to a file on another partition's file system, however. But that only copies that particular partition, nothing outside of it.
1b) I am not sure of the rdisk0 parameter -- would I need to do rdisk0s1, rdisk0s2, etc?
rdisk0 for the whole disk; rdisk0sX if you only want to image a particular partition.
1b) Could the of=<...> be a network share on my NAS? I mount nfs shares in OS X via NFS (e.g. nfs://xxx.xxx.xxx.xxx/SomeShare)
I also assume that using the raw device vs. the character device is the way to capture the GPT and MBR information correctly.
For backing up, of= can be a path to a remote file system containing an image file, yes. For restoring, if= can be a path to a remote file system containing an image file, yes. But it can't be used as a block device, meaning you can't sector copy (read or write) an NFS volume because NFS doesn't expose the underlying storage as a block device.
Raw vs character device simply is about performance. The character device is always 4K block sizes no matter what you set as bs=, and it copies rather slowly. The raw device allows the bs= to be honored and the copy will be at the highest speed for the lowest common denominator performing drive. What copieis the MBR and GPT is copying the whole disk to a file, rather than a partition.
There are some optimizations possible if you're copying this to a NAS, which almost invariably uses a linux file system that supports sparse files (ext and XFS both support sparse files). JHFS+ doesn't, only DMG files can be made sparse, not ordinary files. So it may be worth looking into because the savings can be huge. What I'm not sure of off hand is the interaction of a sparse file and NFS. I *think* that it's implemented at a file system level, so it'd be the NAS's kernel that returns the sectors with zeros that have been optimized away, to nfsd, so the dd command on the Mac simply works. But I haven't tried this.
