This is late to the party, but for the permanent record, the experience with /Z switch is unlikely the source of the problem. Robocopy simply doesn't do unbuffered IO. In my experience on win2k3 you'll get that aggressive trim behavior from any kind of copy operation that does it buffered when the file is read into memory.

Only two options for win2k3 that I've found, use unbuffered IO utility (such as eseutil) to push the file from the SQL box to the destination box) or enable Lock Pages In Memory for the SQL process (that's a commonly suggested setting for x64 SQL on Win2k3 (but not win2k8)).

I have not experienced the same memory issue on windows 2k8 when copying, but I have limited real life experience since production env is 2k3.

ESEUTIL or RICHCOPY can both do unbuffered pushes (network pulls are always handled by win2k3 as buffered operations)