If I understand you properly - you want to have a second reporting instance and you are asking how you can keep that updated.
It also appears you are on SQL Server 2005 so your options are limited more so than, say, if you were on SQL Server 2012 with Availability Groups.
Your options are really going to be in the spirit of:
Log Shipping
And here you can actually restore your logs in WITH STANDBY mode - this means that you can effectively query your log shipped database for read only queries anytime. You can read more about that here and at the related links on that article. You cannot add indexes, add statistics, do any writes, etc. But you can avoid creating a snapshot. But you still require the blip of connectivity when the standby restore happens - so you haven't saved much.
Mirroring
Same idea of log shipping (at a very basic level that is) - and here you can read off of a standby. Still ned that downtime of the reporting users to rebuild your snapshot. You can do A/B switching and effectively abstract some of that through views, content switching/load balancing but you still need a downtime for the snapshot change.
Replication
You can use transactional replication and replicate data. This is near real time and updates just happen as they happen on the primary and get replicated (or you can control the frequency). This has more of an overhead on the source, latency really matters, requires a bit more DBA overhead, but it allows you to report on the secondary with no need to worry about standby restores, or new snapshots. Benefit here is you can choose what comes across and what doesn't if the reports only care about certain tables.
ETL
You could always roll your own process to extract, transform and load just the data you care about. This way you can create a reporting optimized version of the database, index it appropriately and stream data in at the frequency you want. You need to worry about concurrency and blocking risk during your loads if it needs to be updated throughout the day, but there are ways of dealing with that. More overhead and developer time required.
And I would really encourage you to think about SQL Server 2012/2014 - AlwaysOn Availability Group Active Secondaries are a benefit here potentially. The main benefit being the read only secondary database. There are some optimizations here including the ability to have temporary statistics created and stored in the TempDB database on the secondary instance. The read only doesn't require snapshots, with standby, etc. It is truly read only - so you cannot write into it - but for reporting this can be a big win. Granted the move from 2005 to 2012 is a bigger conversation, requires licensing conversations, etc. but it is an option here for sure.
If you are talking about HA for SSRS that is a separate conversation.
