If scripts existed for SSIS I expect someone would have pointed you in the right direction (or Google will find one for you). so I doubt that there is a solution via that route.
I am less sure about a script for precisely what you want. I think most people who want to "copy" a database to a remote server want to do it more often than once-a-week, so it is more usual to use Log Shipping or Replication [which copies the database, continuously, in real-time or near-real-time
For "less frequent" copying I think the most likely equivalent [to find a script for] would be Developers copying a Production Database to a Development server.
My way, copying from above, would be
Set up a backup task, using compression, that outputs to x:\path\MyDatabaseName_yymmdd_hhmm.BAK
Scripts for Backup are readily available, however it is not entirely straightforward. WiIl you use the same filename each time? (if so how will you know whether the file is New, or just the old one from last week?). If you include the Date/Time in the filename then you have to determine a means of copying the newly named file (RoboCopy "Mirror" mode will do this automatically) but you also have to figure out how to delete the file (after a week or two, or after the Restore has been completed on the Remote - in which case the Remote has to communicate back "Restore completed successfully").
You don't have to have this level of sophistication ... but ... if you don't a) how will you know that it has worked? and b) how will you get an alert if & when it fails for some reason? maybe it doesn't matter if it fails?
Suitable backup command would be:
-- If database in FULL Recovery Model ideally make a LOG backup first
DECLARE @strOutputFilename varchar(256)
SELECT @strOutputFilename
= 'x:\Path\' -- '
+ 'MyDatabaseName'
+ '_'
+ CONVERT(varchar(8), GetDate(), 112) -- yyyymmdd
+ '_'
+ REPLACE(CONVERT(varchar(8), GetDate(), 108), ':', '') -- hhmmss
+ '.BAK'
BACKUP DATABASE MyDatabaseName
TO DISK = @strOutputFilename -- e.g. "x:\Path\MyDatabaseName_yymmdd_hhmm.BAK"
WITH
COPY_ONLY
, COMPRESSION
-- , DESCRIPTION = 'text'
, INIT -- This will overwrite any existing file, rather than append
, CHECKSUM
, CONTINUE_AFTER_ERROR -- But consider "STOP_ON_ERROR" instead
, STATS = 10
-- , ENCRYPTION ... if you need that
Having said that, presumably you already have a backup of your databases? If not you need to!! In which case why don't you just copy the most recent full backup file, once a week, instead of making another one?
Use a RoboCopy task with "Mirror" parameter which copies the files to \RemoteServer\Path
You would need to consider what options you need in RoboCopy - personally I would want logging to help diagnose any problems, and you might want specific file types only, all sub folders, and so on.
The basic command is:
robocopy x:\SourcePath \\RemoteServer\Share\DestinationPath /mir
What about sending you an alert (e.g. by Email) if the copy fails? e.g. disk-full on Remote Server, or network down, or DNS cannot resolve the RemoteServer name? (RoboCopy will re-try the copy so intermittent network problems should be fine)
Set up a task on Remote Server which detects a new file and restores it (assuming you need that option, maybe you just want to have the latest files on that server and not actually restore them?)
You haven't said what you want to do with the file on the target server??
Some sort of "purge" which deletes stale files on Source after a reasonable retention time. Using RoboCopy Mirror will cause the files to also be deleted from the Remote Server.
Do you need to keep the backup file after it is transferred? How long for? DO you need to know if the file has been "processed" successfully by the remote server?