It sounds as if this isn't supported. From this bug report info:
There's been a lot of interest in this one, so I'll go into a bit more detail as to what is happening behind the scenes, and what it would mean to implement this functionality. Some types of index pages are segregated into separate allocation units, while others are mixed in with the data pages. Where we currently only look at the allocation bitmap to see if an extent is allocated, now we would have to go in and interpret what is stored in each allocation unit. Further, we would now not be able to just do a linear scan of the data files copying data, we'd be skipping around in the file. All of this interpretation of the data structures would drastically slow down backup. Restore gets even more interesting, because there are a lots of structures that would have to ba fixed up to account for the holes in the backup. Otherwise you'd have allocation maps pointing to pages which weren't backed up, and so have garbage in them, etc. etc. So, implementing this would mean that we'd save less data, take longer doing it, and take much longer restoring it. The other facet to consider is that this would take a large amount of engineering effort to get it all right. While that's not your problem on the surface, consider that it means that other features you may want to see wouldn't get built.
There's been a lot of interest in this one, so I'll go into a bit more detail as to what is happening behind the scenes, and what it would mean to implement this functionality. Some types of index pages are segregated into separate allocation units, while others are mixed in with the data pages. Where we currently only look at the allocation bitmap to see if an extent is allocated, now we would have to go in and interpret what is stored in each allocation unit. Further, we would now not be able to just do a linear scan of the data files copying data, we'd be skipping around in the file. All of this interpretation of the data structures would drastically slow down backup. Restore gets even more interesting, because there are a lots of structures that would have to ba fixed up to account for the holes in the backup. Otherwise you'd have allocation maps pointing to pages which weren't backed up, and so have garbage in them, etc. etc. So, implementing this would mean that we'd save less data, take longer doing it, and take much longer restoring it. The other facet to consider is that this would take a large amount of engineering effort to get it all right. While that's not your problem on the surface, consider that it means that other features you may want to see wouldn't get built.
