Sorry, I was typing while you posted so ...

I'm trying to avoid imaging the entire disk but only as much as is occupied by actual data. Using the "count=..." parameter of dd to limit how much is copied. But to do that I have to know that the data is all located at the beginning of the disk ... that's why I'm shrinking the partition.

This is confusing. Why would you buy a 64GB SD card to only use the first 8GB, or whatever, of it?
I do understand that it takes a long time to image a card so how about just copying files? Why are you trying to only dd the first few blocks of a card you're not using when a smaller card could likely be had for very little at all? Are you completely sure that dding will work as a backup with only partial data on any card?

I'm not sure. That's what I'm trying to determine. I can tell you that I have done this with a 16GB card that contained (so far) less than 3GB of data. I used gparted to resize down to ~3.5GB. I then used dd to copy just the first ~3.5GB (the exact number of sectors that were occupied by the now-reduced partitions) to another SD card. The second card does successfully boot the Pi and so far seems to be fully-functional. I haven't yet found anything on it to be missing or broken.

As far as why ... well in part this is a theoretical question, so I'd just like to know if the method is sound and reliable. But from a more practical point of view, let's say that much more of the card will be used, it just hasn't been used yet. Or let's say maybe I'll create a third partition to store data of a more transient nature -- video files for example -- and I want to create an image of the entire installation (boot partition and root filesystem) excluding the third partition.

Of course there are other ways to accomplish that; there are other ways to do almost anything. I just want to be sure that this particular method is valid.

There are a number of tools that would give you better control over this procedure than "dd" - starting with fsarchiver, rsync, and tar.

Well, it took long enough but the zipping the the 32GB SD card image has finished and it comes in at around 7.2GB which is smaller than the 8.7GB of files on the card. So, yes, it takes forever to dd and then zip but it does save space.

By way of comparison, after resizing Partition 2 on my 16GB card down to about 3.5GB (which took maybe a minute), dd took 17 minutes to create the 3.7GB .img file, and xz took about 23 minutes to compress it down to a 1GB .img.xz file.

@TXLonghorn:
Thanks, but I don't think any of those tools apply here. We're discussing how to create a raw disk image that can be flashed to an SD card and provide in a single step a ready-to-go system with multiple partitions and complete filesystem. I don't think fsarchiver, rsync or tar can span multiple partitions, can they?

A thought occurs -- surely you could. Set if=/dev/sda1 (or whatever) and just dd the partition? I have to admit I'm not sure how that would or, indeed, could be restored but it may work.

Sure that would work, and it would be easy to restore to the same sd card, but to put it on another card (e.g. to prepare multiple RPi's with the same setup) would require backing up both partitions separately, then formatting the next card with the exact same format as the original, and then separately copying those partition backups to the new card. The method I described (post #8) does the whole thing at once (plus a minute to reduce the partition size with gparted, and another minute to expand it again after the copying is done).