Currently you cannot continue using a backup destination if you change the source data’s OS. You get this message:
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.
Unless I’m mistaken, deleting all filesets would remove all old versions of my data, right? The only benefit of doing so would be avoiding having to upload all my data again.
Judging from a few topics:
- The backup contains files that belong to another operating system - #2 by magnust
- Continuing Backup Jobs after Migrating to Other OS? - #6 by ts678
- Changing source OS - #8 by John
The reasoning behind it has to to do with differences in file paths, and file metadata like permissions.
I can understand that reasoning, but I’d like to suggest it would be better to support changing OS’s. For the specific reason that file history can be important.
If I’m a Windows user backing up my home directory, who then decides to switch to a Mac, there is no guarantee that I will have the resources available to keep my old Windows based backup files around in addition to my new OSX based backup files.
FYI, I’m in a similar situation right now. I was using Windows until recently for the source data OS, now I’ve moved over to Linux. I do not have the resources to keep the old backup data around. Fortunately, I don’t need very many versions of these specific files, so I’m not too mad about starting from scratch, but I’m still not exactly pleased.
What I would have preferred is for the old Windows based versions to simply not allow “in place” restores. Restoring to a new location and then moving the files where I want would solve the problem of different path types and metadata.