First thought based on comments...
Use differential backups every, say, 6 hours, to reduce the size/time of backup + FTP. Then reduce your full backup + FTP to weekends only. This avoids complexity of log shipping, simple to do, and only adds slight complexity to DR
I feel that differential backups are overlooked... I've suggested using them before:
Edit: after jcolebrand's comment I'll attempt to explain more
A differential backup only takes pages that have changed. Outside of any index maintenance (which can affect a lot of the database), only a few % of pages will change during a day. So a differential backup is a lot smaller than a full backup before any compression.
If you have a full backup, say weekly, you can then do daily differentials and ship them off site. A daily full backup with differentials will still require both files off site.
This should solve the problem of getting data from A to B, C and D quickly.
You probably need to restore both the full and latest differential to get the latest data but you can maybe work around this with NORECOVERY and a STANDBY file (I haven't tried it with a diff restore for years since I was last in a pure DBA job).
An added bonus is that diff backups are unrelated to ongoing log backups so you can separate any High Availability/DR requirement from the "get data to the code monkeys" requirement.
I see some issues if you have daily full backups by policy or audit, but the diff restore can be applied before any log restores to shorten recovery time. Unlike backups, diff and log restores do interact.
Hope I've covered most bases...
This error means that you "striped" your backup across multiple files, and you're only providing one of the files when you're trying to restore.
If you're backing up using SQL Server Management Studio, make sure that you click "remove" to remove any existing backup destinations before you "add" the file you want to back up to.
Best Answer
In SQL Server Management Studio (SSMS), you can generate a script that would create the structural components of your database (tables and views, as well as users, functions, and procedures). You could use the script(s) returned on your development DB.
To run this, right-click on your database in SSMS, and choose Tasks => Generate scripts.... This opens a wizard that will step you through the process, giving you the option of what you want to copy over.
For tables, there are advanced options you can set. This allows you to include indexes and triggers, and to include the data in the tables. However, this would give you all the data from the tables, not just a selected amount.
If you want all the data from selected tables, and no data from the rest, then two passes through this will let you generate two scripts.
In the first pass, select everything, script things as "DROP if exists" (assuming you want to replace anything that's already there), do not include data, and save that as a single script.
In the second pass, only select the tables that you want to copy over the data for; do not choose the "DROP if exists" option; and do include the data, saving this as a second single script (or, if you prefer, as one script per table).
NOTE: This creates scripts that you would run on your database, rather than true backups.