Backing up on Windows is possible using robocopy and the /sl option, which only copies the symlink. Although, I haven't been able to find a good solution for compressing the backup. 7-zip treats the symlinks as regular folders creating a much larger backup than necessary.

@Oleg: Hi. I am trying to use the Periodoc Backup Plugin, and it suffers from an issue noted here - it creates a .zip file, but when the .zip file is restored, it has followed the symlinks for lastBuild, lastStableBuild, etc to the associated directories, and these former symlinks are restored a real directories, not symlinks. Subsequent builds shows errors in the logs as they cannot update what shoul dbe symlinks instead of directories. If I just use Windows explorer and copy the .jenkins structure to a new disk, as a back up, then during the Windows copy, it refuses to copy the symlink files, so the symlinks are missing in this case (and the next build creates them). I am just noting these results here, I am mot wishing to re-open this particular Jenkins issue (improvement )here, since I belive it to be working as designed - Jenkins has chosen to use these symlinks, and it is up to any tools such as backup to work correctly with the implementation. I will be opening this issue against the Periodic Backup plugin. Until that is fixed, I will look into the robocopy tool Kevin has suggested.

We are running Jenkins on Windows Server 2008 and we also had to deal with this issue.

Our current solution is just to "tweak" the Windows system. In Windows Server 2008 you can withdraw the permission to create symbolic links for certain users and what we do is to withdraw this permission for the user the Tomcat service uses for its log-on. So, Jenkins just doesn't have the opportunity to create symlinks and creates plain text files instead. These can be zipped as usual.

Newly there's another solution available: 7zip 9.33 alpha and onwards comes with a few new command line switches:

• new -snh switch to store hard links as links (WIM and TAR formats only)
• new -snl switch to store symbolic links as links (WIM and TAR formats only)

Using these switches, it it possible to preserve the symlinks, and they will be restored during "unzip".
The disadvantage of this is that - as mentioned above - these switches are only available for the TAR and WIM formats. These formats don't allow compression. So, you can backup the whole data in one file, preserving the symlinks, but it won't be compressed.

See also the 7zip changelog: http://www.7-zip.org/history.txt

Than for you comment, Michael, I had neglected to update this task regarding how we also resolved it. After my query above, we also resolved the issue in a similar way using cygwin tar. Using a cygwin tar at version 1.7.19 (which supports Windows symlinks), then a compressed tarfile is built, and released to a backup location (via jenkins job). If these tarballs are extracted using a cygwin tar of at least the same version 1.7.19, running under administrator account (which is required to created symlinks!), and having the following environment variable set: CYGWIN=winsymlinks:native, then the symlinks can be restored successfully.