Migrating backup data to replacement drive

Server
1

Running UrBackup on Windows server, the current backup data is on D:\UrBackup but I need to replace the disk - it’s larger and space is getting low. I have mounted the new drive on a donor server (same format, the server is in the same domain so permissions should be ok) and wanted to copy over the data from the old drive to the new one. Once migrated I will simply switch out the old drive for the new one.

Have tried using robocopy on the donor server specifying the source as “\SERVER\d$\UrBackup” and the destination as D:\UrBackup with the /SL parameter to handle the links. The actual command I used was:

ROBOCOPY.exe "\\URBSRV\d$\UrBackup" D:\UrBackup /MIR /COPYALL /DCOPY:DAT /SEC /SECFIX /B /W:5 /MT:8 /ETA /V /LOG:URBSRV_D_UrBackup_Exceptions.LOG /TEE /SL

The command is the same as I have used for many other data migrations including the other data on the same drive. but apart from taking an extremely long time, I’m not convinced it’s worked because there’s a lot of errors logged:

            New File                   0        \\URBSRV\d$\UrBackup\FRINK\current\usr\share\man\man3\SSL_use_RSAPrivateKey.3ossl.gz
2023/10/18 10:25:01 ERROR 1463 (0x000005B7) Copying File \\URBSRV\d$\UrBackup\FRINK\current\usr\share\man\man3\SSL_use_RSAPrivateKey.3ossl.gz
The symbolic link cannot be followed because its type is disabled.

            New File                   0        \\URBSRV\d$\UrBackup\FRINK\current\usr\share\man\man3\SSL_use_RSAPrivateKey_ASN1.3ossl.gz
2023/10/18 10:25:01 ERROR 1463 (0x000005B7) Copying File \\URBSRV\d$\UrBackup\FRINK\current\usr\share\man\man3\SSL_use_RSAPrivateKey_ASN1.3ossl.gz
The symbolic link cannot be followed because its type is disabled.

            New File                   0        \\URBSRV\d$\UrBackup\FRINK\current\usr\share\man\man3\SSL_use_RSAPrivateKey_file.3ossl.gz
2023/10/18 10:25:01 ERROR 1463 (0x000005B7) Copying File \\URBSRV\d$\UrBackup\FRINK\current\usr\share\man\man3\SSL_use_RSAPrivateKey_file.3ossl.gz
The symbolic link cannot be followed because its type is disabled.

            New File                   0        \\URBSRV\d$\UrBackup\FRINK\current\usr\share\man\man3\SSL_verify_cb.3ossl.gz
2023/10/18 10:25:01 ERROR 1463 (0x000005B7) Copying File \\URBSRV\d$\UrBackup\FRINK\current\usr\share\man\man3\SSL_verify_cb.3ossl.gz
The symbolic link cannot be followed because its type is disabled.

Can I ignore these or is there another better way to copy the data to the replacement drive?

2

  1. It seems, after a quick search. that to create symlinks on windows you need admin privileges, are you running robocopy as admin?

  2. I have never actually used robocopy, but a quick search on robocopy and symlinks presented me with this page. Maybe that has something to do with it…

I conclude that unless you have used the /sl option, deleting a backup created with Robocopy should be safe. If you did use the /sl option however, absolute symbolic links could get you into trouble, e.g. when using the del command.
How does Robocopy handle file system links (symbolic links, hard links and junctions)? - Super User

  1. It also seems you do it over the network?
    Robocopy can't copy Symlinks to Network Paths - Data Backup

  2. You can always just clone the drive with some program, and then expand the filesystem after it is done, that will make an exact copy, but I don’t think you should mount that drive before unmounting the original though, they will look exactly the same to the computer, and that can ofc create problems.

3

Thanks, I’d already seen all those and none helped - I did find there’s an fsutil command enable how symlinks behave but that hasn’t helped either.

Cloning the drive is not an option - I have a strange situation not related to UrBackup but seemed to occur with ReFS volumes of a certain version, where they would randomly prevent you moving files within the same volume e.g. you would drag a file from one folder to another on the same drive to move it, but Windows would report “file was not found”, yet doing a copy then delete of the same file worked. The only permanent fix I have found is to reformat the disk as since I did this to another disk where I got this regularly and it’s never happened again.

Anyway, I think I’m going to see if reducing the file backups I have for the 3 Linux machines I back up to just a new full backup then try again. Otherwise I’ll just delete them all.

I’ve been able to move over my Duplicati and Veeam backups without a hitch, so it’s sad I cannot do UrBackup so easily.

4

Just to conclude, in the end I gave up and wiped the backups - I only use them in case of problems with updates to the client machines, and seeing as they’ve all been fine for a few weeks I can risk not having them.

After bringing everything back online on the new drive with just the database, I did a new full file backup of each machine and everything is working like before.