5 ms·

Rclone uses WinFSP on windows to mount cloud storage systems via the FUSE compatibility layer. This enables one implementation of a FUSE filing system to work

by nickcw 3y ago

Rclone uses WinFSP on windows to mount cloud storage systems via the FUSE compatibility layer. This enables one implementation of a FUSE filing system to work on lots of OSes. Bill Zissimopoulos also wrote cgofuse which rclone uses to access the FUSE compatibility layer. It's a FUSE library for Go. We use that on Windows and macOS (via macFUSE or fuse-T) too. It runs on Linux too but isn't the default as it needs CGO (linking with C). I've worked a lot with Bill and he knows more about Windows file systems and Windows internals than anyone I've ever met!

NicoJuicy 3y ago
Yeah, i use rclone to mount my box account to my z:/ drive. Really handy for my backups that are stored there, it's a bit slow though. But that's why there is a cache.
- BoppreH 3y ago
  Do you have any protections against ransomware overwiting your backups too? That's the only thing keeping me from using a solution like this.
  - mmwelt 3y ago
    I'm not the person you asked, but one way would be to mount the backup drive just for the backup, then unmount it once the backup is complete. This would limit the time the backup is exposed to ransomware.
  - rainbowzootsuit 3y ago
    I'm unfamiliar with Box, but many of these services have versioning/snapshot on the server side and would allow rolling back changes.
  - NicoJuicy 3y ago
    "Yes". I backup to the day folder ,( eg. 01-31) And to the latest folder
  - dspillett 3y ago
    I'm not familiar with Box, but this is a concern with most backup solutions. Many backup storage providers offer snapshot features that will protect you from that because the snapshots are immutable, just make sure that you check your backup regularly because there have been some cases of data ransom attackers managing to detect and work around such protections¹. Snapshots like this also protect you from a number of accidental matters that might cause you to lose data such as the content of a file being corrupted and the broken version being backed up over the last good one. If the storage provider doesn't offer snapshots you could backup to a rolling target, say one subdirectory per day of the week/month/year, though here you lose the protection of snapshots being less mutable – someone taking control of a machine can kill all the backups as it has full access to them. I do a soft-offline backup³ where the source machines don't have access to the backups directly and so the snapshots. The source machines backup to one external service, just a server connected to via ssh, the backups being maintained using rsync (other tools like rclone already mentioned would do just as well), then another external server reads the backups from there it itself and creates snapshots. The source and backup machines both have credentials to access the intermediate backup but can't authenticate against each other so malware or a human attacker getting access to the source can't corrupt the backups from there or corrupt the source if they hack into the backups. It isn't perfect: there isn't the immutability promise given by some storage providers, verifying backups takes extra steps (but can still be automated), a really determined attacker could still do damage if they get both sets of keys or access to my accounts on the server providers (though that would have to be a very directed attack and I'm not interesting enough to attract one of them!), and I have to be careful about those passwords/keys: I need to be able to authenticate against the final backup service if all else is compromised and for maintenance. -- [1] breaking the backups subtly, so you don't notice and delaying hitting the encrypt-and-ransom switch until after the standard snapshot retention window² has expired [2] assuming this is short, like a month or less, this is less of a concern with longer retention but you still stand to lose recent data [3] I must write properly about that somewhere permanent-ish, so I can just post a link instead of re-describing it in every backup discussion I have!

by nickcw 3y ago

NicoJuicy 3y ago

Yeah, i use rclone to mount my box account to my z:/ drive. Really handy for my backups that are stored there, it's a bit slow though. But that's why there is a cache.

BoppreH 3y ago
Do you have any protections against ransomware overwiting your backups too? That's the only thing keeping me from using a solution like this.
- mmwelt 3y ago
  I'm not the person you asked, but one way would be to mount the backup drive just for the backup, then unmount it once the backup is complete. This would limit the time the backup is exposed to ransomware.
- rainbowzootsuit 3y ago
  I'm unfamiliar with Box, but many of these services have versioning/snapshot on the server side and would allow rolling back changes.
- NicoJuicy 3y ago
  "Yes". I backup to the day folder ,( eg. 01-31) And to the latest folder
- dspillett 3y ago
  I'm not familiar with Box, but this is a concern with most backup solutions. Many backup storage providers offer snapshot features that will protect you from that because the snapshots are immutable, just make sure that you check your backup regularly because there have been some cases of data ransom attackers managing to detect and work around such protections¹. Snapshots like this also protect you from a number of accidental matters that might cause you to lose data such as the content of a file being corrupted and the broken version being backed up over the last good one. If the storage provider doesn't offer snapshots you could backup to a rolling target, say one subdirectory per day of the week/month/year, though here you lose the protection of snapshots being less mutable – someone taking control of a machine can kill all the backups as it has full access to them. I do a soft-offline backup³ where the source machines don't have access to the backups directly and so the snapshots. The source machines backup to one external service, just a server connected to via ssh, the backups being maintained using rsync (other tools like rclone already mentioned would do just as well), then another external server reads the backups from there it itself and creates snapshots. The source and backup machines both have credentials to access the intermediate backup but can't authenticate against each other so malware or a human attacker getting access to the source can't corrupt the backups from there or corrupt the source if they hack into the backups. It isn't perfect: there isn't the immutability promise given by some storage providers, verifying backups takes extra steps (but can still be automated), a really determined attacker could still do damage if they get both sets of keys or access to my accounts on the server providers (though that would have to be a very directed attack and I'm not interesting enough to attract one of them!), and I have to be careful about those passwords/keys: I need to be able to authenticate against the final backup service if all else is compromised and for maintenance. -- [1] breaking the backups subtly, so you don't notice and delaying hitting the encrypt-and-ransom switch until after the standard snapshot retention window² has expired [2] assuming this is short, like a month or less, this is less of a concern with longer retention but you still stand to lose recent data [3] I must write properly about that somewhere permanent-ish, so I can just post a link instead of re-describing it in every backup discussion I have!