My offsite backup server disk set crashed so I had to re upload everything. One of the jobs takes many days so to not lock my local server’s daily backup jobs I started this job from another local computer, backing up the same files. The original local computer is windows, backing up from local disk. The temporary local computer was Debian backing up the same files over a network mount to the original computer.
So when this job had run I went and started the job on the original computer. And got this which I undertstand completely:
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.
So I removed the three dlist files that were on the remote server, set the no-auto-compact option in the job and restarted it.
But I still get the exact same error message? What am I doing wrong here?
Failed: 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.
Details: Duplicati.Library.Interface.UserInformationException: 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.
at Duplicati.Library.Main.Operation.BackupHandler.Run(String sources, IFilter filter)
at Duplicati.Library.Main.Controller.<>c__DisplayClass17_0.<Backup>b__0(BackupResults result)
at Duplicati.Library.Main.Controller.RunAction[T](T result, String& paths, IFilter& filter, Action`1 method)
I think the cleanest recovery from this would be to NOT mix operating systems, however a search for the error message found that this has come up a couple of times, with a difficult solution involving database repair and possibly manual dlist file creation. Duplicati is not good at mixing very different operating systems, due to not only backslash direction, but drive letters and metadata, for example Windows ACLs won’t be saved on Linux.
For background, there’s a local database (see your job’s Database option for its location) which caches info also stored in destination files, e.g. the paths backed up. It’s somewhat unusual to ask for manual deletion of destination files (as opposed to, for example, running The DELETE command) because views go out of sync, however this doesn’t matter if one plans to immediately delete the database and recreate it from destination. The theory there is probably that data blocks will be identified and then merely pointed to in the next backup as deduplication normally does. See How the backup process works. Because next backup is from Windows, the new pathnames will be done Windows-style in both the database and dlist file views. File blocks are OS-independent, but you might wind up getting lots of Windows metadata uploaded that was never done before. Simply removing the dlist file would not update the database’s view, thus producing the error message again. Operations typically use the database when possible because it’s much faster than constant destination use, however recreating a database can be slow due to the amount of destination data that must be downloaded.
Basically I’m hoping you’re willing to backup on Windows, or follow the old articles the lead author worked on. This is rather exotic stuff. Fortunately, you don’t have a huge history you need to preserve, just new backup.
I just wanted to mention that whomever wrote the status message he’s referencing apparently did an awesome job!
But I do need a clarification… It sounds like this is what happened:
backup ran fine on Windows computer to off-site destination
off-site destination crashed LOSING ALL BACKUP HISTORY
started new backup an Linux backing up Windows over network mount which ran fine (this was done to avoid Windows box being bogged down during “initial” re-backup)
tried to move backup job from Linux box to Windows box but now get “multiple OS” message
Does that sound correct or am I missing something?
Thanks for both replies! And yup, you got it right JM.
I knew that file system ACL wouldn’t be dealt with when uploading via a Linux box which I was fine with since it’s only a huge collection of music flac files with no special permissions or anything. But I forgot that this would of course be added to the backup when running from windows again.
I’ll just drop this and re-upload properly. Probably set up a temporary windows machine instead. Needs a bit more hardware only (I was very short on memory, hence the Debian choice)
