Secondary reporting SQL Server I have a SQL Server 2012 Std cluster that has a lot of writes going on. We'd like to offload some of the reporting to a separate (2012 Std) VM. It can be around 24 hours out of date. 

I think log shipping is probably a good approach but I'm concerned I won't be able to compress the tlogs (they'll be big). My question is, can I manually set up log-shipping, essentially leaving the primary untouched and just restore 24 hours worth of transactions on the secondary each day - whilst still being able to read from the secondary during the day?  

EDIT: After doing some testing and with the help from users here, it looks like I can just "manually" restore 24 hours' worth of backups each day by going SINGLE_USER then restoring all the tlogs WITH STANDBY, essentially log shipping but without touching the primary at all.
I think log shipping is probably a good approach but I'm concerned I won't be able to compress the tlogs 


Since you are using logshipping on SQL Server 2012, you can compress your transaction log backups 




  (they'll be big).


Take frequent log backup, so that the size of the T-logs is manageable and you are using backup compression (see above screenshot). The minimum is 1 min. 


  My question is, can I manually set up log-shipping, essentially leaving the primary untouched and just restore 24 hours worth of transactions on the secondary each day - whilst still being able to read from the secondary during the day?


Yes you can do what you are saying. You can delay the restoration of log backups on the secondary server. So, just have to copy job to copy the log backups from primary to secondary and depending on your need and business requirement, you can delay the log restoration. 

Note that when T-logs are being restored, users will be disconnected.



EDIT:

You can put inplace of allowing only COPY_ONLY log backups so that it does not break your log backup chain. I have written it in my answer here. Also, remember that a full backup will never break a log chain. It can mess up a differential backup though. So, its a good practice to have COPY_ONLY backups!