Going back to Krasavita's original question: how long will it take to back up 600GB?

As seen in the replies, the answer depends on many things. To a large extent, the more money you have to throw at the solution, the faster it will be providing you have people who know how to spend the money wisely (rather than people who just spend money...).

One thing I did not see explicitly mentioned is the number of backup files. This can also reduce run time because SQL Server backs up a portion of the database to each file in parallel to each other. It is useful if your storage subsystem can handle the IO load, but can actually slow things down if you saturate your storage system with write requests.

The starting point to your solution should be the duration and performance impact of your backup window. If your backup window allowance allows you to backup 600gb in 4 hours and the backup completes in 3 hours, then you have no problem. If it completes in 5 hours then you need to look at how you can improve performance. If your backup runs without impacting the performance SLA of your OLTP system then you have no problem. If running a backup effectively stops your OLTP system then you need to look at how you can improve performance.

Even if you have no problems today, you should experiment to see how big your database will be or how busy your OLTP will be before you start to get problems. You can then do some capacity planning to predict when this will happen with live data, and get a budget organised to sort out the issues before they become problems.