Following on from ahmeds08 - consider implementing a regular review of index usage - which is all basic information available via DMVs. During these reviews - work ith the app owners to discuss and analyse indexes that have have large amount of writes with very little or no reads. Usually a hint that that the index is added to but then not read. Of course, make sure there is a good understanding of the queries - before you start dropping indexes.
Check these site: http://www.sql.recoverytoolbox.com/ & download demo Recovery Toolbox for SQL Server. Depending on how you are loading your data, you may need to break it up into smaller chunks. Make sure you are not loading all the data in one large transaction.
I dont see any benefit in including Index rebuild in backup plan. MP behaves little erratically when multiple steps are there. I would like you to create separate plan because backup is MUST task for every day while same is not the case with index rebuild. Only rebuild when index is fragmented and having sufficient page count
In a busy production environment - where there can be a requirement for a 24 x 7 requirement on database servers - the backup window can be narrow. Adding index rebuilds increases the window. Index management is a priority but is more flexible if you can break the tasks down