What options exist for copying data between servers on a regular basis?

My apologies if this has already been answered. I've searched SO and of course here on DBA, and am surprised to find no close matches. Specifically, I'm looking for a solution which survives schema differences.

I finally got a development server with which to shadow a production data warehouse server. I'll be testing schema and sproc changes here, eventually publishing such changes to the prod server. To do so, I'll need reasonably current data, but it need not be updated in real time. My plan is to copy end-state data from the main server to the dev server as the final step in overnight ETL. What's the best way to achieve this?

Parameters

All automatic copying will be from prod to dev. Any copying from dev to prod will be by hand, and generally will just be DDL.

Because the dev server's schema is expected to change independently of the production server, I don't want the copy process to fail when the target schema differs (it's OK if the specific tables in flux can't be kept in synch, of course). Otherwise I would just DROP DATABASE and restore last night's backup.

Keeping the schema, SPs, views, and UDFs in synch is not necessary, or even desirable. They should only change when I specifically change them.

Records can be changed retroactively in most tables, so incremental updates will probably not be practical.

The volume of data is 14 GB for the most critical tables, plus about 200 GB of less important data which can be updated weekly.

My goal is to finish the process within two hours. The servers are co-located, and should have high throughput. Copying (INSERT INTO..SELECT * FROM ProdServer..) a single table with 600 MB of data and 300 of indices took 7.5 minutes; not great. Of some concern, another table with 11 GB of data and 8 GB of indices did not finish in 130 minutes, when I cancelled it. I'll test this again without indices.

Taking the prod database offline is acceptable if it can be kept brief - no more than 30 minutes. The dev

I'd consider backup/restore of a mix of full and differential backups from prod to dev.
Then synch between this restored copy to your actual dev databases

SQL Server 2008 R2+ supports backup compression in Standard Edition (In SQL Server 2008 it was Enterprise Edition only) which makes this easier.

Reasons:

• You test your backup integrity and restore capability

• You can reset your dev database easily if some code monkey bollixes it

• You can compare "before" and "after" DDL, performance etc

• You can snapshot the restored database as needed to roll this back if you make changes

I've used this before and will use it again for these reasons

I suggested this in my answer to The smallest backup possible ... with SQL Server

StackExchange Database Administrators Q#19095, answer score: 2