2>&1 just says "redirect handle 2 (STDERR by convention) to the same place as handle 1 (STDOUT).

If it was preceded by 1>my.log, then output from both handles would end up in same file. In the case of redirection to nul, this is effectively the same as doing 1>nul 2>nul, but if you tried to do 1>my.log 2>my.log you will get

The process cannot access the file because
it is being used by another process.
[download]

under win32. When the file is opened for the first handle, it is opened for exclusive access, so when the the attempt is made to open it for the second handle you get this error.

Order is also important. If you try  2>&1 1>nul, then you are asking for handle 2 to be redirected to the same the as handle 1, which is the terminal by default (and the same place as the default for handle 2), you then redirect handle 1 to the nul device, but this does not also redirect handle 2, so output to STDERR wil still end up on the terminal and only the output to STDOUT will get bit-bucketed.