It looks like your confusing various concepts here. Start with Transaction Log Management and Backup Overview topics in Books Online.
Is the root problem that when you restore the full backup to another server, the transaction log is consuming more space than you have available?
If so, the hack I described in an answer to the question Is it possible to restore sql-server bak and shrink the log at the same time? might be useful.
Is your transaction log growing, and growing, and growing because your database is in full recovery but you aren't taking log backups? See here and here.
When I backup a database to a bak file is there a way to exclude the
transaction log in that backup?
No. A data backup will include part of the transaction log, at least the section of the log that was generated since the backup started. It shouldn't however be a significant proportion of the log unless you have very long running transactions.
Note that when you restore a data backup, the database will be recreated with the same data and log file sizes as were present in the source database, regardless of how full the data file was or how large the active part of the log was. If this is the problem you're experiencing, see my earlier hack for working around a lack of space to restore.
Or am I thinking about this wrong, to restore the original database is
the content of the transaction log required?
See above, a proportion of the log will be included in a full backup.
I cannot shrink the transaction log because the database is using
replication and I would have to break the replication.
No reason why you can't shrink the log with replication in place (you'll only be able to shrink the inactive portion) but:
- It won't make any difference to the size of your data backup.
- It will probably grow back to it's current size.
- The large transaction log is probably due to not taking log backups.
- You shouldn't be shrinking the log.
If you don't include the transaction log, then it's not really log shipping, is it?
Your full backup is restored to that point in time, and that's where it will stay until you either (a) apply a log or (b) apply a differential or another full backup. Yes, the restore does also bring over the transaction log, but only the state of the transaction log at that same point in time. I guess technically you could argue that you shipped the log once, but the point of log shipping is to keep the secondary server up to date more often than the full backups (which are typically very large in comparison to periodic log backups).
So if your intention is to do this backup / restore once a day, and you don't need to keep the copy up to date throughout the day, just do a simple backup and restore, and stop calling it log shipping.
If you want the copy to stay relatively up to date throughout the day, then yes, it will be mandatory to take periodic log backups on the primary server and restore them on the secondary server. Note that you have to weigh what's more important: keeping a copy of the data up to date, or letting users query stale data uninterrupted. If you restore a log to the secondary server every 15 minutes, you have to kick all the read-only users out every 15 minutes, because you need exclusive access to the database in order to restore the log.
You can read more information about log shipping here:
http://msdn.microsoft.com/en-us/library/ms187103(v=sql.90).aspx
Best Answer
Because when you're creating a full backup you're creating a backup of the data (as it is physically and as it is materialized from the log). Restoring it somewhere else restores it as data, not log.
The original log file might be truncated so the space can be reused, but it's size might stay the same.