The question is slightly different (I was asking if a restore can rebuild fragmented indexes), but this answer (from a former member of the MS SQL engine team) applies directly to your situation:
A backup is a physical operation, not a logical operation. It reads all extents containing allocated pages (i.e. even though only a single page from an 8-page extent is allocated, it will backup the entire 64K extent), and it does it in physical order.
Rebuilding an index (or anything like it) is a logical operation, which must be logged. Backup and restore manipulate the data files directly, without going through the buffer pool, which is one reason why this cannot be done. Another reason this cannot be done is that backup and restore have no understanding of what is contained in the data being backed up....
Bottom line - backup and restore are physical operations that never change the data.
So in your case (and consistent with Tony's answer), there are no possible settings for backups or restores that can ignore/drop/add/rebuild indexes, since those are all logical operations, which would have to be properly logged.
I concur with Tony that the most likely scenario is some sort of data load process that drops indexes to optimize import speed. Perhaps the nightly data load was interrupted or failed, or perhaps the full backup took place in the middle of the job after the indexes had been removed but before they were re-added.
