Just installed for the first time the client software on a Windows 10 PC ‘OPAL’; server is on the LAN, as is another Win 10 PC ‘TOPAZ’ that had its client installed a few weeks ago and has been running okay AFAIK.
On both client machines, the backup includes a Thunderbird email client profile folder; on OPAL, this is currently the only backup path entry. These profiles are completely distinct, being each allocated to the day-to-day user of the machine; both are in their respective machine’s local filesystem.
After running UrBackup on OPAL for the first time, I went to look at the server to confirm that indeed some backup files had been created and to check the logs. Files were there (way too many to manually confirm) but the log contained some strange entries:
Can anyone explain why the software would be trying to create hardlinks between similarly named files in the backup sets of two different machines? I understand how hardlinks work and that in fact, if successfully created, both ‘files’ would be referencing the same core data (whether that data would come from TOPAZ or OPAL, I’m not sure).
Note that the TOPAZ files are old ones, from Nov 2022, which is around the time when my original install of the server on a QNAP NAS stopped working. The server software has since been reinstalled (just in the last few weeks) but I did not yet clean out the ‘old’ backup file sets from TOPAZ.
Also, why are these errors only warnings, not ‘errors’? Does it mean that the attempt was repeated, this time successfully?
Linking identical files (same SHA hash) regardless of the source machine is something UrBackup does, it’s a backup storage space efficiency thing, a feature rather than a bug.
More interesting is why creating the hardlinks failed.
The former is expected behaviour, the latter isn’t.
It’ll be a warning because you have now 2 copies of the same data, rather than just one, but your backups will still restore, so not an error.
Regarding why it failed: I now believe that the ‘old’ backup files (created by the previous installation of the server) no longer exist, since they were on a drive that went ‘toes up’ in January of this year. I’m guessing that the ‘ghost’ of those files now exist in some database that UrBackup manages, said database surviving the transition from the original, non-working server (last ‘seen’ in Nov/Dec of 2023) to the upgraded new installation. So I think the server software found matches for three of the files in today’s backup of OPAL – presumably some kind of table of filespecs and hashes – but the data of those files no longer existed.
Thank you for your prompt reply, and the insight into how UrBackup operates and why the failure was almost certainly benign from the point of view of my data integrity.
In order to correct missing files you’ll be wanting to run remove-unknown. That’ll correct the database to reflect the present/missing files & vice versa.
