It was a pretty simple request actually. “Can you copy over the Panama database from FOO\WAS_21 to server BAR\LAX_45?”
“Sure, no problem.”
Of course it was a problem. Here’s the issue. This is at one of my clients. They have a couple of datacenters and have hundreds of servers in each. In addition, they have servers in different AD domains. This helps them partition functionality and security requirements. Normally copying files between servers within a datacenter isn’t an issue. Even copying files between the different domains in the same datacenter isn’t normally too bad. To be clear, it’s not great. Between servers in the same domain, it appears they have 1GB connections, between the domains, the firewall seems to throttle stuff down to 100MB.
The problem is when copying between different domains in different datacenters. This can be abysmally slow. That was my problem this week. WAS_21 and LAX_45 were in different datacenters, and in different domains.
Now, for small files, I can use the cut and paste functionality built into RDP and simply cut and paste. This doesn’t work for large files. The file in this case was 19GB. So this was out.
Fortunately, through the Citrix VDI they provide, I have a temp folder I can use. So, easily enough, I could copy the 19GB file from FOO\WAS_21 to that. That took just a few minutes. Then I tried to copy it from there to BAR\LAX_45. This was slow, but looked like it would work. It was going to take 4-5 hours, but they didn’t need the file for a week.
After about 4.5 hours, my RDP session locked up. I logged out and back in and saw the copy had failed. I tried again. This time at just under 4.5 hours I noticed an out of memory error. And then my session locked up.
So, apparently this wasn’t going to work. The obvious solution was to split the file (it was already compressed) into multiple files; except I’m not allowed to install most software on the servers. So that wasn’t a great option. I probably could have installed something like 7zip and then uninstalled it, but I didn’t want to deal with that and the paperwork that would result.
So I fell back to an old friend: Robocopy. This appeared to be working great. Up until about 4.5 hours. And guess what… another out of memory error.
But I LIKE challenges like this.
So I looked more closely. Robocopy has a lot of options. There are two that stuck out: /Z – restartable mode. That looked good. I figured worst case, I’d start my backup, let it fail at about 85% done and then resume it.
But then the holy grail: /J :: copy using unbuffered I/O (recommended for large files).
Wow… unbuffered… that looks good. Might use less memory.
So I gambled and tried both. And low and behold, 4:19 later… the file was copied!
So, it was an annoying problem but… I had solved it. I like that!
So the take-away: Don’t give up. There’s always a way if you’re creative enough!