Using MOSS 2007 on SQL server 2005 is there any way to do a "one-way" synch of data from a production server to a standby server? This would be a one-way process only, and can happen daily rather than in real-time. The standby server won't be used at all unless the main server fails, and switchover would be manual.
You have a number of options available to you, and Nick and Tom both highlighted a couple of them. For your specific scenario, I personally find log shipping to be an excellent option. Once you set it up, you can simply leave your standby farm in database(s) in standby/recovery mode until needed. If your primary server/farm should go down, you bring up you standby box.
The nice thing about log shipping is that your functional RPO (recovery point objective) window can be much smaller than the 24 hours you're describing. By default (if I'm remembering correctly), log shipping can take place every 15 minutes. That interval is configurable down to about five minutes, as well. The one big farm change you'll need to make is to ensure that all of your databases are in a recovery mode that supports log shipping (typically full recovery).
Database mirroring is an option, and it has been used to provide near real-time failover capability for SharePoint environments. That flexibility comes with some significant constraints and requirements, though. Database mirroring is very sensitive to network latency issues, so if your production databases and backup server aren't in close proximity from a network perspective, there will be issues. In addition, you'll need to make some changes to your environment that aren't trivial. The links Tom supplied are good ones for some additional background and implementation help.
Depending on your backup environment needs, another option you might consider (one that allows you to bypass SQL Server altogether) is Content Deployment. MOSS' Content Deployment mechanism is an implementation of SharePoint's export and import functionality; you specify source information (source farm and site), a destination (in your case, the backup farm), and the interval of operation, and SharePoint takes care of exporting your site and bringing it into the destination. This is commonly leveraged in publishing farm scenarios, but it could be another possible option in your situation. You can find some additional information here: http://technet.microsoft.com/en-us/library/cc263428.aspx
Finally, another non-SQL option that might work for you is simply scripting the appropriate STSADM.exe -backup operation(s) needed, copying the files across to your backup server, and executing the associated STSADM-exe -restore operations to bring the content in. This isn't going to do really do anything that's (functionally) different from a SQL database export and import, but it's another relatively straightforward option.
The simplest option for you is to setup a sql agent job on your standby that does a daily restore from a backup taken from your primary. You can do the restore over a UNC path to save you the trouble of having to copy the backup.
In addition, you'll need to make sure you keep your logins in sync from your primary, which you can do in SSIS using the transfer logins task.
An alternative may be to use log shipping , although you should take log backups more often then once a day. The downside to this is that you need to put your database in full or bulk recovery mode.
SQL Server Backup and Restore may work fine for your scenario. Another possability is SQL Server's Mirroring. Microsoft wrote a white paper explaining how it works, Configuring Database Mirroring for SharePoint Products & Technologies. I have seen this work with the manual change over described and it doesn't take much to set up after you have read the white paper. You can also find ways to script the manual changes needed for SharePoint after a primary mirror failure like on this blog post.