How to keep off-site developer databases up to date with production?
I manage a DB environment for several tier 1 telcos and our data/environments are distributed across the world, there are many ways you can achieve what you're looking for but it depends on your pain points.  

Questions:

-How big are the databases, how far are the nodes (or more importantly what is the latency between them), and how much bandwidth do you have?

-How much transaction log activity do you generate?

-How often do you want to restore?

-Are you enabling data compression on the backups?

Some Lessons Learned

-One thing I noticed with copying data across the world is that the Windows CIFS protocol absolutely sucks for doing this.  It is highly inefficient.  

We ended up using HTTPS and issuing a GET request.  It was over 10x faster copying backups from Asia to Los Angeles.  

Using Multithreading options in Robocopy or other copy programs was useful if you break up the backup into multiple files.  

Some Options:

2 Surprising Linux Solutions  


A solution I really like is to RSYNC with Linux servers on each end and mount the backup folder.  This is really nice as backups are automatically synced using a protocol that is efficient for WANs.  If you don't want to sync ALL of your backups, mount another drive on your linux server that really mounts to a windows share that you will place backups in.  The RSYNC will take care of it from there and do it much faster than CIFS.  Linux protocols are much better for long distance file copying than Windows CIFS based on my experience.  I spoke with some of CCIEs and they stated the same.
You could also look at a VM WAN Optimizer (Google or 'Bing' WAN optimizer or get more specific, for example high latency high bandwidth WAN optimizer or low latency high bandwidth, whatever your environment is) 


SQL Transaction Log Shipping Using FTP is not scary at all.  I had a junior .Net developer get it running fast, although I was impressed and got him hired at another company I worked at.  Problem is you might send a lot more data in a 24 hour period if there are a lot of UPDATES but not INSERTS using log shipping, instead of just copying backups.

SAN File System Block Level Replication: Not sure if you have hardware that supports this, but many mid range SANs allow you to replicate live data to the other ones.  If yours does, this is a great option as it has 0 sql server overhead, unless your network pipe is capped in which case you have other issues.

Transaction replication to a central database:  You could create a replication scheme where you have an up to date copy of the data.  You could then take your backups from that copy so it doesn't have to copy full backups across the wire.

Let us know some of your pain points and we can go through other options.

Also be sure to read this excellent white papers by MS if you go with replication:

Geo-Replication Performance Gains with Microsoft SQL Server 2008 Running on Windows Server 2008