This is what is suggested.
urbackup also has a feature to move the backup to another drive without taking the backup system offline for non BTRFS file systems. You have to create a file named “migrate_storage_to” that contains the directory to which you wish for the backup to be migrated to. Urbackup will then continue backing up to the old location while doing the migration In the background.
https://www.urbackup.org/administration_manual.html#x1-9500010.8
This process is, however, quite time consuming. When I attempted this, it took fourteen days to complete on 800GB of backup data.
One of the biggest problems is windows to Linux… I’m sure there’s many people who started using urbackup on windows, Then got themselves a server or NAS and want to have the urbackup server running on that. (If this is what you are looking to do, and seeking answers on how to accomplish this, I will just say as a short answer… Don’t even try.)
The problem Is your backup relies heavily on the file system for its versioning and space saving techniques, Making heavy use of simlinks and hardlinks, As well as special file system features should they be supported, like snapshots on Btrfs, Or zvols for Image backups/FS Block level Deduplication on ZFS.
This heavy reliance on the file system is a double edged sword. On one hand, it means they don’t need to develop a bespoke database and data store system to handle the backups, Like you’d find with Duplicati. You can also trust that the file system will definitely be handling the data correctly. It also means that you can always plug the drive into any other system without the backup software installed, and just copy the data off. However, that means migrating the backup can be an absolute bore If the new target is not set up with the same storage architecture as the previous server.
This is why urbackup server itself has to migrate the data, as it needs to take the old structure and transplant it into the new location, asking for hard links and placing new simlinks in the new file system as required.
If on windows, It would be very likely that your backup drive was NTFS, and paths for the data would be something like “C:.…” This mean simlinks And server database entries will be pointing to locations following the Windows NT Directory Forest architecture. (This is why you have C,D,E,F… drives in Windows) When you tried to read these simlinks or transplant the server database in Linux, It makes absolutely no sense, because Unix operating systems take a single root to all paths approach.
Linux has no idea how to handle, C:,D:,E:,F:.… symlinks/paths because It comes from a architecture that treats each of these drives as their own root (Forest), and Linux just expects a single root, /… , where everything branches out from. (Single tree).
The closest I have gotten to getting a back up from a Windows server somewhat loading on a Linux server Was using rsync archive mode to preserve simlinks and hard links, But then also running a script over all the sim links to convert them all to relative paths. But this even still ultimately failed, As when running remove unknown, as suggested in the manual when migrating to fix simlinks, it just completely eviscerated the data.
This is because I think the database from the windows server contains paths like C:,D:\ ect, Which would not be present on a Linux system, so the server on the Linux side thinks that the file has nothing pointing to it and thus. “Removes Unknown”…
I think what urbackup desperately needs is a “migrate_server” command. This is where one urbackup server connects to another, and rebuilds the hole server on the target. The target server gets the data from the source server and rebuilds its database and data store completely. When done, The old server automatically shuts down and the new server takes over.
Or, another option. migrate_storage_to should migrate the data in a platform agnostic manner. Instead of system symlinks it should use mfsymlinks, and it should placed inode’s (Hardlinks) in a database for the other server to read. Then, when the other server Is linked to this as its backup directory, It recognises it is a migrated back up, and begins a maintenance task to rebuild the backup destination.