bit-team
NTFS is not fit as a target filesystem for backintime
Users keep having problems when trying to write backups to NTFS drives: there are permissions problems, lack of hardlinking and more. Our documentation should clearly warn users about that, and I think we should consider NTFS unsupported as a target filesystem.
Then again, permissions should be fine, because they are kept separately in fileinfo.bz2. However, hardlinking certainly won't work. I think this warrants discussion.
Are they really NTFS partitions or are they (NTFS) partitions mounted via Samba?
I know there are NTFS drivers for linux also. But I remember they are kind of exotic.
But if you have a real NTFS partition on linux (not via samba) then it is interesting to know if hardlinks work. Because NTFS also support something like hardlinks ("junctions"?). If you have rsync on linux and a linux ntfs-driver... It should work.
Just my 2 cents.
After some research I would say it could work.
But this would need further testing. I'm not sure how BIT reacts when storing file permissions from an NTFS partition into fileinfo.bz2 and back. More complex when restoring NTFS->ext4 or other way around.
Hardlinks should work.
I also read about that rsync need extra switches to determine if a file was modified or not on an NTFS partition.
So a lot of edge cases and a lof of extra if-then-else code.
Not sure if it's worth it. BIT is intended to work on Linux. So why someone does use an NTFS partition?
Maybe we should drop the NTFS support explicit. We can have a FAQ entry for that. We could make BIT to check if the snapshot destination is an NTFS partition and warn or error about it.
Thanks for doing research!
I think the most common use-case is external drives which are shared between Windows and Linux systems, and in that context also used as backup storage with backintime.
My feeling also says we should declare it unsupported. But some tests will be interesting before we take that step, because it seems common among users.
Testing this would be a good job for "new contributors".
I would set priority to low.
Comment from a user who backs up to ntfs:
I'm running Linux in a virtual box on a windows machine. The host OS must be Windows because it's a work machine and they IT department says it must be. I can't mount USB drives by policy, so my backup option is to mount my One-Drive account (microsoft's cloud offering) inside my guest Linux OS and point BIT at that location. It works, mostly (BIT falls back on making a full back up each time, as far as I can tell), and it certainly works better than any alternative I can think of.
While it would be great if ntfs was fully supported, I can understand why you wouldn't want to do that. However at the other extreme, it would really get in my way if BIT refused to back up to ntfs at all. Maybe issue a warning that not all features are fully supported on ntfs?
Keep up the excellent work! I've been using BIT across multiple machines for years now, and it gets the balance of power and simplicity just right.
The source code does not contain any special handing of NTFS so far (neither as backup source nor as target) and the use case described by @fergalm is a legit one.
We could add a check of the source and target file system types against a whitelist of
- fully supported and
- supported with known restrictions
file systems and issue
- a message in the GUI (when saving a configuration)
- log output with a warning
Open question:
- How reliably can we check the existing file system (eg. in case of SSH'ing)
Comment from an other user who backs up to ntfs.
I find that the ability of backintime to back up on ntfs while keeping track of the permissions of files is one of its remarkable and specific features that makes it stand out.
When I made the transition to Linux from Windows a few years back, I specifically chose backintime because of this specificity an I heavily relied on this ability to be keep a foot in both OSs and use the same drive formatted as ntfs to make both my Windows and Linux backups. It was also extremely convenient and reassuring to be able to directly access the files in the backintime backups from any OS.
I still nowadays rely on both Linux and Windows because I need to use professional applications that run only on Windows. And being able to access the backups from any system is very convenient.
I imagine that keeping such a feature necessarily increases the amount of labour to maintain the application, so I would understand if for that reason it would have to be dropped. But it would be a pity if it had to happen.
I think we can close this issue. NTFS seems to be used by many users, and we can tackle specific problems if/when they are reported. I don't see any need to make a recommendation for/against NTFS anymore. (Same as #924 )