Restore from copy of SQL Server backup file produces invalid data error We have an instance of SQL Server 2008 R2 SP2 sitting in a DMZ.  When I back up one of its databases to a drive local to that server, then run a RESTORE VERIFYONLY against the backup file, it declares the backup set valid.

If I subsequently robocopy the backup file to a mapped drive, pointing to a server located in our domain, then run a RESTORE VERIFYONLY (or a full RESTORE DATABASE, for that matter) against the copied backup file, while connected to a SQL Server instance which is also in the domain (running SQL Server 2008 R2 SP3), the subsequent RESTORE returns the following error message:  

    Msg 3203, Level 16, State 1, Line 1
    Read on "&lt;Backup file path&gt;" failed: 13(The data is invalid.)
    Msg 3013, Level 16, State 1, Line 1
    VERIFY DATABASE is terminating abnormally.


This happens consistently and is repeatable.  Anyone have any ideas as to what might be corrupting the copied backup file?  Does robocopy feature any validation flags that might be useful?  What's the best way to troubleshoot this?
Since the local copy of the backup file is validated successfully via RESTORE VERIFYONLY, the most likely cause of the issue is corruption of the target file while it is being copied over the network.  

You can determine if the two copies of the backup file are binary-identical with the command-line utility fc:

fc /b C:\some\local\path\file1.bak \\server\share\path\file2.bak


Alternately, you could generate a cryptographic hash of each file, and see if the hashes are identical.  Microsoft offers a command-line tool for that purpose at https://www.microsoft.com/en-us/download/details.aspx?id=11533

If both files are binary-identical, the restore should complete without error.