Shrinking during backup
Are you shrinking before backup in the hope that it will reduce your backup time?  If so that will not make any difference. But if you are doing it so it allocates less space on your target (when you restore) then it will help.

I did not understand if you are doing this every time before backup. If yes you want to resolve this permanently and not do this.

Now to answering your question.

Is the results of the shrink sitting out in tempdb somewhere ready to go?

It does not have to keep the result. It will check everything again once you restart.

To get this shrink done a little quicker, does anyone think running a larger shrinkfile during the backup that I know won't complete is a good idea?

No, because it does 32 pages at one time and commit. See below.

Reference: https://blogs.msdn.microsoft.com/psssql/2008/03/28/how-it-works-sql-server-2005-dbcc-shrink-may-take-longer-than-sql-server-2000/


  Shrink works in transaction batches of ~32 pages.   Once 32 pages are
  moved below the truncation point the transaction is committed and a
  new transaction started.   This avoids an older issue with shrink*
  that kept a transaction open for a long time and caused the log files
  to grow because you can’t truncate past an active transaction.   It
  also makes shrink* restart capable.    If you cancel/kill a shrink*
  operation only the current active transaction is rolled back.   This
  means you could schedule a shrink* operation during a maintenance
  window and limit its runtime to that maintenance window.    You can
  restart it during the next maintenance window and it will pick up from
  where it left off.   The only disadvantage to this is that allocations
  could occur after the target once the shrink is terminated.   This may
  require shrink to do additional work for newly allocated space but
  this should be reasonably limited.


On a side note backing up 2TB should not take a full day. There are switches in native backup, can speed up/optimize your backup duration.