I had a data on a Linux PC (on ext4 partition). I used to regularly backup my data using Duplicati to an external HDD.
Recently, I bought a new Windows PC. I moved all the data to the new Windows PC (on NTFS partition). I exported the backup configurations from the old Linux PC, and imported them on the new Windows PC, and correctly updated the destination and source data paths. Additionally, I moved the .sqlite file from the old Linux PC, and copied it to the new Windows PC, and correctly informed Duplicati, on the new Windows PC, about new path of the .sqlite database file.
Now, on the new Windows PC, I can successfully restore data from Duplicati backups available on the external HDD.
The problem appeared when I tried to continue backing-up my data (now on the new Windows PC), on top of the existing Duplicati backup data on the external HDD. I received an error message saying:
Error while running MyWork
The backup contains files that belong to another operating system. Proceeding with a backup would cause the database to contain paths from two different operation systems, which is not supported. To proceed without losing remote data, delete all filesets and make sure the --no-auto-compact option is set, then run the backup again to re-use the existing data on the remote store.
I don’t understand how can I delete the filesets! Does this mean I have to delete the backups on the external HDD and create a new backup???
Please instruct me how to continue backing up my data. Thanks.
I suspect what the message is getting at is that in a slow-upload-link scenario, it’s better to reconnect your previous file data blocks with the new file paths. That’s just local work, and it doesn’t upload file data again, however that might not matter to you for the external HDD case (and any deleted old versions still get lost).
Duplicati knows files by the path used at the time. I assume all file paths changed, even if it just added C:\. The idea of the big error message is probably to rely on deduplication to refer to prior blocks on destination.
Maybe someone else will think of something, but all I can think of requires quite exotic scripting to get total conversion of old versions onto the new path scheme. If you need less than that, maybe it gets simpler…
If loss of history is not a concern, but (somehow) writes to HDD are, I can try to direct per the message…
Another kind of exotic workaround to use Windows Subsystem for Linux. I don’t know if anyone’s tried that.
EDIT:
What’s your technical skill level? Scripting idea might be a search-and-replace to edit paths in all dlist files. This may or may not work, but if the alternative is starting over, it might be worth a try if you’re up for trying.
While awaiting comment on preference, I’ll finish the previous description, then summarize another option.
The idea of editing the dlist files basically involves decrypting (if encrypted) with AES Crypt or the Duplicati SharpAESCrypt.exe CLI tool, extracting filelist.json from that zip file, changing paths, putting it in .zip, then reencrypting, if necessary. This would likely be easier to script on Linux, and it would edit all the dlists. Final step would be use the Database screen Recreate button to get the edited dlist files back in local DB.
Another option has recently become more workable (maybe – neither of these has really been proven out).
Version 3.12.0 of DB Browser for SQLite has added a “find and replace” dialog which might be used on the PathPrefix table to edit / to \, and add C: prefix with regular expression tilde. Check results in File view.
Backup the DB before starting this. When happy with the edit, “Write Changes”, move all the dlist files into another folder just in case, then use the Database Repair button which will ordinarily rebuild missing dlists.
