Hi Aditya,
Table and index compression would likely be a good way to reduce conventional backup times. You should also check for and correct any severe tablespace size skew since that can reduce read parallelism as the backup progresses. Ensure that your LUNs have a queue depth much higher than the AIX default of 3, and that you have configured enough prefetchers and a reasonable degree of IO parallelism. Finally, the SAP default extent size of 32KB is IMHO bizarrely small and detrimental to backup performance in most cases. A more normal extent size of 128KB or 256KB, aligned to the RAID strip size, is better. Unfortunately this requires new tablespaces, but you can migrate online while compressing at the same time.
Also make sure that you have enough sessions if you are using TSM. I have a customer with a 4TB ECC database, compressed. They have implemented the above changes and use 3 or 4 sessions. The online backup takes about 3 hours, not that amazing but better than a day. In short, your challenge is to eliminate all IO bottlenecks :-)
The aforementioned will improve big read performance generally. Snapshot backup is another option but too much to explain here I feel. One downside of snapshot backup is less flexibility in that you cannot restore just a single tablespace nor can you restore to different containers. However the performance advantages may far outweigh this.
Jeremy