Shrinking bigger databases
Shrinking will probably take quite a while 


It will definitely with that size of data, unless by some fluke most of the free space is at the end of the file.


  and I am not sure what will happen if something goes wrong


The operation should be safe even if you experience a complete power-out and the server shuts down uncleanly, pages are copied then relinked as needed, then the old pages unallocated, in an atomic fashion.


  and if it's OK to do backups in the middle of shrinking.


You can take backups during a shrink, though they will take longer as there will be extra IO contention. You could stop the shrink operation and restart it after the backups are complete - it should pick up (more or less) where it left off. 

Another option is to shrink in small increments when the server is otherwise quiet so that it doesn't conflict with your users either (i.e. if most of your user activity is between 0800UTC &amp; 1900UTC and your full/diff backups and other maintenance like ETL processes usually happen between 2200 &amp; 2330, perhaps running partial shrinks between 0100 &amp; 0700 would be best. If your app has global reach then this is less useful as you won't have quite the same distinct busy/quiet periods.

Don't shrunk right down to the data size though - leave yourself enough space for some months worth of expected data growth. No point fragmenting the data more than you need to as the space saved will just get reclaimed soon enough.